[Bug target/105953] [12/13 Regression] ICE in extract_insn, at recog.cc:2791
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105953 --- Comment #4 from Hongtao.liu --- Fixed in GCC12.2 and trunk.
[Bug rtl-optimization/55278] [10/11/12/13 Regression] Botan performance regressions, other compilers generate better code than gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278
--- Comment #30 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:acb1e6f43dc2bbedd1248ea61c7ab537a11fe59b
commit r13-1100-gacb1e6f43dc2bbedd1248ea61c7ab537a11fe59b
Author: Roger Sayle
Date: Wed Jun 15 09:31:13 2022 +0200
Fold truncations of left shifts in match.pd
Whilst investigating PR 55278, I noticed that the tree-ssa optimizers
aren't eliminating the promotions of shifts to "int" as inserted by the
c-family front-ends, instead leaving this simplification to be left to
the RTL optimizers. This patch allows match.pd to do this itself earlier,
narrowing (T)(X << C) to (T)X << C when the constant C is known to be
valid for the (narrower) type T.
Hence for this simple test case:
short foo(short x) { return x << 5; }
the .optimized dump currently looks like:
short int foo (short int x)
{
int _1;
int _2;
short int _4;
[local count: 1073741824]:
_1 = (int) x_3(D);
_2 = _1 << 5;
_4 = (short int) _2;
return _4;
}
but with this patch, now becomes:
short int foo (short int x)
{
short int _2;
[local count: 1073741824]:
_2 = x_1(D) << 5;
return _2;
}
This is always reasonable as RTL expansion knows how to use
widening optabs if it makes sense at the RTL level to perform
this shift in a wider mode.
Of course, there's often a catch. The above simplification not only
reduces the number of statements in gimple, but also allows further
optimizations, for example including the perception of rotate idioms
and bswap16. Alas, optimizing things earlier than anticipated
requires several testsuite changes [though all these tests have
been confirmed to generate identical assembly code on x86_64].
The only significant change is that the vectorization pass wouldn't
previously lower rotations of signed integer types. Hence this
patch includes a refinement to tree-vect-patterns to allow signed
types, by using the equivalent unsigned shifts.
2022-06-15 Roger Sayle
Richard Biener
gcc/ChangeLog
* match.pd (convert (lshift @1 INTEGER_CST@2)): Narrow integer
left shifts by a constant when the result is truncated, and the
shift constant is well-defined.
* tree-vect-patterns.cc (vect_recog_rotate_pattern): Add
support for rotations of signed integer types, by lowering
using unsigned vector shifts.
gcc/testsuite/ChangeLog
* gcc.dg/fold-convlshift-4.c: New test case.
* gcc.dg/optimize-bswaphi-1.c: Update found bswap count.
* gcc.dg/tree-ssa/pr61839_3.c: Shift is now optimized before VRP.
* gcc.dg/vect/vect-over-widen-1-big-array.c: Remove obsolete tests.
* gcc.dg/vect/vect-over-widen-1.c: Likewise.
* gcc.dg/vect/vect-over-widen-3-big-array.c: Likewise.
* gcc.dg/vect/vect-over-widen-3.c: Likewise.
* gcc.dg/vect/vect-over-widen-4-big-array.c: Likewise.
* gcc.dg/vect/vect-over-widen-4.c: Likewise.
[Bug c++/105985] New: The case of "indirectly" exported by the primary module interface unit is not accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105985
Bug ID: 105985
Summary: The case of "indirectly" exported by the primary
module interface unit is not accepted
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: xmh970252187 at gmail dot com
Target Milestone: ---
// translation unit C
export module M :C;
// translation unit U
export module M :U;
import :C;
// translation unit T
export module M;
export import :U; // #1
[module.unit] says
> All module partitions of a module that are module interface units shall be
> directly or indirectly exported by the primary module interface unit
> ([module.import]). No diagnostic is required for a violation of these rules.
[module.import] p7 says
> When a module-import-declaration imports a translation unit T, it also
> imports all translation units imported by exported module-import-declarations
> in T; such translation units are said to be exported by T. Additionally, when
> a module-import-declaration in a module unit of some module M imports another
> module unit U of M, it also imports all translation units imported by
> non-exported module-import-declarations in the module unit purview of U.
> These rules can in turn lead to the importation of yet more translation units.
It is clear that "U" is exported by "T" since an exported
module-import-declaration at #1 imports "U" in "T", which is exactly said in
the first part of [module.import] p7.
Since "T" and "U" are both module units of "M", the second part of
[module.import] p7 should apply to the "module-import-declaration" at #1, since
the "non-exported module-import-declaration"("import :C;") appears in U, the
module-import-declaration at #1 should also import "C". So, "C" is arguably
said that it is indirectly exported by "T". All partition module interface
units of M are exported by the primary module interface unit of M. There is no
violation here.
However, If we compile the example through GCC, it reports an error that:
> interface partition is not exported
[Bug middle-end/105604] [10/11 Regression] ICE: in tree_to_shwi with vla in struct and sprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105604 Richard Biener changed: What|Removed |Added Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW Version|12.0|11.2.1 --- Comment #7 from Richard Biener --- Originally (gentoo) reported against 11.2, but the fix doesn't cherry-pick nicely.
[Bug c/105923] unsupported return type ‘complex double’ for simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105923 --- Comment #5 from Hongtao.liu --- after a rough hack to allow complex type in both omp-simd-clone and vectorizer(get_related_vectype_for_scalar_type), testcase in PR could be compiled to .L4: vmovapd a(%rbx), %ymm0 addq$32, %rbx call_ZGVdN4v_foo vmovapd %ymm0, b-32(%rbx) cmpq%rbx, %r13 jne .L4 movl%r12d, %ebx andl$-4, %ebx movl%ebx, %r13d cmpl%ebx, %r12d je .L20 vzeroupper .L3: subl%r13d, %r12d cmpl$1, %r12d je .L6 salq$4, %r13 vmovapd a(%r13), %xmm0 call_ZGVbN2v_foo vmovapd %xmm0, b(%r13) testb $1, %r12b je .L17 andl$-2, %r12d addl%r12d, %ebx .L6: movslq %ebx, %rbx salq$4, %rbx vmovsd a(%rbx), %xmm0 vmovsd a+8(%rbx), %xmm1 callfoo vmovsd %xmm0, b(%rbx) vmovsd %xmm1, b+8(%rbx)
[Bug c/105923] unsupported return type ‘complex double’ for simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105923 --- Comment #6 from Hongtao.liu --- > .L3: > subl%r13d, %r12d > cmpl$1, %r12d > je .L6 > salq$4, %r13 > vmovapd a(%r13), %xmm0 > call_ZGVbN2v_foo > vmovapd %xmm0, b(%r13) hmm, xmm version should be abandoned since it's just 1 complex double.
[Bug libstdc++/103501] associative containers left invalid after allocator-extended move construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103501 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:d4fdb293004f2e104edf823d4820d4ee73aa2660 commit r10-10837-gd4fdb293004f2e104edf823d4820d4ee73aa2660 Author: Jonathan Wakely Date: Tue Nov 30 23:32:50 2021 + libstdc++: Clear RB tree after moving elements [PR103501] If the allocator-extended move constructor move-constructs each element into the new container, the contents of the old container are left in moved-from states. We cannot know if those states preserve the container's ordering and uniqueness guarantees, so just erase all moved-from elements. libstdc++-v3/ChangeLog: PR libstdc++/103501 * include/bits/stl_tree.h (_Rb_tree(_Rb_tree&&, false_type)): Clear container if elements have been moved-from. * testsuite/23_containers/multiset/allocator/103501.cc: New test. * testsuite/23_containers/set/allocator/103501.cc: New test. (cherry picked from commit 056551414a328b427c4bf4955b9a3832f344685c)
[Bug libstdc++/104731] 27_io/filesystem/iterators/error_reporting.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104731 --- Comment #12 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:6b59f8acada4858f5dd532185a0030cf79163247 commit r10-10841-g6b59f8acada4858f5dd532185a0030cf79163247 Author: Jonathan Wakely Date: Fri May 6 14:31:06 2022 +0100 libstdc++: Fix test that fails on Solaris [PR104731] On Solaris the dirent::d_name member is a single char, causing this test to fail with warnings about buffer overflow. Change the test to use a union with additional space for writing a string to the d_name member. libstdc++-v3/ChangeLog: PR libstdc++/104731 * testsuite/27_io/filesystem/iterators/error_reporting.cc: Use a trailing char array as storage for dirent::d_name. (cherry picked from commit aa8bdfee1db818b9a56908ab0197ff02c54bf281)
[Bug libstdc++/103501] associative containers left invalid after allocator-extended move construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103501 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |10.4 --- Comment #6 from Jonathan Wakely --- Fixed for 10.4 and 11.3 and 12.1, but I still need to check the unordered containers.
[Bug fortran/105986] New: ICE in gfc_convert_mpz_to_signed, at fortran/simplify.cc:193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105986 Bug ID: 105986 Summary: ICE in gfc_convert_mpz_to_signed, at fortran/simplify.cc:193 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : $ cat z1.f90 program p integer :: i print *, [(btest(ibset(8_1,i), i), i=0,8)] print *, [(btest(ibset(8_2,i), i), i=0,16)] print *, [(btest(ibset(8_4,i), i), i=0,32)] print *, [(btest(ibset(8_8,i), i), i=0,64)] print *, [(btest(ibset(8_16,i), i), i=0,128)] end $ cat z2.f90 program p integer :: i print *, [(btest(ibset(8_1,i), i), i=-1,7)] print *, [(btest(ibset(8_2,i), i), i=-1,15)] print *, [(btest(ibset(8_4,i), i), i=-1,31)] print *, [(btest(ibset(8_8,i), i), i=-1,63)] print *, [(btest(ibset(8_16,i), i), i=-1,127)] end $ gfortran-13-20220612 -c z1.f90 f951: internal compiler error: in gfc_convert_mpz_to_signed, at fortran/simplify.cc:193 0x788eb1 gfc_convert_mpz_to_signed(__mpz_struct*, int) ../../gcc/fortran/simplify.cc:193 0x78e41b gfc_simplify_ibset(gfc_expr*, gfc_expr*) ../../gcc/fortran/simplify.cc:3452 0x70e3c6 do_simplify ../../gcc/fortran/intrinsic.cc:4670 0x7191c8 gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc/fortran/intrinsic.cc:4942 0x6ff0dc gfc_simplify_expr(gfc_expr*, int) ../../gcc/fortran/expr.cc:2228 0x6fed3b gfc_simplify_expr(gfc_expr*, int) ../../gcc/fortran/expr.cc:2224 0x6c59f1 expand_constructor ../../gcc/fortran/array.cc:1839 0x6c5c9e expand_expr ../../gcc/fortran/array.cc:1697 0x6c5c9e expand_iterator ../../gcc/fortran/array.cc:1767 0x6c5c9e expand_constructor ../../gcc/fortran/array.cc:1810 0x6c7dc7 gfc_array_size(gfc_expr*, __mpz_struct (*) [1]) ../../gcc/fortran/array.cc:2677 0x76a75f expression_shape ../../gcc/fortran/resolve.cc:5519 0x76a75f gfc_expression_rank(gfc_expr*) ../../gcc/fortran/resolve.cc:5593 0x76c02f gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.cc:7223 0x77411c gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.cc:7154 0x77411c gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.cc:11966 0x772baf gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.cc:10965 0x772f08 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.cc:11956 0x775c97 resolve_codes ../../gcc/fortran/resolve.cc:17609 0x775d5e gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.cc:17644
[Bug c/105987] New: ICE: unspellable token PRAGMA_EOL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105987 Bug ID: 105987 Summary: ICE: unspellable token PRAGMA_EOL Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : (test cases c-c++-common/gomp/declare-variant-9.c, -10.c, -11.c) $ gcc-13-20220612 -c declare-variant-9.c -fopenmp -traditional-cpp declare-variant-9.c:43: internal compiler error: unspellable token PRAGMA_EOL 43 | #if defined(__i386__) || defined(__x86_64__) | 0x74d9f2 c_cpp_diagnostic(cpp_reader*, cpp_diagnostic_level, cpp_warning_reason, rich_location*, char const*, __va_list_tag (*) [1]) ../../gcc/c-family/c-common.cc:6673 0x19eb6b7 cpp_diagnostic ../../libcpp/errors.cc:82 0x19eb766 cpp_error(cpp_reader*, cpp_diagnostic_level, char const*, ...) ../../libcpp/errors.cc:96 0x19f50fd cpp_spell_token(cpp_reader*, cpp_token const*, unsigned char*, bool) ../../libcpp/lex.cc:4164 0x19f5df7 cpp_token_as_text(cpp_reader*, cpp_token const*) ../../libcpp/lex.cc:4180 0x19efabc _cpp_parse_expr ../../libcpp/expr.cc:1375 0x19e8393 do_if ../../libcpp/directives.cc:2060 0x19e9ca0 _cpp_handle_directive ../../libcpp/directives.cc:557 0x1a0632d _cpp_scan_out_logical_line ../../libcpp/traditional.cc:776 0x1a06a90 _cpp_read_logical_line_trad ../../libcpp/traditional.cc:321 0x76d287 scan_translation_unit_trad ../../gcc/c-family/c-ppoutput.cc:420 0x76d287 preprocess_file(cpp_reader*) ../../gcc/c-family/c-ppoutput.cc:97 0x76b748 c_common_init() ../../gcc/c-family/c-opts.cc:1214 0x6a6826 lang_dependent_init ../../gcc/toplev.cc:1834 0x6a6826 do_compile ../../gcc/toplev.cc:2129
[Bug c/105988] New: [10/11/12/13 Regression] ICE in linemap_ordinary_map_lookup, at libcpp/line-map.cc:1064
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105988 Bug ID: 105988 Summary: [10/11/12/13 Regression] ICE in linemap_ordinary_map_lookup, at libcpp/line-map.cc:1064 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started with r12, using file gcc.dg/pr59020.c : (gcc configured with --enable-checking=yes) $ gcc-13-20220612 -c pr59020.c -O2 -da -fmodulo-sched $ gcc-13-20220612 -c pr59020.c -O2 -da -fmodulo-sched -fno-tree-dce during RTL pass: sms dump file: pr59020.c.297r.sms pr59020.c: In function 'f': pr59020.c:15:1: internal compiler error: in linemap_ordinary_map_lookup, at libcpp/line-map.cc:1064 15 | } | ^ 0x1eb9ca4 linemap_ordinary_map_lookup ../../libcpp/line-map.cc:1064 0x1ebb07d linemap_macro_loc_to_exp_point ../../libcpp/line-map.cc:1561 0x1e93586 expand_location_1 ../../gcc/input.cc:243 0x1e950df expand_location(unsigned int) ../../gcc/input.cc:956 0x9b3b4b insn_location(rtx_insn const*) ../../gcc/emit-rtl.cc:6558 0x1d09e6a dump_insn_location ../../gcc/modulo-sched.cc:1250 0x1d0dc02 sms_schedule ../../gcc/modulo-sched.cc:1418 0x1d1056f execute ../../gcc/modulo-sched.cc:3358
[Bug c/105988] [10/11/12/13 Regression] ICE in linemap_ordinary_map_lookup, at libcpp/line-map.cc:1064
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105988 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-valid-code Target||x86_64-pc-linux-gnu --- Comment #1 from G. Steinmetz --- Starts with r6 and file gcc.dg/torture/pr56034.c, etc. : (starts with r7 without option -fno-tree-dce) $ gcc-13-20220612 -c pr56034.c -O2 -da -fmodulo-sched -fno-tree-dce during RTL pass: sms dump file: pr56034.c.297r.sms pr56034.c: In function 'f': pr56034.c:19:1: internal compiler error: in linemap_ordinary_map_lookup, at libcpp/line-map.cc:1064 19 | } | ^ 0x1eb9ca4 linemap_ordinary_map_lookup ../../libcpp/line-map.cc:1064 0x1ebb07d linemap_macro_loc_to_exp_point ../../libcpp/line-map.cc:1561 0x1e93586 expand_location_1 ../../gcc/input.cc:243 0x1e950df expand_location(unsigned int) ../../gcc/input.cc:956 0x9b3b4b insn_location(rtx_insn const*) ../../gcc/emit-rtl.cc:6558 0x1d09e6a dump_insn_location ../../gcc/modulo-sched.cc:1250 0x1d0dc02 sms_schedule ../../gcc/modulo-sched.cc:1418 0x1d1056f execute ../../gcc/modulo-sched.cc:3358
[Bug tree-optimization/97185] inconsistent builtin elimination for impossible range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97185 --- Comment #3 from Siddhesh Poyarekar --- (In reply to Martin Sebor from comment #2) > There's a heuristic for ranges of allocation sizes to exclude zero > (size_range_flags) that comes into play here. The actual range isn't > "impossible" in the sense it's necessarily invalid. It just means the > string function call is either a no-op or out of bounds, and so can be > eliminated as an optimization. With the optimization consistently > implemented the warning will also go away (eliminating the calls will > prevent sanitizers from detecting the out of bounds ones, so that might be a > consideration). Ahh I see it now, I had missed that it was an 'int'. ISTM that a better idea would be to *not* optimize away memcpy and memmove in this case, not the other way around. > > In general, a low > high range denoted an anti-range before Ranger was > introduced (i.e., ~[high, low]). With Ranger it's the corresponding union > of two ranges. Some of the cruft for dealing with anti-ranges is still > around, such as in get_size_range() in pointer-query.cc. The code should be > migrated to the irange class and the representation probably also updated to > print something more sensible (e.g., the union [MIN, high) U (low, MAX]; we > talked about introducing a pretty-printer % directive for ranges to make the > format consistent across all diagnostics). That makes sense, thanks.
[Bug c/105987] ICE: unspellable token PRAGMA_EOL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105987 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 79516. *** This bug has been marked as a duplicate of bug 79516 ***
[Bug c/79516] [10/11/12/13 Regression] ICE: unspellable token PRAGMA_EOL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79516 Andrew Pinski changed: What|Removed |Added CC||gs...@t-online.de --- Comment #4 from Andrew Pinski --- *** Bug 105987 has been marked as a duplicate of this bug. ***
[Bug target/105938] [12/13 Regression] ICE in get_insn_temp late, at final.cc:2050 on nvptx-none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105938
--- Comment #1 from Matthias Klose ---
$ cat libgcc2.i
int __subvti3_a, __subvti3_b;
void __subvti3() {
int w;
__builtin_sub_overflow(__subvti3_a, __subvti3_b, &w);
}
$ /home/packages/gcc/12/gcc-12-12.1.0/build-nvptx/gcc/xgcc
-B/home/packages/gcc/12/gcc-12-12.1.0/build-nvptx/gcc/ -g -O -c libgcc2.i
during RTL pass: final
libgcc2.i: In function ‘__subvti3’:
libgcc2.i:5:1: internal compiler error: in get_insn_template, at final.cc:2050
5 | }
| ^
0x5b17d5 get_insn_template(int, rtx_insn*)
../../src-nvptx/gcc/final.cc:2050
0x81f924 final_scan_insn_1
../../src-nvptx/gcc/final.cc:2827
0x81fe0b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../src-nvptx/gcc/final.cc:2940
0x820095 final_1
../../src-nvptx/gcc/final.cc:1997
0x820872 rest_of_handle_final
../../src-nvptx/gcc/final.cc:4285
0x820872 execute
../../src-nvptx/gcc/final.cc:4363
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
omitting either -g or -O avoids the ICE.
[Bug target/105975] OpenMP/nvptx offloading: 'internal compiler error: in maybe_legitimize_operand, at optabs.cc:7785'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105975
--- Comment #2 from Thomas Schwinge ---
Created attachment 53140
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53140&action=edit
'a-for-11.o.xz'
With commit 1d205dbac1e1754c01c22a31bd1688126545401e "Factor out common
internal-fn idiom" sources, I've run such an OpenMP/nvptx offloading
compilation ('libgomp.c-c++-common/for-11.c', '-O1') with '-v -save-temps', and
we see:
[...]
/home/thomas/tmp/source/gcc/build/trace-slim-omp/build-gcc-offload-nvptx-none/gcc/lto1
-quiet -dumpbase ./a.xnvptx-none.mkoffload -m64 -mgomp -O1 -version
-fno-openacc -fno-pie -fcf-protection=none -foffload-abi=lp64 -fopenmp
@./a.xnvptx-none.mkoffload.args.0 -o ./a.xnvptx-none.mkoffload.s
[...]
during RTL pass: expand
source-gcc/libgomp/testsuite/libgomp.c-c++-common/for-2.h: In function
‘f20_tpf_simd_static._omp_fn.1’:
source-gcc/libgomp/testsuite/libgomp.c-c++-common/for-2.h:343:9: internal
compiler error: in maybe_legitimize_operand, at optabs.cc:7785
[...]
$ cat < a.xnvptx-none.mkoffload.args.0
a-for-11.o
If you now build a nvptx offloading compiler (same commit
1d205dbac1e1754c01c22a31bd1688126545401e sources):
$ ../source-gcc/configure --target=nvptx-none
--enable-as-accelerator-for=x86_64-pc-linux-gnu --enable-languages=lto
--enable-checking=yes,extra,rtl
$ make -j16 all-gcc
..., you ought to be able to reproduce the ICE (using the 'a-for-11.o' I've
attached to this PR, 'xz'-compressed):
$ gcc/lto1 -quiet -dumpbase ./a.xnvptx-none.mkoffload -m64 -mgomp -O1
-version -fno-openacc -fno-pie -fcf-protection=none -foffload-abi=lp64 -fopenmp
a-for-11.o -o ./a.xnvptx-none.mkoffload.s
[...]
during RTL pass: expand
../source-gcc/libgomp/testsuite/libgomp.c-c++-common/for-2.h: In function
‘f20_tpf_simd_static._omp_fn.1’:
../source-gcc/libgomp/testsuite/libgomp.c-c++-common/for-2.h:343:9:
internal compiler error: in maybe_legitimize_operand, at optabs.cc:7785
[...]
[Bug c/105969] [12/13 Regression] ICE in Floating point exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105969
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Last reconfirmed||2022-06-15
Target Milestone|--- |12.2
Keywords||accepts-invalid,
||needs-bisection
Ever confirmed|0 |1
CC||jsm28 at gcc dot gnu.org
Blocks||105604
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Richard Biener ---
Confirmed.
(gdb) l
2317
2318unsigned HOST_WIDE_INT byteoff = idx * elbytes;
2319
2320if (byteoff < HOST_WIDE_INT_MAX
2321&& elbytes < HOST_WIDE_INT_MAX
2322&& byteoff / elbytes == idx)
2323 {
2324/* For in-bounds constant offsets into constant-sized
arrays
2325 bump up *OFF, and for what's likely arrays or structs of
2326 arrays, also *FLDOFF, as necessary. */
(gdb) p elbytes
$1 = 0
I think this testcase should probably be rejected given we have b with
an array element size of zero which means elements overlap. Joseph?
The ICE can be mitigated by reworking the byteoff / elbytes == idx check
which seems to be looking for whether the byteoff computation overflowed?
(but we don't check whether *off += byteoff overflows). The overflow
checking can be preserved by doing elbytes == 0 || byteoff / elbytes == idx.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105604
[Bug 105604] [10/11 Regression] ICE: in tree_to_shwi with vla in struct and
sprintf
[Bug target/105975] OpenMP/nvptx offloading: 'internal compiler error: in maybe_legitimize_operand, at optabs.cc:7785'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105975
--- Comment #3 from Thomas Schwinge ---
Created attachment 53141
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53141&action=edit
'a.xnvptx-none.mkoffload.s.xz'
For cross-checking: if I now temporarily 'git revert
1d205dbac1e1754c01c22a31bd1688126545401e', and rebuilt things, I get the same
'a-for-11.o' file (with just some randomness in '.section' names; different
issue), and the nvptx 'gcc/lto1' command produces 'a.xnvptx-none.mkoffload.s'
as attached ('xz'-compressed).
(I'll soon be off of work for a few days.)
[Bug tree-optimization/105971] [12/13 Regression] ICE in bitmap_check_index, at sbitmap.h:104
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105971 Richard Biener changed: What|Removed |Added Keywords||needs-bisection Component|c |tree-optimization Target Milestone|--- |12.2
[Bug tree-optimization/105726] [10/11 Regression] spurious warning with -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105726 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:d76c15430f74024f1658be55cfcd2ed9f581f1bd commit r11-10069-gd76c15430f74024f1658be55cfcd2ed9f581f1bd Author: Richard Biener Date: Wed May 25 11:49:03 2022 +0200 tree-optimization/105726 - adjust array bound heuristic There's heuristic to detect ptr[1].a[...] out of bound accesses reasoning that if ptr points to an array of aggregates a trailing incomplete array has to have size zero. The following more thoroughly constrains the cases this applies to avoid false positive diagnostics. 2022-05-25 Richard Biener PR tree-optimization/105726 * gimple-ssa-warn-restrict.c (builtin_memref::set_base_and_offset): Constrain array-of-flexarray case more. * g++.dg/warn/Warray-bounds-27.C: New testcase. (cherry picked from commit e7c482b08076bb299742883c4ffd65b31e33200c)
[Bug c++/105989] New: Coroutine frame space for temporaries in a co_await expression is not reused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105989 Bug ID: 105989 Summary: Coroutine frame space for temporaries in a co_await expression is not reused Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: michal.jankovic59 at gmail dot com Target Milestone: --- Created attachment 53142 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53142&action=edit Minimal reproduction of the described issue. Space in a coroutine frame that is allocated for temporaries in a co_await expression (in particular the awaiter object) is not reused for subsequent co_await-s. Writing the same co_await expression multiple times results in a larger coroutine frame than using a for loop, where the space is only allocated once. This is a bummer for me, as I would like to use coroutines for embedded systems with limited memory, and every byte counts. I would expect that the space in the coroutine frame for the temporaries of two subsequent co_await expressions would overlap. This appears to work on Clang (allthough it has a similar issue with HALO, where the space for the subroutine frames do not overlap). The attached minimal example shows the issue by logging allocations of the coroutine frames; change the number of co_await expressions in coro_1() and the size of the dummy array in the awaiter object to see that the space for the awaiter is not reclaimed. Change it to 1 co_await in a for loop, and the temporaries are only allocated once. Compilation command (the issue is on all optimization levels, not just -O3): g++ -std=c++20 -fcoroutines -O3 --save-temps report.cpp gcc -v output: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-werror --with-build-config=bootstrap-lto --enable-link-serialization=1 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.1.0 (GCC)
[Bug c/105972] [12/13 Regression] ICE in lower_stmt, at gimple-low.cc:312
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105972
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2022-06-15
Status|UNCONFIRMED |NEW
Target Milestone|--- |12.2
Keywords||error-recovery,
||ice-checking,
||needs-bisection
--- Comment #1 from Richard Biener ---
Confirmed. Somehow we get in .original
;; Function f (null)
;; enabled by -tree-original
{
static int g ();
# DEBUG BEGIN STMT;
static int g ();
}
with the error but correctly
;; Function f (null)
;; enabled by -tree-original
{
extern int g ();
}
with the error fixed.
[Bug tree-optimization/105973] Wrong branch prediction for if (COND) { if(x) noreturn1(); else noreturn2(); }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105973 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #3 from Richard Biener --- possibly the noreturn predictor doesn't trigger here
[Bug target/105974] [13 Regression] ICE: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in arm_bfi_1_p, at config/arm/arm.cc:10214
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105974 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0
[Bug c++/105976] -Wuse-after-free warning with std::shared_ptr[]>::reset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105976 --- Comment #1 from Richard Biener --- I think I've seen a duplicate for this.
[Bug c/105977] [12/13 Regression] ICE in gimple_call_static_chain_flags, at gimple.cc:1636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105977 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.2 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||hubicka at gcc dot gnu.org Last reconfirmed||2022-06-15 --- Comment #1 from Richard Biener --- -fdisable-ipa-inline might confuse us enough here, we run into 1634 /* Nested functions should always bind to current def since 1635 there is no public ABI for them. */ 1636 gcc_checking_assert (node->binds_to_current_def_p ()); (gdb) p node->debug() a.0/0 (a) @0x76a26000 Type: function Body removed by symtab_remove_unreachable_nodes Visibility: semantic_interposition prevailing_def_ironly References: Referring: Availability: not_available Function flags: count:118111600 (estimated locally) optimize_size static_chain Called by: Calls: $3 = void might be not a bug, -fdisable-* are only for debugging.
[Bug target/105980] [11/12/13 Regression] ICE in final_scan_insn_1, at final.cc:2811
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105980 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.4
[Bug c++/105982] [13 Regression] internal compiler error: in lookup_template_class, at cp/pt.cc:10361
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105982 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/105984] [13 Regression] wrong code with __builtin_mul_overflow_p() at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105984 Richard Biener changed: What|Removed |Added Keywords||needs-bisection Target Milestone|--- |13.0
[Bug middle-end/105984] [13 Regression] wrong code with __builtin_mul_overflow_p() at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105984 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2022-06-15 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Keywords|needs-bisection | Priority|P3 |P1 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with my r13-979-g1982fe2692b6c3b7f969ffc4edac59f9d4359e91
[Bug tree-optimization/105971] [12/13 Regression] ICE in bitmap_check_index, at sbitmap.h:104
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105971
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Last reconfirmed||2022-06-15
Priority|P3 |P2
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Keywords|needs-bisection |
--- Comment #1 from Richard Biener ---
Confirmed.
#1 0x02d39e66 in bitmap_check_index (map=0x44062b0, index=-1)
at /space/rguenther/src/gcc/gcc/sbitmap.h:104
104 gcc_checking_assert (index >= 0);
get_byte_range returns true but a size of zero, it seems to be constrainted
on "COPY inside REF" but we have
(gdb) p *use_ref
$3 = {ref = ,
base = ,
offset = {> = {coeffs = {0}}, },
size = {> = {coeffs = {32}}, },
max_size = {> = {coeffs = {32}}, },
ref_alias_set = -1, base_alias_set = -1, volatile_p = false}
(gdb) p *ref
$4 = {ref = ,
base = ,
offset = {> = {coeffs = {32}}, },
size = {> = {coeffs = {32}}, },
max_size = {> = {coeffs = {32}}, },
ref_alias_set = -1, base_alias_set = -1, volatile_p = false}
which means the refs do not overlap. We have
(gdb) p debug_gimple_stmt (use_stmt)
# VUSE <.MEM_16>
_2 = REALPART_EXPR ;
$5 = void
(gdb) p debug_gimple_stmt (stmt)
# .MEM_21 = VDEF <.MEM_18>
IMAGPART_EXPR = _5;
so we expected ref_maybe_used_by_stmt_p to return false but it does not
(because we reference a FUNCTION_DECL). That's because of
/* We can end up referring to code via function and label decls.
As we likely do not properly track code aliases conservatively
bail out. */
if (TREE_CODE (base1) == FUNCTION_DECL
|| TREE_CODE (base1) == LABEL_DECL
|| TREE_CODE (base2) == FUNCTION_DECL
|| TREE_CODE (base2) == LABEL_DECL)
return true;
we can make this less restrictive for the case of two decls which is also
the case DSE is interested in here.
[Bug target/105974] [13 Regression] ICE: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in arm_bfi_1_p, at config/arm/arm.cc:10214
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105974 Richard Earnshaw changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rearnsha at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-06-15 --- Comment #1 from Richard Earnshaw --- Mine
[Bug rtl-optimization/105988] [10/11/12/13 Regression] ICE in linemap_ordinary_map_lookup, at libcpp/line-map.cc:1064
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105988 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.4
[Bug c++/105989] Coroutine frame space for temporaries in a co_await expression is not reused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105989
--- Comment #1 from Michal Jankovič ---
Exploring further, this seems to be a symptom of a deeper issue - the coroutine
frame contains space for ALL variables of the coroutine, not just for the
maximally sized subset of the variables that can be alive across suspension.
Temporaries in co_await are just promoted to stored variables, so exhibit the
same problem.
This is easy to see when changing coro_1() body to:
{ std::byte _[500]; co_await coro_2(); }
{ std::byte _[500]; co_await coro_2(); }
{ std::byte _[500]; co_await coro_2(); }
{ std::byte _[500]; co_await coro_2(); }
{ std::byte _[500]; co_await coro_2(); }
The size of coro_1's frame is now 3408 - all of the variables are allocated
separately, even though they cannot be alive at the same time.
I would not call this a missed optimization - this seems like something that
should work on -O0, by using a smarter allocation scheme for the coroutine
frame.
[Bug tree-optimization/105726] [10/11 Regression] spurious warning with -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105726 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:55ea76600843498048158ec08a661fe7f0c7bcb0 commit r10-10844-g55ea76600843498048158ec08a661fe7f0c7bcb0 Author: Richard Biener Date: Wed May 25 11:49:03 2022 +0200 tree-optimization/105726 - adjust array bound heuristic There's heuristic to detect ptr[1].a[...] out of bound accesses reasoning that if ptr points to an array of aggregates a trailing incomplete array has to have size zero. The following more thoroughly constrains the cases this applies to avoid false positive diagnostics. 2022-05-25 Richard Biener PR tree-optimization/105726 * gimple-ssa-warn-restrict.c (builtin_memref::set_base_and_offset): Constrain array-of-flexarray case more. * g++.dg/warn/Warray-bounds-27.C: New testcase. (cherry picked from commit e7c482b08076bb299742883c4ffd65b31e33200c)
[Bug tree-optimization/105726] [10/11 Regression] spurious warning with -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105726 Richard Biener changed: What|Removed |Added Known to work||10.3.1, 11.3.1 Known to fail|10.3.1 |10.3.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Richard Biener --- Fixed.
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 105726, which changed state. Bug 105726 Summary: [10/11 Regression] spurious warning with -Warray-bounds https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105726 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c/105977] [12/13 Regression] ICE in gimple_call_static_chain_flags, at gimple.cc:1636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105977 --- Comment #2 from hubicka at kam dot mff.cuni.cz --- Inline transform function does fixup_cfg and other mandatory things so disabling it will likely cause other kind of ICEs as well. I wonder if there is more robust way to do so (one can make these part of all_ipa_tranforms and not part of a pass but it looks bit ugly).
[Bug tree-optimization/105973] Wrong branch prediction for if (COND) { if(x) noreturn1(); else noreturn2(); }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105973 --- Comment #4 from hubicka at kam dot mff.cuni.cz --- > possibly the noreturn predictor doesn't trigger here The problem here is that we handle throw1 and throw2 as two independent reason for code path to be unlikely. This makes us to look for conditional controling the code path and we predict the inner if both ways as unlikely so they cancel out. I suppose we could be smarter here and teach path predictor to check for this situation and if both directions of a branch are considered bad for same reason continue propagating up. This shoudl not be hard to implement.
[Bug tree-optimization/105940] suggested_unroll_factor applying place looks wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105940 --- Comment #5 from CVS Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:2636660b6f35423e0cfbf53bfad5c5fed6ae6471 commit r13-1103-g2636660b6f35423e0cfbf53bfad5c5fed6ae6471 Author: Richard Sandiford Date: Wed Jun 15 11:12:51 2022 +0100 aarch64: Revert bogus fix for PR105254 In f2ebf2d98efe0ac2314b58cf474f44cb8ebd5244 I'd forced the chosen unroll factor to be a factor of the VF, in order to work around an exact_div ICE in PR105254. This was completely bogus -- clearly I didn't look in enough detail at why we ended up with an unrolled VF that wasn't a multiple of the UF. Kewen has since fixed the bug properly for PR105940, so this patch reverts my earlier attempt. Sorry for the stupidity. gcc/ PR tree-optimization/105254 PR tree-optimization/105940 Revert: * config/aarch64/aarch64.cc (aarch64_vector_costs::determine_suggested_unroll_factor): Take a loop_vec_info as argument. Restrict the unroll factor to values that divide the VF. (aarch64_vector_costs::finish_cost): Update call accordingly. gcc/testsuite/ * gcc.target/aarch64/sve/cost_model_14.c: New test.
[Bug tree-optimization/105254] ICE in exact_div, at poly-int.h:2219
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105254 --- Comment #6 from CVS Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:2636660b6f35423e0cfbf53bfad5c5fed6ae6471 commit r13-1103-g2636660b6f35423e0cfbf53bfad5c5fed6ae6471 Author: Richard Sandiford Date: Wed Jun 15 11:12:51 2022 +0100 aarch64: Revert bogus fix for PR105254 In f2ebf2d98efe0ac2314b58cf474f44cb8ebd5244 I'd forced the chosen unroll factor to be a factor of the VF, in order to work around an exact_div ICE in PR105254. This was completely bogus -- clearly I didn't look in enough detail at why we ended up with an unrolled VF that wasn't a multiple of the UF. Kewen has since fixed the bug properly for PR105940, so this patch reverts my earlier attempt. Sorry for the stupidity. gcc/ PR tree-optimization/105254 PR tree-optimization/105940 Revert: * config/aarch64/aarch64.cc (aarch64_vector_costs::determine_suggested_unroll_factor): Take a loop_vec_info as argument. Restrict the unroll factor to values that divide the VF. (aarch64_vector_costs::finish_cost): Update call accordingly. gcc/testsuite/ * gcc.target/aarch64/sve/cost_model_14.c: New test.
[Bug tree-optimization/105973] Wrong branch prediction for if (COND) { if(x) noreturn1(); else noreturn2(); }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105973
--- Comment #5 from Jonathan Wakely ---
If the two noreturn functions are replaced with throwing exceptions, I get the
behaviour I expect:
if (n > (__PTRDIFF_MAX__ / sizeof(T)))
{
if (n > (__SIZE_MAX__ / sizeof(T)))
throw 1;
throw 2L;
}
This is correctly treated as unlikely. So the problem only seems to happen
because of libstdc++'s convention of using named noreturn functions to throw
exceptions (which is done to simplify -fno-exceptions cases). This probably
doesn't affect much user code.
It also seem that if I explicitly add the 'cold' attribute to those noreturn
functions, I get the behaviour I expect.
So maybe it's not worth spending any effort on this, and I should just change
__attribute__((__noreturn__)) to __attribute__((__noreturn__,__cold)) for every
function in libstdc++-v3/include/bits/functexcept.h
[Bug target/105975] OpenMP/nvptx offloading: 'internal compiler error: in maybe_legitimize_operand, at optabs.cc:7785'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105975 rsandifo at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Last reconfirmed||2022-06-15 --- Comment #4 from rsandifo at gcc dot gnu.org --- Thanks for the reproducer.
[Bug c/105969] [12/13 Regression] ICE in Floating point exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105969 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:edb9330c29fe8a0a0b76df6fafd6a223a4d0e41f commit r13-1105-gedb9330c29fe8a0a0b76df6fafd6a223a4d0e41f Author: Richard Biener Date: Wed Jun 15 10:54:48 2022 +0200 tree-optimization/105969 - FPE with array diagnostics For a [0][0] array we have to be careful when dividing by the element size which is zero for the outermost dimension. Luckily the division is only for an overflow check which is pointless for array size zero. 2022-06-15 Richard Biener PR tree-optimization/105969 * gimple-ssa-sprintf.cc (get_origin_and_offset_r): Avoid division by zero in overflow check. * gcc.dg/pr105969.c: New testcase.
[Bug tree-optimization/105971] [12/13 Regression] ICE in bitmap_check_index, at sbitmap.h:104
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105971 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:8c2733e16ec1c0cdda3db4cdc5ad158a96a658e8 commit r13-1106-g8c2733e16ec1c0cdda3db4cdc5ad158a96a658e8 Author: Richard Biener Date: Wed Jun 15 11:27:31 2022 +0200 tree-optimization/105971 - less surprising refs_may_alias_p_2 When DSE asks whether __real a is using __imag a it gets a surprising result when a is a FUNCTION_DECL. The following makes sure this case is less surprising to callers but keeping the bail-out for the non-decl case where it is true that PTA doesn't track aliases to code correctly. 2022-06-15 Richard Biener PR tree-optimization/105971 * tree-ssa-alias.cc (refs_may_alias_p_2): Put bail-out for FUNCTION_DECL and LABEL_DECL refs after decl-decl disambiguation to leak less surprising alias results. * gcc.dg/torture/pr106971.c: New testcase.
[Bug tree-optimization/105971] [12 Regression] ICE in bitmap_check_index, at sbitmap.h:104
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105971 Richard Biener changed: What|Removed |Added Summary|[12/13 Regression] ICE in |[12 Regression] ICE in |bitmap_check_index, at |bitmap_check_index, at |sbitmap.h:104 |sbitmap.h:104 Known to work||13.0 --- Comment #3 from Richard Biener --- Fixed on trunk sofar.
[Bug middle-end/105984] [13 Regression] wrong code with __builtin_mul_overflow_p() at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105984 --- Comment #2 from Jakub Jelinek --- Created attachment 53143 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53143&action=edit gcc13-pr105984.patch Untested fix.
[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950 --- Comment #27 from John Kanapes --- Hi, I have uploaded my sources to https://www.dropbox.com/s/ao4l5h62h3paujq/test.tgz?dl=0 It is a tar.gzip archive. Expands to a test directory with flat files (10) and 1 Makefile. Main executable is capture. In Ubuntu 20.04 you will also need to install: sudo apt-get install flex sudo apt-get install libuhd3.15 sudo apt-get install libuhd-dev uhd is the ettus driver for their usrp radio. You don't need the radio for the test. Makefile provides 3 targets: (exec), db, clean exec: make without arguments will build capture with -O3 to test bug db: builds capture with gdb flags and without any optimizations clean: cleans all intermediate files and executables Problem reproduction: capture -h Expected response: SIGILL core if built with (exec) Syntax and arguments if built with debug Plz let me know when you have downloaded it, so that I can block the shared link. I can help with all installation and problem reproduction. I will appreciate it, if you can reduce the code before publishing it to a smaller part that can trigger the problem. Gl John
[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950 --- Comment #28 from Jakub Jelinek --- Can't reproduce, neither with gcc 9.5 nor gcc 12.1. You are using -mavx2, are you sure you have AVX2 ISA on the box you're running it?
[Bug middle-end/105860] Miscompilation causing clobbered union contents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105860 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |WAITING Last reconfirmed||2022-06-15 --- Comment #1 from Martin Liška --- Can you please contact a self-contained test case (that contains an assert or so) that I can run?
[Bug preprocessor/105732] [10/11 Regression] internal compiler error: unspellable token PADDING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732 --- Comment #21 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:49e320ac0792672e2137ca47215fd7f935302895 commit r11-10072-g49e320ac0792672e2137ca47215fd7f935302895 Author: Jakub Jelinek Date: Sun May 29 21:57:51 2022 +0200 libcpp: Ignore CPP_PADDING tokens in _cpp_parse_expr [PR105732] The first part of the following testcase (m1-m3 macros and its use) regressed with my PR89971 fix, but as the m1,m4-m5 and its use part shows, the problem isn't new, we can emit a CPP_PADDING token to avoid it from being adjacent to whatever comes after the __VA_OPT__ (in this case there is nothing afterwards, true). In most cases these CPP_PADDING tokens don't matter, all other callers of cpp_get_token_with_location either ignore CPP_PADDING tokens completely (e.g. c_lex_with_flags) or they just remember them and take them into account when printing stuff whether there should be added whitespace or not (scan_translation_unit + token_streamer::stream). So, I think we should just ignore CPP_PADDING tokens the same way in _cpp_parse_expr. 2022-05-27 Jakub Jelinek PR preprocessor/105732 * expr.c (_cpp_parse_expr): Handle CPP_PADDING by just another token. * c-c++-common/cpp/va-opt-10.c: New test. (cherry picked from commit 58a40e76ebadce78639644cd3d56e42b68336927)
[Bug middle-end/105860] Miscompilation causing clobbered union contents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105860 --- Comment #2 from John Hodge --- Created attachment 53144 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53144&action=edit Reproduction, partially minimised and including assertion Attached is an updated reproduction, that includes asserts. This fails the assert when compiled with gcc 10.3.0-1ubuntu1~20.04 when -O1 is passed, and passes when no optimisation is enabled. (Platform is x86_64, in case that wasn't already obvious from the disassembly)
[Bug preprocessor/105732] [10/11 Regression] internal compiler error: unspellable token PADDING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732 --- Comment #22 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b2f5dc82400fe04511b85caa8c80677f81eee415 commit r10-10846-gb2f5dc82400fe04511b85caa8c80677f81eee415 Author: Jakub Jelinek Date: Sun May 29 21:57:51 2022 +0200 libcpp: Ignore CPP_PADDING tokens in _cpp_parse_expr [PR105732] The first part of the following testcase (m1-m3 macros and its use) regressed with my PR89971 fix, but as the m1,m4-m5 and its use part shows, the problem isn't new, we can emit a CPP_PADDING token to avoid it from being adjacent to whatever comes after the __VA_OPT__ (in this case there is nothing afterwards, true). In most cases these CPP_PADDING tokens don't matter, all other callers of cpp_get_token_with_location either ignore CPP_PADDING tokens completely (e.g. c_lex_with_flags) or they just remember them and take them into account when printing stuff whether there should be added whitespace or not (scan_translation_unit + token_streamer::stream). So, I think we should just ignore CPP_PADDING tokens the same way in _cpp_parse_expr. 2022-05-27 Jakub Jelinek PR preprocessor/105732 * expr.c (_cpp_parse_expr): Handle CPP_PADDING by just another token. * c-c++-common/cpp/va-opt-10.c: New test. (cherry picked from commit 58a40e76ebadce78639644cd3d56e42b68336927)
[Bug preprocessor/105732] [10/11 Regression] internal compiler error: unspellable token PADDING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #23 from Jakub Jelinek --- Fixed even for 10.4 and 11.4.
[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950 --- Comment #29 from John Kanapes --- Thx for trying it so fast. I assume you have downloaded it, and no longer need the link:) I have no problem with the -mavx2 option. I have gcc 9.4.0, though. Have you tried it with it?
[Bug tree-optimization/105983] Failure to optimize (b != 0) && (a >= b) as well as the same pattern with binary and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105983
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
On generic, what opimizes this is:
/* y == XXX_MIN || x < y --> x <= y - 1 */
(simplify
(bit_ior:c (eq:s @1 min_value) (lt:s @0 @1))
(if (INTEGRAL_TYPE_P (TREE_TYPE (@1))
&& TYPE_OVERFLOW_WRAPS (TREE_TYPE (@1)))
(le @0 (minus @1 { build_int_cst (TREE_TYPE (@1), 1); }
/* y != XXX_MIN && x >= y --> x > y - 1 */
(simplify
(bit_and:c (ne:s @1 min_value) (ge:s @0 @1))
(if (INTEGRAL_TYPE_P (TREE_TYPE (@1))
&& TYPE_OVERFLOW_WRAPS (TREE_TYPE (@1)))
(gt @0 (minus @1 { build_int_cst (TREE_TYPE (@1), 1); }
in match.pd when & is used instead of &&.
[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950 --- Comment #30 from John Kanapes --- I checked without the -mavx2 option, and it worked with -O3 optimization, even with gcc 9.4.0:) It seems that whatever problem is related to that option. Have you tried it with -mavx2 option in 9.5 and 12.1?
[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950 --- Comment #31 from Sam James --- What CPU do you have?
[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950 --- Comment #32 from John Kanapes --- AMD FX(tm)-8320 Eight-Core Processor
[Bug fortran/78492] [OOP] Compiler segfault with non_overridable function in generic interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78492 --- Comment #5 from federico --- Created attachment 53145 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53145&action=edit test program: call non_overridable function from generic interface within polymorphic procedure
[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950 --- Comment #33 from Sam James --- As far as I can tell, that CPU might have AVX, but not AVX2.
[Bug fortran/78492] [OOP] Compiler segfault with non_overridable function in generic interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78492 --- Comment #6 from federico --- I've attached a simple test program that confirms ICE on gfortran 11.3.0. ICE is returned only if - the non_overridable procedure is part of a generic type-bound interface - that same generic is being called from another type-bound procedure
[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950 --- Comment #34 from John Kanapes --- You must be right. I checked in the web and found one more reference that says it has only avx acceleration...
[Bug ipa/105917] [10/11/12/13 regression] Missed passthru jump function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105917 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-06-15 --- Comment #2 from Martin Liška --- Started with introduction of IPA SRA r10-3311-gff6686d2e5f797d6.
[Bug target/105974] [13 Regression] ICE: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in arm_bfi_1_p, at config/arm/arm.cc:10214
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105974 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:dc8071da0e89eab4935751f3b16745c95cbc0d30 commit r13-1108-gdc8071da0e89eab4935751f3b16745c95cbc0d30 Author: Richard Earnshaw Date: Wed Jun 15 13:42:23 2022 +0100 arm: fix thinko in arm_bfi_1_p() [PR105974] I clearly wasn't thinking straight when I wrote the arm_bfi_1_p function and used XUINT rather than UINTVAL when extracting CONST_INT values. It seemed to work in testing, but was incorrect and failed RTL checking. Fixed thusly: gcc/ChangeLog: PR target/105974 * config/arm/arm.cc (arm_bfi_1_p): Use UINTVAL instead of XUINT.
[Bug target/105974] [13 Regression] ICE: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in arm_bfi_1_p, at config/arm/arm.cc:10214
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105974 Richard Earnshaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Earnshaw --- Fixed
[Bug target/105870] Asan cannot work correctly for RISC-V GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105870 --- Comment #7 from JUN SHA --- Ping.
[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950 --- Comment #35 from John Kanapes --- Changed all my Makefiles to use -mavx acceleration...
[Bug middle-end/105860] [10/11/12/13 Regression] Miscompilation causing clobbered union contents since r10-918-gc56c86024f8fba0c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105860 Martin Liška changed: What|Removed |Added Keywords||wrong-code Status|WAITING |NEW CC||jamborm at gcc dot gnu.org Summary|Miscompilation causing |[10/11/12/13 Regression] |clobbered union contents|Miscompilation causing ||clobbered union contents ||since ||r10-918-gc56c86024f8fba0c Assignee|dmalcolm at gcc dot gnu.org|unassigned at gcc dot gnu.org --- Comment #3 from Martin Liška --- Oh, great, thanks for it! It started with Martin's r10-918-gc56c86024f8fba0c.
[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950 --- Comment #36 from John Kanapes --- That's great news. Thank you so much:) I have to ask: How did you come up with avx? You couldn't even reproduce the problem in your new gccs on newer cpus... I could live with a little better gcc reporting (no SIGILL), but I am very happy with this. Do you need anything more from me?
[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950 Jakub Jelinek changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #37 from Jakub Jelinek --- User error.
[Bug analyzer/105962] Unhelpful diagnostics paths from analyzer in the face of inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105962 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2022-06-15 --- Comment #1 from David Malcolm --- I'm testing a patch for this
[Bug target/105981] Wrong code generated when compiling for arm cortex-a72 in AARCH32 with -mbig-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105981 Richard Earnshaw changed: What|Removed |Added Last reconfirmed||2022-06-15 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Richard Earnshaw --- Confirmed. Looking at the sources, I think this has been broken since r230663.
[Bug tree-optimization/105983] Failure to optimize (b != 0) && (a >= b) as well as the same pattern with binary and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105983
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Status|NEW |ASSIGNED
--- Comment #4 from Jakub Jelinek ---
--- gcc/match.pd.jj 2022-06-15 12:52:04.640981511 +0200
+++ gcc/match.pd2022-06-15 15:28:55.916225336 +0200
@@ -2379,14 +2379,14 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
/* y == XXX_MIN || x < y --> x <= y - 1 */
(simplify
- (bit_ior:c (eq:s @1 min_value) (lt:s @0 @1))
+ (bit_ior:c (eq:s @1 min_value) (lt:cs @0 @1))
(if (INTEGRAL_TYPE_P (TREE_TYPE (@1))
&& TYPE_OVERFLOW_WRAPS (TREE_TYPE (@1)))
(le @0 (minus @1 { build_int_cst (TREE_TYPE (@1), 1); }
/* y != XXX_MIN && x >= y --> x > y - 1 */
(simplify
- (bit_and:c (ne:s @1 min_value) (ge:s @0 @1))
+ (bit_and:c (ne:s @1 min_value) (ge:cs @0 @1))
(if (INTEGRAL_TYPE_P (TREE_TYPE (@1))
&& TYPE_OVERFLOW_WRAPS (TREE_TYPE (@1)))
(gt @0 (minus @1 { build_int_cst (TREE_TYPE (@1), 1); }
fixes this.
[Bug tree-optimization/105990] New: Dead code elimination failed at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105990
Bug ID: 105990
Summary: Dead code elimination failed at -O3
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
static struct { int a; } b, c;
static int d = -1;
void foo();
int main() {
if (b.a)
d = 2 | (b.a <= 0);
for (; b.a; b.a++)
c = b;
if (!d)
foo();
}
foo() can be eliminated since d would never be zero.
[Bug tree-optimization/105990] Dead code elimination failed at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105990
--- Comment #1 from Hongtao.liu ---
Another case
static short a;
static int b;
void foo(void);
void bar9_(void);
int main() {
char c;
b = a = 23;
for (; b <= 1;)
a = 1;
bar9_();
c = a >= 18 || 2 > 2 >> a ? 1 : 1 << a;
if (c == 0)
foo();
}
foo() also can be eliminated.
[Bug target/105981] [10/11/12/13 regression] Wrong code from gen_cpymem_ldrd_strd() with -mbig-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105981 Richard Earnshaw changed: What|Removed |Added Target Milestone|--- |10.5 Summary|Wrong code generated when |[10/11/12/13 regression] |compiling for arm |Wrong code from |cortex-a72 in AARCH32 with |gen_cpymem_ldrd_strd() with |-mbig-endian|-mbig-endian
[Bug target/105938] [12/13 Regression] ICE in get_insn_temp late, at final.cc:2050 on nvptx-none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105938 Matthias Klose changed: What|Removed |Added Keywords|needs-bisection | CC||rguenth at gcc dot gnu.org --- Comment #2 from Matthias Klose --- triggered by the fix for PR middle-end/105537, a53eff4ad05f234a509dd2995d5a7612d5baa4e8
[Bug target/105938] [12/13 Regression] ICE in get_insn_temp late, at final.cc:2050 on nvptx-none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105938 --- Comment #3 from Richard Biener --- That had a followup fix for nvptx, r13-285-ge7d9fdf5e0ee4c, which wasn't backported yet it seems?
[Bug tree-optimization/105983] Failure to optimize (b != 0) && (a >= b) as well as the same pattern with binary and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105983
--- Comment #5 from Richard Earnshaw ---
(In reply to Jakub Jelinek from comment #4)
> --- gcc/match.pd.jj 2022-06-15 12:52:04.640981511 +0200
> +++ gcc/match.pd 2022-06-15 15:28:55.916225336 +0200
> @@ -2379,14 +2379,14 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>
> /* y == XXX_MIN || x < y --> x <= y - 1 */
> (simplify
> - (bit_ior:c (eq:s @1 min_value) (lt:s @0 @1))
> + (bit_ior:c (eq:s @1 min_value) (lt:cs @0 @1))
>(if (INTEGRAL_TYPE_P (TREE_TYPE (@1))
> && TYPE_OVERFLOW_WRAPS (TREE_TYPE (@1)))
>(le @0 (minus @1 { build_int_cst (TREE_TYPE (@1), 1); }
>
> /* y != XXX_MIN && x >= y --> x > y - 1 */
> (simplify
> - (bit_and:c (ne:s @1 min_value) (ge:s @0 @1))
> + (bit_and:c (ne:s @1 min_value) (ge:cs @0 @1))
>(if (INTEGRAL_TYPE_P (TREE_TYPE (@1))
> && TYPE_OVERFLOW_WRAPS (TREE_TYPE (@1)))
>(gt @0 (minus @1 { build_int_cst (TREE_TYPE (@1), 1); }
>
> fixes this.
But doesn't that regress
bool f(unsigned a, unsigned b)
{
return (b != 0) & (a >= b);
}
[Bug tree-optimization/105983] Failure to optimize (b != 0) && (a >= b) as well as the same pattern with binary and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105983
--- Comment #6 from Richard Earnshaw ---
(In reply to Richard Earnshaw from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > --- gcc/match.pd.jj 2022-06-15 12:52:04.640981511 +0200
> > +++ gcc/match.pd2022-06-15 15:28:55.916225336 +0200
> > @@ -2379,14 +2379,14 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> >
> > /* y == XXX_MIN || x < y --> x <= y - 1 */
> > (simplify
> > - (bit_ior:c (eq:s @1 min_value) (lt:s @0 @1))
> > + (bit_ior:c (eq:s @1 min_value) (lt:cs @0 @1))
> >(if (INTEGRAL_TYPE_P (TREE_TYPE (@1))
> > && TYPE_OVERFLOW_WRAPS (TREE_TYPE (@1)))
> >(le @0 (minus @1 { build_int_cst (TREE_TYPE (@1), 1); }
> >
> > /* y != XXX_MIN && x >= y --> x > y - 1 */
> > (simplify
> > - (bit_and:c (ne:s @1 min_value) (ge:s @0 @1))
> > + (bit_and:c (ne:s @1 min_value) (ge:cs @0 @1))
> >(if (INTEGRAL_TYPE_P (TREE_TYPE (@1))
> > && TYPE_OVERFLOW_WRAPS (TREE_TYPE (@1)))
> >(gt @0 (minus @1 { build_int_cst (TREE_TYPE (@1), 1); }
> >
> > fixes this.
>
> But doesn't that regress
>
> bool f(unsigned a, unsigned b)
> {
> return (b != 0) & (a >= b);
> }
Ignore that - I'm confusing reports.
[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950 --- Comment #38 from John Kanapes --- (In reply to Jakub Jelinek from comment #37) > User error. True. But gcc should complain and handle user errors, not crash with SIGILL:(
[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950 --- Comment #39 from Jakub Jelinek --- GCC didn't crash with SIGILL. GCC was asked to compile a program with AVX2 instruction set, it has done that. When such a program is run on a hardware that doesn't support some of its instructions, it is termined by the SIGILL signal by the kernel, as hardware raises an exception that there is unknown instruction. What do you expect could GCC done about that?
[Bug tree-optimization/105983] Failure to optimize (b != 0) && (a >= b) as well as the same pattern with binary and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105983 --- Comment #7 from Jakub Jelinek --- Created attachment 53146 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53146&action=edit gcc13-pr105983.patch Full untested patch.
[Bug target/105981] [10/11/12/13 regression] Wrong code from gen_cpymem_ldrd_strd() with -mbig-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105981 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:8aaa948059a8b5f0a62ad010d0aa6346b7ac9cd3 commit r13-1110-g8aaa948059a8b5f0a62ad010d0aa6346b7ac9cd3 Author: Richard Earnshaw Date: Wed Jun 15 16:07:20 2022 +0100 arm: big-endian issue in gen_cpymem_ldrd_strd [PR105981] The code in gen_cpymem_ldrd_strd has been incorrect for big-endian since r230663. The problem is that we use gen_lowpart, etc. to split the 64-bit quantity, but fail to account for the fact that these routines are really dealing with 64-bit /values/ and in big-endian the ordering of the sub-registers changes. To fix this, I've renamed the conceptually misnamed low_reg and hi_reg as first_reg and second_reg, and then used different logic for big-endian targets to initialize these values. This makes the logic clearer than trying to think about high bits and low bits. gcc/ChangeLog: PR target/105981 * config/arm/arm.cc (gen_cpymem_ldrd_strd): Rename low_reg and hi_reg to first_reg and second_reg respectively. Initialize them correctly when generating big-endian code.
[Bug target/105981] [10/11/12 regression] Wrong code from gen_cpymem_ldrd_strd() with -mbig-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105981 Richard Earnshaw changed: What|Removed |Added Summary|[10/11/12/13 regression]|[10/11/12 regression] Wrong |Wrong code from |code from |gen_cpymem_ldrd_strd() with |gen_cpymem_ldrd_strd() with |-mbig-endian|-mbig-endian --- Comment #3 from Richard Earnshaw --- Fixed on trunk so far.
[Bug c/105969] [12 Regression] ICE in Floating point exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105969 --- Comment #3 from joseph at codesourcery dot com --- Overlapping elements is simply a consequence of the zero-sized-objects extension, I don't see anything invalid here to reject (though there might be undefined behavior at runtime when sprintf accesses bytes beyond the zero-sized object; even if char a[0][0][0] is treated like a flexible array member, it's not clear a flexible array member whose elements themselves have zero size can be validly used to access any bytes).
[Bug target/105975] OpenMP/nvptx offloading: 'internal compiler error: in maybe_legitimize_operand, at optabs.cc:7785'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105975 --- Comment #5 from CVS Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:9d2fe6d427b37755410bb4eb4ecce8382f2ebfc5 commit r13--g9d2fe6d427b37755410bb4eb4ecce8382f2ebfc5 Author: Richard Sandiford Date: Wed Jun 15 17:40:09 2022 +0100 Revert recent internal-fn changes [PR105975] The recent internal-fn âclean-upsâ triggered problems on nvptx because some of the omp_simt_* patterns had modeless operands. I wondered about adapting expand_fn_using_insn to cope with that, but then the problem becomes: what should the mode of operand 0 be when there is no lhs? The answer depends on the target insn. For GOMP_SIMT_ENTER_ALLOC the answer was: use Pmode. For GOMP_SIMT_ORDERED_PRED and others the answer was: elide the call. (However, GOMP_SIMT_ORDERED_PRED doesn't seem to have ECF_* flags that would normally allow it to be dropped at the gimple level.) So these instructions seem to be special enough that they need their own code after all. This patch reverts the second patch and most of the first. The only part retained from the first is splitting expand_fn_using_insn out of expand_direct_optab_fn, since I think expand_fn_using_insn could still be useful in future. gcc/ PR middle-end/105975 Revert everything apart from the expand_fn_using_insn and expand_direct_optab_fn changes from: * internal-fn.def (DEF_INTERNAL_INSN_FN): New macro. (GOMP_SIMT_ENTER_ALLOC, GOMP_SIMT_EXIT, GOMP_SIMT_LANE) (GOMP_SIMT_LAST_LANE, GOMP_SIMT_ORDERED_PRED, GOMP_SIMT_VOTE_ANY) (GOMP_SIMT_XCHG_BFLY, GOMP_SIMT_XCHG_IDX): Use it. * internal-fn.h (direct_internal_fn_info::directly_mapped): New member variable. (direct_internal_fn_info::vectorizable): Reduce to 1 bit. (direct_internal_fn_p): Also return true for internal functions that map directly to instructions defined target-insns.def. (direct_internal_fn): Adjust comment accordingly. * internal-fn.cc (direct_insn, optab1, optab2, vectorizable_optab1) (vectorizable_optab2): New local macros. (not_direct): Initialize directly_mapped. (mask_load_direct, load_lanes_direct, mask_load_lanes_direct) (gather_load_direct, len_load_direct, mask_store_direct) (store_lanes_direct, mask_store_lanes_direct, vec_cond_mask_direct) (vec_cond_direct, scatter_store_direct, len_store_direct) (vec_set_direct, unary_direct, binary_direct, ternary_direct) (cond_unary_direct, cond_binary_direct, cond_ternary_direct) (while_direct, fold_extract_direct, fold_left_direct) (mask_fold_left_direct, check_ptrs_direct): Use the macros above. (expand_GOMP_SIMT_ENTER_ALLOC, expand_GOMP_SIMT_EXIT): Delete (expand_GOMP_SIMT_LANE, expand_GOMP_SIMT_LAST_LANE): Likewise; (expand_GOMP_SIMT_ORDERED_PRED, expand_GOMP_SIMT_VOTE_ANY): Likewise. (expand_GOMP_SIMT_XCHG_BFLY, expand_GOMP_SIMT_XCHG_IDX): Likewise. (direct_internal_fn_types): Handle functions that map to instructions defined in target-insns.def. (direct_internal_fn_types): Likewise. (direct_internal_fn_supported_p): Likewise. (internal_fn_expanders): Likewise. (expand_fn_using_insn): New function, split out and adapted from... (expand_direct_optab_fn): ...here. (expand_GOMP_SIMT_ENTER_ALLOC): Use it. (expand_GOMP_SIMT_EXIT): Likewise. (expand_GOMP_SIMT_LANE): Likewise. (expand_GOMP_SIMT_LAST_LANE): Likewise. (expand_GOMP_SIMT_ORDERED_PRED): Likewise. (expand_GOMP_SIMT_VOTE_ANY): Likewise. (expand_GOMP_SIMT_XCHG_BFLY): Likewise. (expand_GOMP_SIMT_XCHG_IDX): Likewise.
[Bug target/105975] OpenMP/nvptx offloading: 'internal compiler error: in maybe_legitimize_operand, at optabs.cc:7785'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105975 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from rsandifo at gcc dot gnu.org --- Should be fixed now.
[Bug target/105991] New: rldicl+sldi+add generated instead of rldimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105991
Bug ID: 105991
Summary: rldicl+sldi+add generated instead of rldimi
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
Starting with r12-2731-g96146e61cd7aee, this code (on ppc64le)
unsigned long long
foo (unsigned long long value)
{
value &= 0x;
value |= value << 32;
return value;
}
compiled with -O2 generates
rldicl 9,3,0,32
sldi 3,3,32
add 3,3,9
blr
while previously it was just
rldimi 3,3,32,0
blr
It doesn't look like a wrong code problem, but it seems more optimal to use
rldimi (rotate left, mask insert) rather than rotate left by 0 bits, AND with a
mask, shift left, and add.
[Bug target/105991] [12/13 Regression] rldicl+sldi+add generated instead of rldimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105991 Marek Polacek changed: What|Removed |Added Host||powerpc64le-unknown-linux-g ||nu Target||powerpc64le-unknown-linux-g ||nu Summary|rldicl+sldi+add generated |[12/13 Regression] |instead of rldimi |rldicl+sldi+add generated ||instead of rldimi Target Milestone|--- |12.2 CC||sayle at gcc dot gnu.org
[Bug c++/105989] Coroutine frame space for temporaries in a co_await expression is not reused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105989
--- Comment #2 from Michal Jankovič ---
Reading through gcc/cp/coroutines.cc, it seems like the coroutine frame is
indeed composed as a flat struct with fields for all the local variables,
temps, and special stuff needed by the actor.
Relevant code:
coro_make_frame_entry - adds a field to the coro_frame_type structure.
register_local_var_uses - here coro_make_frame_entry is called for each local
variable.
morph_fn_to_coro - here the coro_frame_type structure definition is created
from the collected fields.
Comments in the code state that the mid-end should be able to optimize out
unused fields from this struct, which currently does not happen, but even if it
did, this does not solve the overlapping of variables.
I think that instead of a flat struct, the frontend should generate a structure
recursively composed of unions of structures, having a union for each disjunct
scope (including an implicit scope for expression temporaries).
Example:
task task_1() {
{
char a[128];
co_await task_2();
}
{
char b[128];
co_await task_3(get_temporary());
static awaiter awaiter_not_stored_in_frame;
co_await awaiter_not_stored_in_frame;
}
}
Currently, this generates a coro frame struct that looks something like this:
struct coro_frame {
// builtin state ...
char a[128];
awaiter task_2_awaiter;
char b[128];
int get_temporary_result;
awaiter task_3_awaiter;
awaiter* awaiter_not_stored_in_frame;
};
Instead, the frontend could generate something like this:
struct coro_frame {
// builtin state ...
union {
struct {
char a[128];
awaiter task_2_awaiter;
};
struct {
char b[128];
union {
struct {
int get_temporary_result;
awaiter task_3_awaiter;
};
struct { awaiter* awaiter_not_stored_in_frame; };
};
};
};
};
[Bug target/105992] New: memcmp(p, q, 7) == 0 can be optimized better on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105992
Bug ID: 105992
Summary: memcmp(p, q, 7) == 0 can be optimized better on x86
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
bool eq( char const* p )
{
return __builtin_memcmp( p, "literal", 7 ) == 0;
}
generates
eq(char const*):
cmp DWORD PTR [rdi], 1702127980
je .L6
.L2:
mov eax, 1
testeax, eax
seteal
ret
.L6:
xor eax, eax
cmp DWORD PTR [rdi+3], 1818325605
jne .L2
testeax, eax
seteal
ret
(https://godbolt.org/z/68MKqGz9T)
but LLVM does
eq(char const*): # @eq(char const*)
mov eax, 1702127980
xor eax, dword ptr [rdi]
mov ecx, 1818325605
xor ecx, dword ptr [rdi + 3]
or ecx, eax
seteal
ret
(https://godbolt.org/z/jxcb85Ysa)
There are similar bugs for ARM
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104611) and AVX512
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104610) but I haven't found one
for vanilla x86.
Recent changes to std::string::operator== make it use the above pattern:
https://godbolt.org/z/8KxqqG9cx
[Bug libstdc++/105717] [10/11/12/13 Regression] cannot create unordered_map from range of types convertible to value_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105717 François Dumont changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|10.4|13.0 CC||fdumont at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |fdumont at gcc dot gnu.org --- Comment #1 from François Dumont --- libstdc++: [_Hashtable] Insert range of types convertible to value_type PR 105717 Fix insertion of range of instances convertible to value_type. libstdc++-v3/ChangeLog: PR libstdc++/105717 * include/bits/hashtable_policy.h (_ConvertToValueType): New. * include/bits/hashtable.h (_Hashtable<>::_M_insert_unique_aux): New. (_Hashtable<>::_M_insert(_Arg&&, const _NodeGenerator&, true_type)): Use latters. (_Hashtable<>::_M_insert(_Arg&&, const _NodeGenerator&, false_type)): Likewise. (_Hashtable(_InputIterator, _InputIterator, size_type, const _Hash&, const _Equal&, const allocator_type&, true_type)): Use this.insert range. (_Hashtable(_InputIterator, _InputIterator, size_type, const _Hash&, const _Equal&, const allocator_type&, false_type)): Use _M_insert. * testsuite/23_containers/unordered_map/cons/56112.cc: Check how many times conversion is done. * testsuite/23_containers/unordered_map/insert/105717.cc: New test. * testsuite/23_containers/unordered_set/insert/105717.cc: New test.
[Bug c/105923] unsupported return type ‘complex double’ for simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105923 --- Comment #7 from H.J. Lu --- (In reply to Hongtao.liu from comment #6) > > .L3: > > subl%r13d, %r12d > > cmpl$1, %r12d > > je .L6 > > salq$4, %r13 > > vmovapd a(%r13), %xmm0 > > call_ZGVbN2v_foo > > vmovapd %xmm0, b(%r13) > > hmm, xmm version should be abandoned since it's just 1 complex double. If there is an XMM version of a vector complex, will it be faster than passing complex double as a struct in 2 registers.
[Bug fortran/105986] ICE in gfc_convert_mpz_to_signed, at fortran/simplify.cc:193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105986 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- Created attachment 53147 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53147&action=edit Tentative patch We need to check the 'pos' argument in simplification. Testing the attached patch.
[Bug fortran/105986] ICE in gfc_convert_mpz_to_signed, at fortran/simplify.cc:193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105986 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-06-15
[Bug target/105599] g++ by itself is not producing "fatal error: no input files" for darwin target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105599 --- Comment #5 from CVS Commits --- The releases/gcc-12 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:58c0bc2b62cdbbe9d9677b448fe52a8c54044276 commit r12-8484-g58c0bc2b62cdbbe9d9677b448fe52a8c54044276 Author: Iain Sandoe Date: Sun May 29 16:14:32 2022 +0100 Darwin: Fix empty g++ command lines [PR105599]. An empty g++ command line should produce a diagnostic that there are no inputs. The PR is that currently Darwin produces a dignostic about missing link items instead - this is because (errnoeously), for this driver, we are creating a link job for empty command lines. The problem occurs in four stages: The g++ driver appends -shared-libgcc to the command line. The Darwin driver_init code in the backend does not see this (it sees an empty command line). When the back end driver code driver sees an empty command line, it does not add any supplementary flags (e.g. asm-macosx-version-min) - precisely to avoid anything being claimed as an input_file and therefore triggering a link line. Since we do not have a value for asm-macosx-version-min when processing the driver specs, we unconditionally inject 'multiply_defined suppress' which is used with shared libgcc (but only intended on very old Darwin). This then causes the generation of a link job. The solution, for the present, is to move version-specific link params to the LINK_SPEC so that they are only processed when a link job has already been decided. Signed-off-by: Iain Sandoe PR target/105599 gcc/ChangeLog: * config/darwin.h: Move versions-specific handling of multiply_defined from SUBTARGET_DRIVER_SELF_SPECS to LINK_SPEC. (cherry picked from commit 794737976b9a6418eab817f143bb4eb2d0c834d2)
