[Bug tree-optimization/97079] [11 Regression] aarch64, SVE: ICE in SLP recognizer since r11-3148-g8d3767c30240c901a493d82d9d20f306b2f0152d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97079 --- Comment #2 from Alex Coplan --- Ah, yes, the ICE re-appears immediately prior to r11-3095-g47ddf4c7b1d4471cb9534f27844ab5e4279c2168, so the bug was temporarily hidden on trunk. I'll do another bisect, thanks.
[Bug libbacktrace/97082] New: new test 'test' fails for Mach-O/Darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97082 Bug ID: 97082 Summary: new test 'test' fails for Mach-O/Darwin. Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libbacktrace Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org CC: ian at gcc dot gnu.org Target Milestone: --- Assuming that this test is expected to be usable on Darwin. I added the following patch to get dsymutil run on the test: diff --git a/libbacktrace/Makefile.am b/libbacktrace/Makefile.am index 4d349386c9b..afa1134e963 100644 --- a/libbacktrace/Makefile.am +++ b/libbacktrace/Makefile.am @@ -484,6 +484,10 @@ mtest_LDADD = libbacktrace.la BUILDTESTS += mtest +if HAVE_DSYMUTIL +check_DATA += mtest.dSYM +endif HAVE_DSYMUTIL + if HAVE_MINIDEBUG TESTS += mtest_minidebug the log output is still: test5: unexpected syminfo name got dwarf_section_names expected global PASS: backtrace_full noinline PASS: backtrace_simple noinline FAIL: backtrace_syminfo variable FAIL mtest (exit status: 1)
[Bug libbacktrace/97082] new test 'mtest' fails for Mach-O/Darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97082 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Target||x86_64-*-darwin Summary|new test 'test' fails for |new test 'mtest' fails for |Mach-O/Darwin. |Mach-O/Darwin. Status|UNCONFIRMED |NEW Last reconfirmed||2020-09-17
[Bug middle-end/97073] [8/9/10/11 Regression] Miscompilation with -m32 -O1 -march=i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97073
Uroš Bizjak changed:
What|Removed |Added
Component|target |middle-end
--- Comment #2 from Uroš Bizjak ---
Middle-end expands double mode operation to:
2: r85:DI=[r76:SI]
3: NOTE_INSN_FUNCTION_BEG
6: r86:SI=`gs2'
7: r87:SI=`gs2'
10: {r89:SI=r85:DI#0&[r87:SI];clobber flags:CC;}
11: [r86:SI+0x4]=r89:SI
14: {r91:SI=r85:DI#4&[r87:SI+0x4];clobber flags:CC;}
15: [r86:SI+0x8]=r91:SI
Please note how (insn 11) partially clobbers input value, needed by (insn 14).
When -msse2 is used, we expand with:
6: r86:SI=`gs2'
7: r87:SI=`gs2'
10: {r89:DI=r85:DI&[r87:SI];clobber flags:CC;}
11: [r86:SI+0x4]=r89:DI
that bypasses generic middle-end expansion.
[Bug tree-optimization/97075] [11 regression] powerpc64 vector tests fails after r11-3230
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97075 --- Comment #3 from Kewen Lin --- (In reply to akrl from comment #2) > Thanks Kewen, unfortunately I've no Power setup. Sorry for the > inconvenience. My pleasure! If you have interests to run on Power machines, you can apply and use some Power8/Power9 machines in CFarm machine pool https://cfarm.tetaneutral.net/machines/list/.
[Bug fortran/95654] nvptx offloading: FAIL: libgomp.fortran/pr66199-5.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95654 --- Comment #10 from Tobias Burnus --- (In reply to Tobias Burnus from comment #9) > See also thread at: > https://gcc.gnu.org/pipermail/gcc-patches/2020-September/thread.html#554054 Regarding the patch there, the proper way is to adapt can_duplicate_block_p, which calls the associated cfg_hooks->can_duplicate_block_p. Currently, there is the stub (in gimple_cfg_hooks) tree-cfg.c: gimple_can_duplicate_bb_p and (for rtl_cfg_hooks and cfg_layout_rtl_cfg_hooks) cfgrtl.c:cfg_layout_can_duplicate_bb_p the latter avoids duplicate tablejumps and calls targetm.cannot_copy_insn_p.
[Bug c/97083] New: __builtin_lround and _builtin_llround not replaced with fcvtas on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97083 Bug ID: 97083 Summary: __builtin_lround and _builtin_llround not replaced with fcvtas on aarch64 Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: linux at carewolf dot com Target Milestone: --- On aarch64 calling __builtin_round and casting the result to int or long long uses a single fcvtas instruction, but using __builtin_lround or __builtin_llround instead will do function call. Seems like they are missing the same optimization.
[Bug tree-optimization/97075] [11 regression] powerpc64 vector tests fails after r11-3230
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97075
--- Comment #4 from Kewen Lin ---
> gcc.target/powerpc/p9-vec-length-full-6.c
This is a test case issue, 64bit/32bit pairs will use full vector instead of
partial vector as Andrea's improvement.
> gcc.target/powerpc/p9-vec-length-epil-7.c
It exposed one problem: when we call vect_need_peeling_or_partial_vectors_p in
function vect_analyze_loop_2, it's in analysis stage, if the loop is one
epilogue loop, the loop_vinfo hasn't been fixed up, like LOOP_VINFO_INT_NITERS,
the function can probably give the wrong answer. For some 64bit type functions
of this failed case, it will return false for the epilogue loops but actually
the remaining iteration can't cover the full vector.
One simple fix is to exclude epilogue loop for this check.
diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index ab627fbf029..7273e998a99 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -2278,7 +2278,8 @@ start_over:
{
/* Don't use partial vectors if we don't need to peel the loop. */
if (param_vect_partial_vector_usage == 0
- || !vect_need_peeling_or_partial_vectors_p (loop_vinfo))
+ || (!LOOP_VINFO_EPILOGUE_P (loop_vinfo)
+ && !vect_need_peeling_or_partial_vectors_p (loop_vinfo)))
LOOP_VINFO_USING_PARTIAL_VECTORS_P (loop_vinfo) = false;
else if (vect_verify_full_masking (loop_vinfo)
|| vect_verify_loop_lens (loop_vinfo))
Testing is ongoing.
[Bug target/96313] [AArch64] vqmovun* return types should be unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96313 David Spickett changed: What|Removed |Added CC||david.spickett at linaro dot org --- Comment #3 from David Spickett --- Created attachment 49232 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49232&action=edit test file
[Bug target/96313] [AArch64] vqmovun* return types should be unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96313
--- Comment #4 from David Spickett ---
I've been fixing this for clang so here is a test file in case it's any help.
gcc version 11.0.0 20200609 (experimental)
Ubuntu 16.04.7 LTS running on x86_64
$ ./aarch64-none-elf-g++ -v
Using built-in specs.
COLLECT_GCC=./aarch64-none-elf-g++
COLLECT_LTO_WRAPPER=/arm/pdtl/builds/fsf-trunk.2226/installed/rhe6x86_64/aarch64-none-elf/bin/../libexec/gcc/aarch64-none-elf/11.0.0/lto-wrapper
Target: aarch64-none-elf
Configured with:
/tmp/dgboter/bbs/rhev-vm4--rhe6x86_64/buildbot/rhe6x86_64--aarch64-none-elf/build/src/gcc/configure
--target=aarch64-none-elf
--prefix=/tmp/dgboter/bbs/rhev-vm4--rhe6x86_64/buildbot/rhe6x86_64--aarch64-none-elf/build/build-aarch64-none-elf/install//
--with-gmp=/tmp/dgboter/bbs/rhev-vm4--rhe6x86_64/buildbot/rhe6x86_64--aarch64-none-elf/build/build-aarch64-none-elf/host-tools
--with-mpfr=/tmp/dgboter/bbs/rhev-vm4--rhe6x86_64/buildbot/rhe6x86_64--aarch64-none-elf/build/build-aarch64-none-elf/host-tools
--with-mpc=/tmp/dgboter/bbs/rhev-vm4--rhe6x86_64/buildbot/rhe6x86_64--aarch64-none-elf/build/build-aarch64-none-elf/host-tools
--with-isl=/tmp/dgboter/bbs/rhev-vm4--rhe6x86_64/buildbot/rhe6x86_64--aarch64-none-elf/build/build-aarch64-none-elf/host-tools
--disable-shared --disable-nls --disable-threads --disable-tls
--enable-checking=yes --enable-languages=c,c++,fortran --with-newlib
--with-pkgversion=fsf-trunk.2226
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200609 (experimental) (fsf-trunk.2226)
/tmp/test.cpp:
#include
uint32_t (*fp3)(int64_t) = vqmovund_s64;
uint8_t (*fp4)(int16_t) = vqmovunh_s16;
uint16_t (*fp5)(int32_t) = vqmovuns_s32;
Compile with:
$ ./aarch64-none-elf-g++ -march=armv8.1-a+simd -Wall -Wextra -c -o /tmp/foo
/tmp/test.cpp -save-temps
Output:
/tmp/test.cpp:3:28: error: invalid conversion from 'int32_t (*)(int64_t)' {aka
'int (*)(long int)'} to 'uint32_t (*)(int64_t)' {aka 'unsigned int (*)(long
int)'} [-fpermissive]
3 | uint32_t (*fp3)(int64_t) = vqmovund_s64;
|^~~~
||
|int32_t (*)(int64_t) {aka int (*)(long int)}
/tmp/test.cpp:4:27: error: invalid conversion from 'int8_t (*)(int16_t)' {aka
'signed char (*)(short int)'} to 'uint8_t (*)(int16_t)' {aka 'unsigned char
(*)(short int)'} [-fpermissive]
4 | uint8_t (*fp4)(int16_t) = vqmovunh_s16;
| ^~~~
| |
| int8_t (*)(int16_t) {aka signed char
(*)(short int)}
/tmp/test.cpp:5:28: error: invalid conversion from 'int16_t (*)(int32_t)' {aka
'short int (*)(int)'} to 'uint16_t (*)(int32_t)' {aka 'short unsigned int
(*)(int)'} [-fpermissive]
5 | uint16_t (*fp5)(int32_t) = vqmovuns_s32;
|^~~~
||
|int16_t (*)(int32_t) {aka short int
(*)(int)}
[Bug tree-optimization/97079] [11 Regression] aarch64, SVE: ICE in SLP recognizer since r11-3148-g8d3767c30240c901a493d82d9d20f306b2f0152d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97079 --- Comment #3 from Alex Coplan --- It seems this was introduced with r11-2817-gcdb2e365fc0dba2ee052827e5ca65234ca82d605: commit cdb2e365fc0dba2ee052827e5ca65234ca82d605 Author: Martin Liska Date: Fri Jul 31 09:53:39 2020 SLP: support entire BB.
[Bug fortran/95654] nvptx offloading: FAIL: libgomp.fortran/pr66199-5.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95654 Tom de Vries changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #11 from Tom de Vries --- So, at this point we know that duplicating the BB containing VOTE_ANY causes problems in executing. But AFAIU, we do not know why. Is VOTE_ANY not supposed to be duplicated by design? If so, is there any documentation of that design, that explains that? At the nvptx level, VOTE_ANY translates to vote.ballot.b32, which does cross-lane communication, but has defined behaviour in divergent mode AFAICT. >From that perspective at least, there's no problem with duplicating VOTE_ANY. My guess at this point, is that duplicating the block with VOTE_ANY has the effect that the JIT compiler doesn't recognize control flow divergence before XCHG_IDX, and fails to insert the proper barrier. And XCHG_IDX translates to shfl.idx.b32, which has undefined behaviour in divergent mode.
[Bug d/96989] SSA_NAMEs in Wuninitialized warning messages after r11-959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96989 --- Comment #4 from Iain Buclaw --- Created attachment 49233 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49233&action=edit d tree printer Very minimal tree printing support just to cover SSA_NAME and MEM_REF nodes. I'm not entirely convinced by having to resort to this: else if (SSA_NAME_DEF_STMT (expr) && is_gimple_assign (SSA_NAME_DEF_STMT (expr))) d_print_expression (pp, gimple_assign_rhs1 (SSA_NAME_DEF_STMT (expr))); But it's the only place I can see to coax out the original variable from an anonymous SSA_NAME. Trying the same example with gcc/g++, and the warning emits *() - so the problem is at least shared between all front-ends.
[Bug fortran/97084] New: Openmp + Allocatable String Crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97084 Bug ID: 97084 Summary: Openmp + Allocatable String Crashes Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: wddawson at ucdavis dot edu Target Milestone: --- Minimal example ``` program test implicit none integer :: ii integer, parameter :: N = 80 character(len=:), allocatable :: temp_string allocate(character(len=N) :: temp_string) !$omp parallel default(shared) !$omp do do ii = 1, N temp_string(ii:ii) = "#" end do !$omp end do !$omp end parallel end program ``` When I compile with `gfortran main.f90 -fopenmp -o test ` I get the following error: ``` during GIMPLE pass: omplower main.f90:9:0: 9 | !$omp parallel default(shared) | internal compiler error: in gimplify_expr, at gimplify.c:13885 libbacktrace could not find executable to open ``` It fails with the following compilers: ``` GNU Fortran (Homebrew GCC 10.2.0) 10.2.0 ``` ``` GNU Fortran (Homebrew GCC 9.3.0) 9.3.0 ``` But works with: ``` GNU Fortran (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39) ``` This is possibly related to 89621?
[Bug tree-optimization/94621] [9 Regression] GCC 9.2.1 segfaults when compiling file with -O3 since r9-5354
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94621 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Jakub Jelinek --- Fixed for 9.4+.
[Bug middle-end/97078] [11 Regression] ICE in set_rtl building glibc tests with -ffloat-store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97078 --- Comment #3 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:225a08220e444371ae4867b3e2ace275d30af3d3 commit r11-3257-g225a08220e444371ae4867b3e2ace275d30af3d3 Author: Eric Botcazou Date: Thu Sep 17 12:58:02 2020 +0200 Fix assertion checking failure with tail call gcc/ChangeLog: PR middle-end/97078 * function.c (use_register_for_decl): Test cfun->tail_call_marked for a parameter here instead of... (assign_parm_setup_reg): ...here. gcc/testsuite/ChangeLog: * gcc.dg/pr97078.c: New test.
[Bug middle-end/97078] [11 Regression] ICE in set_rtl building glibc tests with -ffloat-store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97078 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Eric Botcazou --- Thanks for reporting the problem.
[Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97060 --- Comment #9 from Jiri Olsa --- (In reply to Jakub Jelinek from comment #6) > Also, to avoid confusion, upstream 10 branch is not affected, but in 10-RH > we've backported the PR96383 changes from the trunk. Is this gcc going to RHEL8? that could be a problem for us. Also, is there a way how we can workaround this? How to recgnize function declaration apart from definition in dwarf data?
[Bug fortran/93423] [8/9/10/11 Regression] ICE on invalid with argument list for module procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93423 --- Comment #7 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:c12facd22881517127ebbe213d7ecc7fc1fcea4e commit r11-3259-gc12facd22881517127ebbe213d7ecc7fc1fcea4e Author: Tobias Burnus Date: Thu Sep 17 14:01:09 2020 +0200 Fortran: Avoid double-free with parse error (PR96041, PR93423) gcc/fortran/ PR fortran/96041 PR fortran/93423 * decl.c (gfc_match_submod_proc): Avoid later double-free in the error case.
[Bug fortran/96041] [11 regression] ICE in gfortran.dg/pr93423.f90 after r11-1792
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96041 --- Comment #10 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:c12facd22881517127ebbe213d7ecc7fc1fcea4e commit r11-3259-gc12facd22881517127ebbe213d7ecc7fc1fcea4e Author: Tobias Burnus Date: Thu Sep 17 14:01:09 2020 +0200 Fortran: Avoid double-free with parse error (PR96041, PR93423) gcc/fortran/ PR fortran/96041 PR fortran/93423 * decl.c (gfc_match_submod_proc): Avoid later double-free in the error case.
[Bug fortran/89891] [meta-bug] Accessing memory in rejected statements or expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89891 Bug 89891 depends on bug 96041, which changed state. Bug 96041 Summary: [11 regression] ICE in gfortran.dg/pr93423.f90 after r11-1792 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96041 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/96041] [11 regression] ICE in gfortran.dg/pr93423.f90 after r11-1792
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96041 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from Tobias Burnus --- FIXED on trunk (GCC 11), which is the only one affected. Note: The patch causing this issue is for PR93423. The latter was a 8/9/10/11 regression of type ICE-on-invalid. If the PR93423 patch gets cherry-picked for a branch, you may likely also see cherry-picks commits in PR.
[Bug other/86656] [meta-bug] Issues found with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656 Bug 86656 depends on bug 96041, which changed state. Bug 96041 Summary: [11 regression] ICE in gfortran.dg/pr93423.f90 after r11-1792 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96041 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/93423] [8/9/10/11 Regression] ICE on invalid with argument list for module procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93423 Bug 93423 depends on bug 96041, which changed state. Bug 96041 Summary: [11 regression] ICE in gfortran.dg/pr93423.f90 after r11-1792 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96041 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97060 --- Comment #10 from Jakub Jelinek --- RHEL8 uses gcc 8 which is not affected (unless one uses DTS/GTS). Also, it is unclear for what in particular pahole or what wants to use DW_AT_declaration. DW_TAG_subprogram of a real definition (that hasn't been optimized out) is the one that has DW_AT_low_pc/DW_AT_high_pc or DW_AT_ranges attributes (i.e. has any associated code). Some functions can have many definitions (e.g. inline functions or other comdat entities).
[Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97060 --- Comment #11 from Jiri Olsa --- (In reply to Jakub Jelinek from comment #10) > RHEL8 uses gcc 8 which is not affected (unless one uses DTS/GTS). > Also, it is unclear for what in particular pahole or what wants to use > DW_AT_declaration. pahole takes dwarf data and produces BTF type data that includes functions the DW_AT_declaration flag was used to skip function declarations so only one function record was processed and added to BTF data without that flag pahole will add one function multiple times to BTF data, based on how many times it was declared in other objects > DW_TAG_subprogram of a real definition (that hasn't been optimized out) is > the one that has DW_AT_low_pc/DW_AT_high_pc or DW_AT_ranges attributes (i.e. > has any associated code). Some functions can have many definitions (e.g. > inline functions or other comdat entities). I'll check if we can add more check to pahole for this thanks
[Bug tree-optimization/97085] New: [11 Regression] aarch64, SVE: ICE in gimple_expand_vec_cond_expr since r11-2610-ga1ee6d507b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97085
Bug ID: 97085
Summary: [11 Regression] aarch64, SVE: ICE in
gimple_expand_vec_cond_expr since r11-2610-ga1ee6d507b
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
For the following testcase:
int a, b, c, d;
short e, g;
unsigned short f;
void h() {
for (; d; d++) {
g = d;
e = b == 0 ? 1 : a % b;
c ^= (f = e) > (g == 5);
}
}
AArch64 GCC ICEs at -O3 with -march=armv8.2-a+sve since
r11-2610-ga1ee6d507b0c26466be519d177f5a08b22f63647:
Author: Marc Glisse
Date: Fri Aug 7 17:49:04 2020
Disable some VEC_COND_EXPR transformations after vector lowering
To reproduce:
$ aarch64-none-elf-gcc -c test.c -O3 -march=armv8.2-a+sve
during GIMPLE pass: isel
test.c: In function 'h':
test.c:4:6: internal compiler error: in gimple_expand_vec_cond_expr, at
gimple-isel.cc:135
4 | void h() {
| ^
0x102c7bd gimple_expand_vec_cond_expr
/home/alecop01/toolchain/src/gcc/gcc/gimple-isel.cc:133
0x102cbe1 gimple_expand_vec_cond_exprs
/home/alecop01/toolchain/src/gcc/gcc/gimple-isel.cc:191
0x102cbe1 execute
/home/alecop01/toolchain/src/gcc/gcc/gimple-isel.cc:240
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/97086] New: aix: ceilf and truncf do not preserve the sign bit when output is rounded to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97086
Bug ID: 97086
Summary: aix: ceilf and truncf do not preserve the sign bit
when output is rounded to 0
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mfarazma.ext at gmail dot com
Target Milestone: ---
Test program:
#include
#include
int main(){
float input = -0.1;
printf("%f\n", ceilf(-0.1)); // -0.00 , correct
printf("%f\n", ceilf(input)); // 0.00 , wrong
return 0;
}
Compile with:
g++ test.cc
./a.out
"ceilf" does not preserve the sign bit when its input is passed by value and
the output is rounded to 0.
The same happens when using "truncf".
[Bug c++/96410] A lambda with a template parameter list inside the template function using C++20 requires clauses is not usable in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96410 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:b28b621ac67beee81a47adb50b954bcf751570fd commit r11-3261-gb28b621ac67beee81a47adb50b954bcf751570fd Author: Patrick Palka Date: Thu Sep 17 09:16:02 2020 -0400 c++: requires-expressions and partial instantiation [PR96410] This patch makes tsubst_requires_expr avoid substituting into a requires-expression when partially instantiating a generic lambda. This is necessary in general to ensure that we always check requirements in lexical order (as in the first testcase below). A mechanism similar to PACK_EXPANSION_EXTRA_ARGS is added to remember template arguments and defer substitution of requires-expressions. Incidentally, this change also fixes the two mentioned PRs -- the problem there is that tsubst_requires_expr was performing semantic checks on template trees, and some of the checks are not prepared to handle such trees. With this patch, tsubst_requires_expr no longer does any semantic checking at all when processing_template_decl. gcc/cp/ChangeLog: PR c++/96409 PR c++/96410 * constraint.cc (tsubst_requires_expr): Use REQUIRES_EXPR_PARMS and REQUIRES_EXPR_REQS. Use REQUIRES_EXPR_EXTRA_ARGS, add_extra_args and build_extra_args to defer substitution until we have all the template arguments. (finish_requires_expr): Adjust the call to build_min so that REQUIRES_EXPR_EXTRA_ARGS gets set to NULL_TREE. * cp-tree.def (REQUIRES_EXPR): Give it a third operand. * cp-tree.h (REQUIRES_EXPR_PARMS, REQUIRES_EXPR_REQS, REQUIRES_EXPR_EXTRA_ARGS): Define. (add_extra_args, build_extra_args): Declare. gcc/testsuite/ChangeLog: PR c++/96409 PR c++/96410 * g++.dg/cpp2a/concepts-lambda13.C: New test. * g++.dg/cpp2a/concepts-lambda14.C: New test.
[Bug c++/96409] A lambda with a template parameter list inside the template function using C++20 nested requirements clauses occurs internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96409 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:b28b621ac67beee81a47adb50b954bcf751570fd commit r11-3261-gb28b621ac67beee81a47adb50b954bcf751570fd Author: Patrick Palka Date: Thu Sep 17 09:16:02 2020 -0400 c++: requires-expressions and partial instantiation [PR96410] This patch makes tsubst_requires_expr avoid substituting into a requires-expression when partially instantiating a generic lambda. This is necessary in general to ensure that we always check requirements in lexical order (as in the first testcase below). A mechanism similar to PACK_EXPANSION_EXTRA_ARGS is added to remember template arguments and defer substitution of requires-expressions. Incidentally, this change also fixes the two mentioned PRs -- the problem there is that tsubst_requires_expr was performing semantic checks on template trees, and some of the checks are not prepared to handle such trees. With this patch, tsubst_requires_expr no longer does any semantic checking at all when processing_template_decl. gcc/cp/ChangeLog: PR c++/96409 PR c++/96410 * constraint.cc (tsubst_requires_expr): Use REQUIRES_EXPR_PARMS and REQUIRES_EXPR_REQS. Use REQUIRES_EXPR_EXTRA_ARGS, add_extra_args and build_extra_args to defer substitution until we have all the template arguments. (finish_requires_expr): Adjust the call to build_min so that REQUIRES_EXPR_EXTRA_ARGS gets set to NULL_TREE. * cp-tree.def (REQUIRES_EXPR): Give it a third operand. * cp-tree.h (REQUIRES_EXPR_PARMS, REQUIRES_EXPR_REQS, REQUIRES_EXPR_EXTRA_ARGS): Define. (add_extra_args, build_extra_args): Declare. gcc/testsuite/ChangeLog: PR c++/96409 PR c++/96410 * g++.dg/cpp2a/concepts-lambda13.C: New test. * g++.dg/cpp2a/concepts-lambda14.C: New test.
[Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97060
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #12 from Jakub Jelinek ---
So, I've tried to bootstrap/regtest an adjusted patch:
2020-09-16 Jakub Jelinek
PR debug/97060
* dwarf2out.c (dwarf2out_early_global_decl): For FUNCTION_DECLs
and their abstract origins, if they don't have gimple body,
set current_function_decl to NULL rather than the decl or origin.
* gcc.dg/debug/dwarf2/pr97060.c: New test.
--- gcc/dwarf2out.c.jj 2020-09-07 13:17:58.383594248 +0200
+++ gcc/dwarf2out.c 2020-09-16 11:14:57.763550862 +0200
@@ -26547,7 +26547,12 @@ dwarf2out_early_global_decl (tree decl)
&& ((origin_die = lookup_decl_die (origin)) == NULL
|| is_declaration_die (origin_die)))
{
- current_function_decl = origin;
+ cgraph_node *cnode = cgraph_node::get (origin);
+ if ((cnode && cnode->has_gimple_body_p ())
+ || decl_ultimate_origin (origin))
+ current_function_decl = origin;
+ else
+ current_function_decl = NULL_TREE;
dwarf2out_decl (origin);
}
@@ -26556,7 +26561,12 @@ dwarf2out_early_global_decl (tree decl)
if ((old_die = lookup_decl_die (decl)) == NULL
|| is_declaration_die (old_die))
{
- current_function_decl = decl;
+ cgraph_node *cnode = cgraph_node::get (decl);
+ if ((cnode && cnode->has_gimple_body_p ())
+ || decl_ultimate_origin (decl))
+ current_function_decl = decl;
+ else
+ current_function_decl = NULL_TREE;
dwarf2out_decl (decl);
}
--- gcc/testsuite/gcc.dg/debug/dwarf2/pr97060.c.jj 2020-09-16
11:03:22.358420449 +0200
+++ gcc/testsuite/gcc.dg/debug/dwarf2/pr97060.c 2020-09-16 11:03:17.717486318
+0200
@@ -0,0 +1,13 @@
+/* PR debug/97060 */
+/* { dg-do compile } */
+/* { dg-options "-g -dA" } */
+/* { dg-final { scan-assembler-times "DW_AT_declaration" 2 } } */
+
+extern int foo (unsigned int, unsigned int);
+
+int
+bar (void)
+{
+ foo (1, 2);
+ return 0;
+}
It passes bootstrap, but causes some regressions:
-FAIL: g++.dg/guality/pr55665.C -O2 -flto -fno-use-linker-plugin
-flto-partition=none line 23 p == 40
+FAIL: g++.dg/debug/dwarf2/array-3.C -std=gnu++11 scan-assembler-times
DW_TAG_const_type 5
+FAIL: g++.dg/debug/dwarf2/array-3.C -std=gnu++14 scan-assembler-times
DW_TAG_const_type 5
+FAIL: g++.dg/debug/dwarf2/array-3.C -std=gnu++17 scan-assembler-times
DW_TAG_const_type 5
+FAIL: g++.dg/debug/dwarf2/array-3.C -std=gnu++2a scan-assembler-times
DW_TAG_const_type 5
+FAIL: g++.dg/debug/dwarf2/array-3.C -std=gnu++98 scan-assembler-times
DW_TAG_const_type 5
+FAIL: g++.dg/debug/dwarf2/array-4.C -std=gnu++11 scan-assembler-times
DW_TAG_const_type 4
+FAIL: g++.dg/debug/dwarf2/array-4.C -std=gnu++14 scan-assembler-times
DW_TAG_const_type 4
+FAIL: g++.dg/debug/dwarf2/array-4.C -std=gnu++17 scan-assembler-times
DW_TAG_const_type 4
+FAIL: g++.dg/debug/dwarf2/array-4.C -std=gnu++2a scan-assembler-times
DW_TAG_const_type 4
+FAIL: g++.dg/debug/dwarf2/array-4.C -std=gnu++98 scan-assembler-times
DW_TAG_const_type 4
+FAIL: g++.dg/debug/dwarf2/defaulted-member-function-2.C scan-assembler-times
0x2[ \\t][^\\n]* DW_AT_defaulted 1
+FAIL: g++.dg/debug/dwarf2/local-var-in-contructor.C -std=gnu++11
scan-assembler problem
+FAIL: g++.dg/debug/dwarf2/local-var-in-contructor.C -std=gnu++14
scan-assembler problem
+FAIL: g++.dg/debug/dwarf2/local-var-in-contructor.C -std=gnu++17
scan-assembler problem
+FAIL: g++.dg/debug/dwarf2/local-var-in-contructor.C -std=gnu++2a
scan-assembler problem
+FAIL: g++.dg/debug/dwarf2/local-var-in-contructor.C -std=gnu++98
scan-assembler problem
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C -std=gnu++11 scan-assembler
"one::c1::c10"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C -std=gnu++11 scan-assembler
"one::c1::~c10"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C -std=gnu++11 scan-assembler
"two::c2::c20"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C -std=gnu++11 scan-assembler
"two::c2::~c20"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C -std=gnu++11 scan-assembler
"two::c2::c20"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C -std=gnu++11 scan-assembler
"two::c2::~c20"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C -std=gnu++11 scan-assembler
"two::c2::c20"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.d
[Bug fortran/95654] nvptx offloading: FAIL: libgomp.fortran/pr66199-5.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95654
--- Comment #12 from Tom de Vries ---
(In reply to Tom de Vries from comment #7)
> Minimal example after commit 91347c3bbf7 "Fortran: OpenMP - fix simd with
> (last)private (PR97061)":
> ...
> ! { dg-do run }
>
> program main
> implicit none
> integer :: d1
> !$omp target map(from: d1)
>
> !$omp teams distribute parallel do simd default(none) lastprivate(d1)
>
> do d1 = 0, 31
> end do
> !$omp end target
>
> if (d1 /= 32) stop 3
> end program
> ...
To further reduce: set num_teams to 2, and num_threads to 1:
...
!$omp teams distribute parallel do simd default(none) lastprivate(d1)
num_teams (2) num_threads (1)
...
Makes it easier to reason about the code.
[Bug c++/55776] -Wshadow generates an incorrect warning with enum classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55776 Ian McInerney changed: What|Removed |Added CC||ian.s.mcinerney at ieee dot org --- Comment #9 from Ian McInerney --- Based on all these examples, it seems like the potential for confusion/incorrect behavior is when the shadowed name is used on the right-hand side of an assignment inside the enum class declaration. So why does this need to trigger if it is just declaring the name and not using it in the enum class declatation? Can this warning instead only warn on a usage in the declaration? e.g. the original example in comment 1 never used foo in the enum class to initialize values in the enum, so where is the possibility for incorrect behavior in this case? Throwing a warning in this case leads to excess warnings in some cases when compiled with headers from MingW, since they tend to define things like RECT, INPUT, OUTPUT, etc. so the shadowing warnings are thrown if you use any of those names in an enum class.
[Bug c++/97051] Evaluating is_constant_evaluated in requires clause fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97051 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- Looking into it
[Bug preprocessor/96935] [9/10 Regression] ICE in subspan, at input.h:69
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96935 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:d01c3def63caf59d1d156aec8d52a1540e5ffe27 commit r10-8772-gd01c3def63caf59d1d156aec8d52a1540e5ffe27 Author: Marek Polacek Date: Wed Sep 16 09:27:29 2020 -0400 preprocessor: Fix ICE with too long line in fmtwarn [PR96935] Here we ICE in char_span::subspan because the offset it gets is -1. It's -1 because get_substring_ranges_for_loc gets a location whose column was 0. That only happens in testcases like the attached where we're dealing with extremely long lines (at least 4065 chars it seems). This does happen in practice, though, so it's not just a theoretical problem (e.g. when building the SU2 suite). Fixed by checking that the column get_substring_ranges_for_loc gets is sane, akin to other checks in that function. gcc/ChangeLog: PR preprocessor/96935 * input.c (get_substring_ranges_for_loc): Return if start.column is less than 1. gcc/testsuite/ChangeLog: PR preprocessor/96935 * gcc.dg/format/pr96935.c: New test. (cherry picked from commit 31dd5cd6344bfbbe122fb512993b128e11236d35)
[Bug preprocessor/96935] [9 Regression] ICE in subspan, at input.h:69
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96935 Marek Polacek changed: What|Removed |Added Summary|[9/10 Regression] ICE in|[9 Regression] ICE in |subspan, at input.h:69 |subspan, at input.h:69 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Marek Polacek --- Fixed.
[Bug debug/93888] Incorrect DW_AT_location generated for copy-constructed function argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93888 --- Comment #9 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:777fa0a232a6bfc7ed3827f35322ec740fe714e9 commit r8-10457-g777fa0a232a6bfc7ed3827f35322ec740fe714e9 Author: Jakub Jelinek Date: Wed Mar 4 12:59:04 2020 +0100 inliner: Copy DECL_BY_REFERENCE in copy_decl_to_var [PR93888] In the following testcase we emit wrong debug info for the karg parameter in the DW_TAG_inlined_subroutine into main. The problem is that the karg PARM_DECL is DECL_BY_REFERENCE and thus in the IL has const K & type, but in the source just const K. When the function is inlined, we create a VAR_DECL for it, but don't set DECL_BY_REFERENCE, so when emitting DW_AT_location, we treat it like a const K & typed variable, but it has DW_AT_abstract_origin which has just the const K type and thus the debugger thinks the variable has const K type. Fixed by copying the DECL_BY_REFERENCE flag. Not doing it in copy_decl_for_dup_finish, because copy_decl_no_change already copies that flag through copy_node and in copy_result_decl_to_var it is undesirable, as we handle DECL_BY_REFERENCE in that case instead by changing the type. 2020-03-04 Jakub Jelinek PR debug/93888 * tree-inline.c (copy_decl_to_var): Copy DECL_BY_REFERENCE flag. * g++.dg/guality/pr93888.C: New test. (cherry picked from commit d2a810ee83e2952bf351498cecf8f5db28860a24)
[Bug rtl-optimization/94002] [9/10 Regression] ICE: in decompose, at rtl.h:2279 with -O -fPIC -fno-tree-dce -fno-tree-reassoc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94002 --- Comment #7 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:3549a5cabdfd4ebb197da99f247d0abad0ba55b5 commit r8-10455-g3549a5cabdfd4ebb197da99f247d0abad0ba55b5 Author: Jakub Jelinek Date: Tue Mar 3 10:42:34 2020 +0100 explow: Fix ICE caused by plus_constant [PR94002] The following testcase ICEs in cross to riscv64-linux. The problem is that we have a DImode integral constant (that doesn't fit into SImode), which is pushed into a constant pool and later access just the first half of it using a MEM. When plus_constant is called on such a MEM, if the constant has mode, we verify the mode, but if it doesn't, we don't and ICE later on when we think the CONST_INT is a valid SImode constant. 2020-03-03 Jakub Jelinek PR rtl-optimization/94002 * explow.c (plus_constant): Punt if cst has VOIDmode and get_pool_mode is different from mode. * gcc.dg/pr94002.c: New test. (cherry picked from commit e913d4f4771e04d4254bf6c0e720fec5e324a898)
[Bug target/94046] cast to __m256d in mask argument of avx2 float gather intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94046
--- Comment #8 from CVS Commits ---
The releases/gcc-8 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:5dd7682887c959a10d5d1d4d7ad7b4a0950805d2
commit r8-10456-g5dd7682887c959a10d5d1d4d7ad7b4a0950805d2
Author: Jakub Jelinek
Date: Thu Mar 5 19:44:42 2020 +0100
i386: Fix some -O0 avx2intrin.h and xopintrin.h intrinsic macros [PR94046]
As the testcases show, the macros we have for -O0 for intrinsics that
require
constant argument(s) should first cast the argument to the type the -O1+
inline uses and afterwards to whatever type e.g. a builtin needs.
The PR reported one which violated this, and I've grepped for all
double-casts
and grepped out from that meaningful casts where the __m{128,256,512}{,d,i}
first cast is cast to same sized __v* type and has the same kind of element
type (float, double, integral). These 7 macros were using different casts,
and I've double checked them against the inline function types.
2020-03-05 Jakub Jelinek
PR target/94046
* config/i386/avx2intrin.h (_mm_mask_i32gather_ps): Fix first cast
of
SRC and MASK arguments to __m128 from __m128d.
(_mm256_mask_i32gather_ps): Fix first cast of MASK argument to
__m256
from __m256d.
(_mm_mask_i64gather_ps): Fix first cast of MASK argument to __m128
from __m128d.
* config/i386/xopintrin.h (_mm_permute2_pd): Fix first cast of C
argument to __m128i from __m128d.
(_mm256_permute2_pd): Fix first cast of C argument to __m256i from
__m256d.
(_mm_permute2_ps): Fix first cast of C argument to __m128i from
__m128.
(_mm256_permute2_ps): Fix first cast of C argument to __m256i from
__m256.
* g++.dg/ext/pr94046-1.C: New test.
* g++.dg/ext/pr94046-2.C: New test.
(cherry picked from commit 07d52e63d999a0a10c7598c34c48365a357d3d5a)
[Bug tree-optimization/94130] [8 Regression] Unintended result with optimization option when assigning two structures, memset and 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94130
--- Comment #12 from CVS Commits ---
The releases/gcc-8 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:9001bc36447e015283a5f1a0a924bd355f9d9df3
commit r8-10463-g9001bc36447e015283a5f1a0a924bd355f9d9df3
Author: Jakub Jelinek
Date: Thu Mar 12 09:34:00 2020 +0100
tree-dse: Fix mem* head trimming if call has lhs [PR94130]
As the testcase shows, if DSE decides to head trim
{mem{set,cpy,move},strncpy}
and the call has lhs, it is incorrect to leave the lhs as is, because it
will then point to the adjusted address (base + head_trim) instead of the
original base.
The following patch fixes that by dropping the lhs of the call and
assigning
lhs the original base in a following statement.
2020-03-12 Jakub Jelinek
PR tree-optimization/94130
* tree-ssa-dse.c: Include gimplify.h.
(increment_start_addr): If stmt has lhs, drop the lhs from call and
set it after the call to the original value of the first argument.
Formatting fixes.
(decrement_count): Formatting fix.
* gcc.c-torture/execute/pr94130.c: New test.
(cherry picked from commit a545ffafa380fa958393e1dfbf7f5f8f129bc5cf)
[Bug debug/94167] [8 Regression] pr71109.c -fcompare-debug failures on x86_64 and powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94167 --- Comment #8 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7fdfea793bdf47510a8ac6ff11dbf46288ae47a6 commit r8-10468-g7fdfea793bdf47510a8ac6ff11dbf46288ae47a6 Author: Jakub Jelinek Date: Mon Mar 16 09:03:59 2020 +0100 tree-inline: Fix a -fcompare-debug issue in the inliner [PR94167] The following testcase fails with -fcompare-debug. The problem is that bar is marked as address_taken only with -g and not without. I've tracked it down to insert_init_stmt calling gimple_regimplify_operands even on DEBUG_STMTs. That function will just insert normal stmts before the DEBUG_STMT if the DEBUG_STMT operand isn't gimple val or invariant. While DCE will turn those statements into debug temporaries, it can cause differences in SSA_NAMEs and more importantly, the ipa references are generated from those before the DCE happens. On the testcase, the DEBUG_STMT value is (int)bar. We could generate DEBUG_STMTs with debug temporaries instead, but I fail to see the reason to do that, DEBUG_STMTs allow other expressions and all we want to ensure is that the expressions aren't too large (arbitrarily complex), but during inlining/function versioning I don't see why something would queue a DEBUG_STMT with arbitrarily complex expressions in there. 2020-03-16 Jakub Jelinek PR debug/94167 * tree-inline.c (insert_init_stmt): Don't gimple_regimplify_operands DEBUG_STMTs. * gcc.dg/pr94167.c: New test. (cherry picked from commit 378e830538afd4a02e41674cc9161fa59b5e09a9)
[Bug target/94121] ICE on aarch64-linux-gnu: in abs_hwi, at hwint.h:324
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94121 --- Comment #11 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ce8325e77d923a11dce089a7ef3a24b4737bf95f commit r8-10466-gce8325e77d923a11dce089a7ef3a24b4737bf95f Author: Jakub Jelinek Date: Fri Mar 13 11:33:16 2020 +0100 aarch64: Fix another bug in aarch64_add_offset_1 [PR94121] > I'm getting this ICE with -mabi=ilp32: > > during RTL pass: fwprop1 > /opt/gcc/gcc-20200312/gcc/testsuite/gcc.dg/pr94121.c: In function 'bar': > /opt/gcc/gcc-20200312/gcc/testsuite/gcc.dg/pr94121.c:16:1: internal compiler error: in decompose, at rtl.h:2279 That is a preexisting issue, caused by another bug in the same function. When mode is SImode and moffset is 0x8000 (or anything else with the bit 31 set), we need to sign-extend it. 2020-03-13 Jakub Jelinek PR target/94121 * config/aarch64/aarch64.c (aarch64_add_offset_1): Use gen_int_mode instead of GEN_INT. (cherry picked from commit c2f836c413b1e9ae45598338b4a2ecd33bd926fb)
[Bug target/94134] pdp11-aout puts initial variable into .text section rather than .data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94134
--- Comment #15 from CVS Commits ---
The releases/gcc-8 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:4910b2e4cfe25c95fef18cf54125b788c190cfb2
commit r8-10462-g4910b2e4cfe25c95fef18cf54125b788c190cfb2
Author: Jakub Jelinek
Date: Wed Mar 11 18:35:13 2020 +0100
pdp11: Fix handling of common (local and global) vars [PR94134]
As mentioned in the PR, the generic code decides to put the a variable into
lcomm_section, which is a NOSWITCH section and thus the generic code
doesn't
switch into a particular section before using
ASM_OUTPUT{_ALIGNED{,_DECL}_}_LOCAL, on many targets that results just in
.lcomm (or for non-local .comm) directives which don't need a switch to
some
section, other targets put switch_to_section (bss_section) at the start of
that macro.
pdp11 doesn't do that (and doesn't have bss_section), and so emits the
lcomm/comm variables in whatever section is current (it has only
.text/.data
and for DEC assembler rodata).
The following patch fixes that by putting it always into data section, and
additionally avoids emitting an empty line in the assembly for the lcomm
vars.
2020-03-11 Jakub Jelinek
PR target/94134
* config/pdp11/pdp11.c (pdp11_asm_output_var): Call
switch_to_section
at the start to switch to data section. Don't print extra newline
if
.globl directive has not been emitted.
* gcc.c-torture/execute/pr94134.c: New test.
(cherry picked from commit f1125cf88ac0c97d819e4f81d556fbcd1161270e)
[Bug middle-end/93566] [8 Regression] tree-nested.c ICE on C OpenMP array section reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93566
--- Comment #8 from CVS Commits ---
The releases/gcc-8 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:434ddc50ba49442e655c34d85cedd358110e4266
commit r8-10467-g434ddc50ba49442e655c34d85cedd358110e4266
Author: Jakub Jelinek
Date: Sun Mar 15 01:27:40 2020 +0100
tree-nested: Fix handling of *reduction clauses with C array sections
[PR93566]
tree-nested.c didn't handle C array sections in {,task_,in_}reduction
clauses.
2020-03-14 Jakub Jelinek
PR middle-end/93566
* tree-nested.c (convert_nonlocal_omp_clauses,
convert_local_omp_clauses): Handle {,in_,task_}reduction clauses
with C/C++ array sections.
* testsuite/libgomp.c/pr93566.c: New test.
(cherry picked from commit a8fc40fd551a60a97efbfe3fee08721accd80964)
[Bug tree-optimization/94114] [8 Regression] ICE in gimplify_modify_expr, at gimplify.c:5936
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94114 --- Comment #6 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:8d5332862e86edb92f27bd136ccd9fdba3524039 commit r8-10459-g8d5332862e86edb92f27bd136ccd9fdba3524039 Author: Jakub Jelinek Date: Wed Mar 11 09:32:22 2020 +0100 ldist: Further fixes for -ftrapv [PR94114] As the testcase shows, arithmetics that for -ftrapv would need multiple basic blocks can show up not just in nb_bytes expressions where we are calling rewrite_to_non_trapping_overflow for a while already, but also in the pointer expression to the start of the region. While the testcase covers just the first hunk and I've failed to create a testcase for the latter, it is at least in theory possible too, so I've adjusted that hunk too. 2020-03-11 Jakub Jelinek PR tree-optimization/94114 * tree-loop-distribution.c (generate_memset_builtin): Call rewrite_to_non_trapping_overflow even on mem. (generate_memcpy_builtin): Call rewrite_to_non_trapping_overflow even on dest and src. * gcc.dg/pr94114.c: New test. (cherry picked from commit 2fd27691f213f2e808626c4cd492b00c801a00fa)
[Bug c/94172] [arm-none-eabi] ICE in expand_debug_locations, at cfgexpand.c:5403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94172
--- Comment #13 from CVS Commits ---
The releases/gcc-8 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:cac1949a51e25360a7fd7dc8f473997b7ca048a9
commit r8-10470-gcac1949a51e25360a7fd7dc8f473997b7ca048a9
Author: Jakub Jelinek
Date: Tue Mar 17 22:32:34 2020 +0100
c: Handle C_TYPE_INCOMPLETE_VARS even for ENUMERAL_TYPEs [PR94172]
The following testcases ICE, because they contain extern variable
declarations with incomplete enum types that is later completed and after
that those variables are accessed. The ICEs are because the vars then may
have
incorrect DECL_MODE etc., e.g. in the first case the var has SImode
DECL_MODE (the guessed mode for the enum), but the enum then actually has
DImode because its enumerators don't fit into unsigned int.
The following patch fixes it by using C_TYPE_INCOMPLETE_VARS not just on
incomplete struct/union types, but also incomplete enum types.
TYPE_VFIELD can't be used as it is TYPE_MIN_VALUE on ENUMERAL_TYPE,
thankfully TYPE_LANG_SLOT_1 has been used in the C FE only on
FUNCTION_TYPEs.
2020-03-17 Jakub Jelinek
PR c/94172
* c-tree.h (C_TYPE_INCOMPLETE_VARS): Define to TYPE_LANG_SLOT_1
instead of TYPE_VFIELD, and support it on
{RECORD,UNION,ENUMERAL}_TYPE.
(TYPE_ACTUAL_ARG_TYPES): Check that it is only used on
FUNCTION_TYPEs.
* c-decl.c (pushdecl): Push C_TYPE_INCOMPLETE_VARS also to
ENUMERAL_TYPEs.
(finish_incomplete_vars): New function, moved from finish_struct.
Use
relayout_decl instead of layout_decl.
(finish_struct): Remove obsolete comment about
C_TYPE_INCOMPLETE_VARS
being TYPE_VFIELD. Use finish_incomplete_vars.
(finish_enum): Clear C_TYPE_INCOMPLETE_VARS. Call
finish_incomplete_vars.
* c-typeck.c (c_build_qualified_type): Clear C_TYPE_INCOMPLETE_VARS
also on ENUMERAL_TYPEs.
* gcc.dg/pr94172-1.c: New test.
* gcc.dg/pr94172-2.c: New test.
(cherry picked from commit 87ce34fa00cd6b87452d747235da40dfe5b6e00f)
[Bug middle-end/93399] [8 Regression] Annotate assembler option failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93399 --- Comment #13 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c035257d1f775f44359fe55ceb3d018a68d87114 commit r8-10458-gc035257d1f775f44359fe55ceb3d018a68d87114 Author: Jakub Jelinek Date: Thu Mar 5 09:12:44 2020 +0100 print-rtl: Fix printing of CONST_STRING in DEBUG_INSNs [PR93399] The following testcase fails to assemble, as CONST_STRING in the DEBUG_INSNs is printed as is, so if it contains \n and/or \r, we are in trouble: .loc 1 14 3 # DEBUG haystack => [si] # DEBUG needle => " " In the gimple dumps we print those (STRING_CSTs) as # DEBUG haystack => D#1 # DEBUG needle => "\n" so this patch uses what we use in tree printing for the CONST_STRINGs too. 2020-03-05 Jakub Jelinek PR middle-end/93399 * tree-pretty-print.h (pretty_print_string): Declare. * tree-pretty-print.c (pretty_print_string): Remove forward declaration, no longer static. Change nbytes parameter type from unsigned to size_t. * print-rtl.c (print_value) : Use pretty_print_string and for shrink way too long strings. * gcc.dg/pr93399.c: New test. (cherry picked from commit e0d6777cda966b04fc47d544c09839c4fa94343c)
[Bug c++/90995] [8 Regression] ICE in grokdeclarator, at cp/decl.c:12024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90995
--- Comment #11 from CVS Commits ---
The releases/gcc-8 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:feb0b5e3339e3b3f710c4f82d5997c1cd6af67ae
commit r8-10469-gfeb0b5e3339e3b3f710c4f82d5997c1cd6af67ae
Author: Jakub Jelinek
Date: Tue Mar 17 21:21:16 2020 +0100
c++: Fix parsing of invalid enum specifiers [PR90995]
The testcase shows some accepts-invalid (the ones without alignas) and
ice-on-invalid-code (the ones with alignas) cases.
If the enum doesn't have an underlying type and is not a definition,
the caller retries to parse it as elaborated type specifier.
E.g. for enum struct S s it will then pedwarn that elaborated type
specifier
shouldn't have the struct/class keywords.
The problem is if the enum specifier is not followed by { when it has
underlying type. In that case we have already called
cp_parser_parse_definitely to end the tentative parsing started at the
beginning of cp_parser_enum_specifier. But the
cp_parser_error (parser, "expected %<;%> or %<{%>");
doesn't emit any error because the whole function is called from yet
another
tentative parse and the caller starts parsing the elaborated type
specifier where the cp_parser_enum_specifier stopped (i.e. after the
underlying type token(s)). The ultimate caller than commits the tentative
parsing (and even if it wouldn't, it wouldn't know what kind of error
to report). I think after seeing enum {,struct,class} : type not being
followed by { or ;, there is no reason not to report it right away, as it
can't be valid C++, which is what the patch does. Not sure if we shouldn't
also return error_mark_node instead of NULL_TREE, so that the caller
doesn't
try to parse it as elaborated type specifier (the patch doesn't do that
right now).
Furthermore, while reading the code, I've noticed that
parser->colon_corrects_to_scope_p is saved and set to false at the start
of the function, but not restored back in some cases. Don't have a
testcase
where this would be a problem, but it just seems wrong. Either we can in
the two spots replace return NULL_TREE; with { type = NULL_TREE; goto out;
}
or we could perhaps abuse warning_sentinel or create a special class with
dtor to clean the flag up.
And lastly, I've fixed some formatting issues in the function while reading
it.
2020-03-17 Jakub Jelinek
PR c++/90995
* parser.c (cp_parser_enum_specifier): Use temp_override for
parser->colon_corrects_to_scope_p, replace goto out with return.
If scoped enum or enum with underlying type is not followed by
{ or ;, call cp_parser_commit_to_tentative_parse before calling
cp_parser_error and make sure to return error_mark_node instead of
NULL_TREE. Formatting fixes.
* g++.dg/cpp0x/enum40.C: New test.
(cherry picked from commit 980a7a0be5a114e285c49ab05ac70881e4f27fc3)
[Bug tree-optimization/94211] [8 Regression] -fcompare-debug failure on phi-opt-13.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94211 --- Comment #8 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2b0aaa4970a8d174b00fb98b4d24550d1c9a4e3a commit r8-10471-g2b0aaa4970a8d174b00fb98b4d24550d1c9a4e3a Author: Jakub Jelinek Date: Thu Mar 19 10:24:16 2020 +0100 phiopt: Avoid -fcompare-debug bug in phiopt [PR94211] Two years ago, I've added support for up to 2 simple preparation statements in value_replacement, but the - && estimate_num_insns (assign, &eni_time_weights) + && estimate_num_insns (bb_seq (middle_bb), &eni_time_weights) change, meant that we compute the cost of all those statements rather than just the single assign that has been the single supported non-debug statement in the bb before, doesn't do what I thought would do, gimple_seq is just gimple * and thus it can't be really overloaded depending on whether we pass a single gimple * or a whole sequence. Which means in the last two years it doesn't count all the statements, but only the first one. With -g that happens to be a DEBUG_STMT, or it could be e.g. the first preparation statement which could be much cheaper than the actual assign. 2020-03-19 Jakub Jelinek PR tree-optimization/94211 * tree-ssa-phiopt.c (value_replacement): Use estimate_num_insns_seq instead of estimate_num_insns for bb_seq (middle_bb). Rename emtpy_or_with_defined_p variable to empty_or_with_defined_p, adjust all uses. * gcc.dg/pr94211.c: New test. (cherry picked from commit 8db876e9c045c57d2dc5bd08a6e250f822efaad0)
[Bug c++/93931] ICE using lambda capture in openMP parallel for reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93931 --- Comment #6 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4ef4c88af7007ff0563e65269e1807b1ba30085d commit r8-10472-g4ef4c88af7007ff0563e65269e1807b1ba30085d Author: Jakub Jelinek Date: Thu Mar 19 12:22:47 2020 +0100 c++: Fix up handling of captured vars in lambdas in OpenMP clauses [PR93931] Without the parser.c change we were ICEing on the testcase, because while the uses of the captured vars inside of the constructs were replaced with capture proxy decls, we didn't do that for decls in OpenMP clauses. With that fixed, we don't ICE anymore, but the testcase is miscompiled and FAILs at runtime. This is because the capture proxy decls have DECL_VALUE_EXPR and during gimplification we were gimplifying those to their DECL_VALUE_EXPRs. That is fine for shared vars, but for privatized ones we must not do that. So that is what the cp-gimplify.c changes do. Had to add a DECL_CONTEXT check before calling is_capture_proxy because some VAR_DECLs don't have DECL_CONTEXT set (yet) and is_capture_proxy relies on that being non-NULL always. 2020-03-19 Jakub Jelinek PR c++/93931 * parser.c (cp_parser_omp_var_list_no_open): Call process_outer_var_ref on outer_automatic_var_p decls. * cp-gimplify.c (cxx_omp_disregard_value_expr): Return true also for capture proxy decls. * testsuite/libgomp.c++/pr93931.C: New test. (cherry picked from commit 484206967f958fc47827a71654fe52a98adc95cb)
[Bug target/94121] ICE on aarch64-linux-gnu: in abs_hwi, at hwint.h:324
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94121 --- Comment #10 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5f6826f724348c4e1317c15ea4cea01d5604fc39 commit r8-10461-g5f6826f724348c4e1317c15ea4cea01d5604fc39 Author: Jakub Jelinek Date: Wed Mar 11 10:54:22 2020 +0100 aarch64: Fix ICE in aarch64_add_offset_1 [PR94121] abs_hwi asserts that the argument is not HOST_WIDE_INT_MIN and as the (invalid) testcase shows, the function can be called with such an offset. The following patch is IMHO minimal fix, absu_hwi unlike abs_hwi allows even that value and will return (unsigned HOST_WIDE_INT) HOST_WIDE_INT_MIN in that case. The function then uses moffset in two spots which wouldn't care if the value is (unsigned HOST_WIDE_INT) HOST_WIDE_INT_MIN or HOST_WIDE_INT_MIN and wouldn't accept it (!moffset and aarch64_uimm12_shift (moffset)), then in one spot where the signedness of moffset does matter and using unsigned is the right thing - moffset < 0x100 - and finally has code which will handle even this value right; the assembler doesn't really care for DImode immediates if mov x1, -9223372036854775808 or mov x1, 9223372036854775808 is used and similarly it doesn't matter if we add or sub it in DImode. 2020-03-11 Jakub Jelinek PR target/94121 * config/aarch64/aarch64.c (aarch64_add_offset_1): Use absu_hwi instead of abs_hwi, change moffset type to unsigned HOST_WIDE_INT. * gcc.dg/pr94121.c: New test. (cherry picked from commit a644079a702a6228df2ffaace1d88a5f74e4bb9f)
[Bug middle-end/94111] Wrong constant folding: decimal floating-point infinity casted to double -> zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94111
--- Comment #7 from CVS Commits ---
The releases/gcc-8 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:8b53a85254e91903018498d70b59928b0d1dd9f9
commit r8-10460-g8b53a85254e91903018498d70b59928b0d1dd9f9
Author: Jakub Jelinek
Date: Wed Mar 11 09:33:52 2020 +0100
dfp: Fix decimal_to_binary [PR94111]
As e.g. decimal_from_decnumber shows, the REAL_VALUE_TYPE representation
contains a decimal128 embedded in ->sig only if it is rvc_normal, for
other kinds like rvc_inf or rvc_nan, ->sig is ignored and everything is
contained in the REAL_VALUE_TYPE flags (cl, sign, signalling and decimal).
decimal_to_binary which is used when folding a decimal{32,64,128} constant
to a binary floating point type ignores this and thus folds infinities and
NaNs into +0.0.
The following patch fixes that by only doing that for rvc_normal.
Similarly to the binary to decimal folding, it goes through a string, in
order to e.g. deal with canonical NaN mantissas, or binary float formats
that don't support infinities and/or NaNs.
2020-03-11 Jakub Jelinek
PR middle-end/94111
* dfp.c (decimal_to_binary): Only use decimal128ToString if
from->cl
is rvc_normal, otherwise use real_to_decimal to print the number to
string.
* gcc.dg/dfp/pr94111.c: New test.
(cherry picked from commit 343c467ccdc24edb9acd7c60d54914d9656ab499)
[Bug debug/94283] [8 Regression] gcc: error: gcc/testsuite/gcc.dg/fold-bopcond-1.c: ‘-fcompare-debug’ failure since r7-4804-gb54819879e0518b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94283 --- Comment #10 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c9790fa67882765eb293774e629cd071de857952 commit r8-10473-gc9790fa67882765eb293774e629cd071de857952 Author: Jakub Jelinek Date: Tue Apr 7 20:57:37 2020 +0200 if-conv: Fix -fcompare-debug bugs in ifcvt_local_dce [PR94283] The following testcase shows -fcompare-debug bugs in ifcvt_local_dce, where the decisions what statements are needed is based also on debug stmt operands, which is wrong. So, this patch makes sure to never add debug stmt to the worklist, or never add an assign to worklist just because it is used in a debug stmt in another bb. 2020-03-24 Jakub Jelinek PR debug/94283 * tree-if-conv.c (ifcvt_local_dce): For gimple debug stmts, just set GF_PLF_2, but don't add them to worklist. Don't add an assigment to worklist or set GF_PLF_2 just because it is used in a debug stmt in another bb. Formatting improvements. * gcc.target/i386/pr94283.c: New test. (cherry picked from commit 4dcfd4e56b0d22af12750372f3e0b49249b1d473)
[Bug c/97087] New: [11 regression] 70x slow -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97087 Bug ID: 97087 Summary: [11 regression] 70x slow -O3 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dimhen at gmail dot com Target Milestone: --- Created attachment 49234 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49234&action=edit -O3 slowdown 70x gcc -O3 -c y.i r11-3192 0.06s r11-3210 3.45s r11-3234 3.61s gcc -O2 -c y.i r11-3192 0.05s r11-3210 0.05s r11-3234 0.05s $ ~/arch-gcc/gcc_current/bin/gcc -v Using built-in specs. COLLECT_GCC=/home/dimhen/arch-gcc/gcc_current/bin/gcc COLLECT_LTO_WRAPPER=/home/dimhen/arch-gcc/gcc_current/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none Target: x86_64-pc-linux-gnu Configured with: /home/dimhen/src/gcc_current/configure --prefix=/home/dimhen/arch-gcc/gcc_current --enable-checking=yes,df,fold,rtl,extra --enable-languages=c,c++,lto --disable-multilib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --enable-cet --with-tune=native Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.0.0 20200916 (experimental) [master revision 7d1be939e0f:e8cbe88c94b:aab6194d0898f5c592708fe2d44a14046b4d9097] (GCC)
[Bug c/97087] [11 regression] 70x slow -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97087 --- Comment #1 from Dmitry G. Dyachenko --- Created attachment 49235 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49235&action=edit unreduced file preprocessed openssl-1.1.0 crypto/blake2/blake2s.c compilition aborted after ~1h
[Bug libstdc++/97088] New: 17_intro/names.cc and experimental/names.cc fail with --disable-libstdcxx-pch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97088 Bug ID: 97088 Summary: 17_intro/names.cc and experimental/names.cc fail with --disable-libstdcxx-pch Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- When configuring gcc with --disable-libstdcxx-pch, two libstdc++ fail on arm (linux and newlib targets) and aarch64 (with newlib). For instance on arm-eabi (using newlib): In file included from /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v7ve+simd/hard/libstdc++-v3/include/cmath:45, from /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v7ve+simd/hard/libstdc++-v3/include/arm-none-eabi/bits/stdc++.h:41, from /libstdc++-v3/testsuite/17_intro/names.cc:203: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-eabi/include/math.h:194: error: expected ')' before ';' token /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-eabi/include/math.h:195: error: expected ')' before ';' token /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-eabi/include/math.h:196: error: expected ')' before ';' token /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-eabi/include/math.h:197: error: expected ')' before ';' token /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-eabi/include/math.h:198: error: expected ')' before ';' token /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-eabi/include/math.h:199: error: expected ')' before ';' token /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-eabi/include/math.h:200: error: expected ')' before ';' token /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-eabi/include/math.h:201: error: expected ')' before ';' token This happens because the testcase does #define x ( and "x" is used as parameter names in several function prototypes in newlib's math.h Similarly for arm-linux-gnueabi (with glibc), I can see: In file included from /aci-gcc-fsf/builds/gcc-fsf-gccsrc/sysroot-arm-none-linux-gnueabi/usr/include/signal.h:306, from /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/csignal:42, from /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/arm-none-linux-gnueabi/bits/stdc++.h:43, from /libstdc++-v3/testsuite/17_intro/names.cc:203: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/sysroot-arm-none-linux-gnueabi/usr/include/sys/ucontext.h:89: error: expected unqualified-id before ':' token /aci-gcc-fsf/builds/gcc-fsf-gccsrc/sysroot-arm-none-linux-gnueabi/usr/include/sys/ucontext.h:89: error: expected ')' before ':' token When configured without --disable-libstdcxx-pch, the pch feature is auto-enabled, and the testcase is compiled with -include bits/stdc++.h which avoids the problem. I think this is a problem with the test.
[Bug fortran/95654] nvptx offloading: FAIL: libgomp.fortran/pr66199-5.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95654
--- Comment #13 from Tom de Vries ---
(In reply to Tom de Vries from comment #11)
> My guess at this point, is that duplicating the block with VOTE_ANY has the
> effect that the JIT compiler doesn't recognize control flow divergence
> before XCHG_IDX, and fails to insert the proper barrier.
Turns out, it's not that complicated.
Before ftracer we have:
...
[local count: 268435456]:
_30 = _18 + _27;
_31 = _18 + _28;
_46 = .GOMP_SIMT_ENTER_ALLOC (0, 1);
_47 = .GOMP_SIMT_LANE ();
_48 = (int) _47;
_49 = _30 + _48;
if (_31 > _49)
goto ; [87.50%]
else
goto ; [12.50%]
[local count: 117440512]:
...
goto ; [100.00%]
[local count: 134217728]:
# _54 = PHI <_50(D)(4), _67(8)>
# _34 = PHI <_49(4), _71(8)>
_55 = _34 == 63;
_56 = (int) _55;
_57 = .GOMP_SIMT_VOTE_ANY (_56);
if (_57 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 67108864]:
_58 = .GOMP_SIMT_LAST_LANE (_56);
_60 = .GOMP_SIMT_XCHG_IDX (_54, _58);
_61 = _60 + 1;
goto ; [100.00%]
[local count: 268435456]:
# d1_6 = PHI <_61(7), d1_29(D)(5)>
*_46 ={v} {CLOBBER};
.GOMP_SIMT_EXIT (_46);
if (_31 == 32)
goto ; [34.00%]
else
goto ; [66.00%]
...
At bb4 entry, we have unified control flow (that is, all threads in the warp
execute the same code in lockstep).
That's no longer the case at bb5/bb8. In team 0, threads 0..15 execute the
loop body (bb8), and threads 16..31 don't. In team 1, it's the opposite.
However, at bb5 the control flow from bb4 and bb8 joins, so control flow is
once again unified.
Then VOTE_ANY is executed in bb5, with team 1 subsequently going to the block
with XCHG_IDX (bb 7), and team 0, skipping straight to bb6.
After ftracer, we have:
...
[local count: 16777216]:
# _54 = PHI <_50(D)(4)>
# _34 = PHI <_49(4)>
_55 = _34 == 63;
_56 = (int) _55;
_57 = .GOMP_SIMT_VOTE_ANY (_56);
if (_57 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 117440512]:
...
_80 = _71 == 63;
_81 = (int) _80;
_82 = .GOMP_SIMT_VOTE_ANY (_81);
if (_82 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
...
Now control flow no longer is unified at bb 5, and consequently it's not in bb7
when executing XCHG_IDX. And that's the root cause for the failure we're
seeing.
So, one way to handle this it to consider VOTE_ANY as a "join" to the "fork" of
ENTER_ALLOC (which means: don't duplicate, unless you duplicate the pair).
But, after reading this:
...
/* Allocate per-lane storage and begin non-uniform execution region. */
static void
expand_GOMP_SIMT_ENTER_ALLOC (internal_fn, gcall *stmt)
...
and this:
...
/* Deallocate per-lane storage and leave non-uniform execution region. */
static void
expand_GOMP_SIMT_EXIT (internal_fn, gcall *stmt)
...
it seems that spot is already taken.
So I wonder, isn't the problem that we do the lastprivate stuff before
SIMT_EXIT. [ Of course after fixing that we might run into SIMT_EXIT being
duplicated by ftracer. But there at least the description of the internal-fn
would make it clear why we don't want to duplicate it. ]
[Bug tree-optimization/97089] New: [11 regression] execution FAILs for gfortran.dg/array_constructor_11.f90 after r11-3258
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97089 Bug ID: 97089 Summary: [11 regression] execution FAILs for gfortran.dg/array_constructor_11.f90 after r11-3258 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:c7f4be78cb61006492d16375aba5392f580cd633, r11-3258 make -k check-gcc-fortran RUNTESTFLAGS=dg.exp=gfortran.dg/array_constructor_11.f90 spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-trunk/gcc/testsuite/gfortran/../../gfortran -B/home/seurer/gcc/git/build/gcc-trunk/gcc/testsuite/gfortran/../../ -B/home/seurer/gcc/git/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgfortran/ /home/seurer/gcc/git/gcc-trunk/gcc/testsuite/gfortran.dg/array_constructor_11.f90 -fdiagnostics-plain-output -fdiagnostics-plain-output -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions -Wzerotrip -B/home/seurer/gcc/git/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/git/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/git/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/git/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libatomic/.libs -B/home/seurer/gcc/git/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libquadmath/.libs -L/home/seurer/gcc/git/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libquadmath/.libs -L/home/seurer/gcc/git/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libquadmath/.libs -lm -o ./array_constructor_11.exe /home/seurer/gcc/git/gcc-trunk/gcc/testsuite/gfortran.dg/array_constructor_11.f90:14:41: Warning: DO loop at (1) will be executed zero times [-Wzerotrip] /home/seurer/gcc/git/gcc-trunk/gcc/testsuite/gfortran.dg/array_constructor_11.f90:18:47: Warning: DO loop at (1) will be executed zero times [-Wzerotrip] /home/seurer/gcc/git/gcc-trunk/gcc/testsuite/gfortran.dg/array_constructor_11.f90:25:45: Warning: DO loop at (1) will be executed zero times [-Wzerotrip] /home/seurer/gcc/git/gcc-trunk/gcc/testsuite/gfortran.dg/array_constructor_11.f90:26:48: Warning: DO loop at (1) will be executed zero times [-Wzerotrip] /home/seurer/gcc/git/gcc-trunk/gcc/testsuite/gfortran.dg/array_constructor_11.f90:27:49: Warning: DO loop at (1) will be executed zero times [-Wzerotrip] PASS: gfortran.dg/array_constructor_11.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for warnings, line 14) PASS: gfortran.dg/array_constructor_11.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for warnings, line 18) PASS: gfortran.dg/array_constructor_11.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for warnings, line 25) PASS: gfortran.dg/array_constructor_11.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for warnings, line 26) PASS: gfortran.dg/array_constructor_11.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for warnings, line 27) PASS: gfortran.dg/array_constructor_11.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) Setting LD_LIBRARY_PATH to .:/home/seurer/gcc/git/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/git/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/git/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libatomic/.libs:/home/seurer/gcc/git/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/git/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/git/build/gcc-trunk/gcc/testsuite/gfortran/../..:.:/home/seurer/gcc/git/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/git/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/git/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libatomic/.libs:/home/seurer/gcc/git/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/git/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/git/build/gcc-trunk/gcc/testsuite/gfortran/../..:/home/seurer/gcc/git/build/gcc-trunk/./gmp/.libs:/home/seurer/gcc/git/build/gcc-trunk/./prev-gmp/.libs:/home/seurer/gcc/git/build/gcc-trunk/./mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-trunk/./prev-mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-trunk/./mpc/src/.libs:/home/seurer/gcc/git/build/gcc-trunk/./prev-mpc/src/.libs:/home/seurer/gcc/git/build/gcc-trunk/./isl/.libs:/home/seurer/gcc/git/build/gcc-trunk/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.4.0/lib64 Execution timeout is: 300 spawn [open ...] STOP 1 FAIL: gfortr
[Bug analyzer/97090] New: gcc.dg/analyzer/malloc-vs-local-1b.c fails on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090 Bug ID: 97090 Summary: gcc.dg/analyzer/malloc-vs-local-1b.c fails on arm Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Between r11-3230 and r11-3249 (g:052204fac580b21c967e57e6285d99a9828b8fac and g:ecde1b0a467127714872785b9935fe7c580778f0), I've noticed: FAIL: gcc.dg/analyzer/malloc-vs-local-1b.c (test for bogus messages, line 170) on some arm targets. For instance: target arm-none-linux-gnueabi --with-mode arm --with-cpu cortex-a9 there is no such problem with arm-none-linux-gnueabihf and the same config flags.
[Bug preprocessor/96935] [9 Regression] ICE in subspan, at input.h:69
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96935 --- Comment #11 from Jan Smets --- Thanks. Fix verified.
[Bug libstdc++/97091] New: Demangling the name of the type of a lambda accepting variadic auto parameters fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97091
Bug ID: 97091
Summary: Demangling the name of the type of a lambda accepting
variadic auto parameters fails
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dominik.muth at gmx dot de
Target Milestone: ---
Demangling the mangled name of [](auto...){} fails with gcc 5, 8, 9, 10, and
11.
It works with gcc 6 and 7, however the mangled name is different, see output
below. The demangled name main::{lambda(auto:1, ...)#1} looks wrong to me.
Should it be main::{lambda(auto:1...)#1} instead?
Here is a fairly minimal example to reproduce the bug:
// https://wandbox.org/permlink/FVonGE60X1Xi651E
#include
#include
using namespace std;
template
static string nametype(T v)
{
return typeid(decltype(v)).name();
}
template
static string strtype(T v)
{
return abi::__cxa_demangle(nametype(v).c_str(), nullptr, nullptr, nullptr);
}
template
static void puttype(T v)
{
cout << nametype(v) << endl;
cout << "-> " << strtype(v) << endl;
}
int main()
{
cout << __GNUC__ << "." << __GNUC_MINOR__ << "." << __GNUC_PATCHLEVEL__ <<
" " << __GLIBCXX__ << endl;
puttype([](auto...){});
}
/*
output:
5.5.0 20171010
Z4mainEUlT_zE_
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid
6.3.0 20161221
Z4mainEUlT_zE_
-> main::{lambda(auto:1, ...)#1}
7.3.0 20180125
Z4mainEUlT_zE_
-> main::{lambda(auto:1, ...)#1}
8.3.0 20190222
Z4mainEUlDpT_E0_
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid
9.3.0 20200312
Z4mainEUlDpT_E0_
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid
10.1.0 20200507
Z4mainEUlDpT_E_
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid
11.0.0 20200915
Z4mainEUlDpT_E_
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid
*/
[Bug libstdc++/97088] 17_intro/names.cc and experimental/names.cc fail with --disable-libstdcxx-pch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97088 --- Comment #1 from joseph at codesourcery dot com --- On Thu, 17 Sep 2020, clyon at gcc dot gnu.org wrote: > This happens because the testcase does > #define x ( > and "x" is used as parameter names in several function prototypes in newlib's > math.h That's a bug in newlib, which should be fixed there.
[Bug tree-optimization/96295] [11 Regression] -Wmaybe-uninitialized warning for range operator with reference to an empty struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96295 Martin Sebor changed: What|Removed |Added CC||vincent.lebourlot@starqube. ||com --- Comment #5 from Martin Sebor --- *** Bug 97067 has been marked as a duplicate of this bug. ***
[Bug sanitizer/97067] UBSAN: False positive maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97067 Martin Sebor changed: What|Removed |Added Resolution|--- |DUPLICATE CC||msebor at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from Martin Sebor --- I'm not able to reproduce the warning on trunk. I'm assuming it's been fixed by r11-3237 (pr96295). If the warning persists, please reopen the bug and provide all the information requested at https://gcc.gnu.org/bugs. *** This bug has been marked as a duplicate of bug 96295 ***
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 97067, which changed state. Bug 97067 Summary: UBSAN: False positive maybe-uninitialized https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97067 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug target/97086] aix: ceilf and truncf do not preserve the sign bit when output is rounded to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97086 Andrew Pinski changed: What|Removed |Added Component|c++ |target --- Comment #1 from Andrew Pinski --- This might NOT be a GCC issue but rather an issue with the libc that AIX has.
[Bug target/97083] __builtin_lround and _builtin_llround not replaced with fcvtas on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97083 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug rtl-optimization/97092] New: [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
Bug ID: 97092
Summary: [10/11 Regression] aarch64, SVE: ICE in ira-color.c
since r10-4752-g2d56600c
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
For the following testcase:
void g(void);
long a;
signed char b(int c, int d) { return c + d; }
void e(void) {
int f;
for (; (long)e < 4;) {
f = 0;
for (; f < 10; f++);
g();
a = -4;
for (; a; a = b(a, 1));
}
}
AArch64 GCC ICEs in IRA when compiling with -O1 -ftree-vectorize
-march=armv8.2-a+sve:
$ aarch64-none-elf-gcc -O1 -ftree-vectorize -march=armv8.2-a+sve test.c -c -S
during RTL pass: ira
test.c: In function 'e':
test.c:13:1: internal compiler error: in paradoxical_subreg_p, at rtl.h:3170
13 | }
| ^
0xb56ebb paradoxical_subreg_p(machine_mode, machine_mode)
/home/alecop01/toolchain/src/gcc/gcc/rtl.h:3170
0xb56ebb narrower_subreg_mode(machine_mode, machine_mode)
/home/alecop01/toolchain/src/gcc/gcc/rtl.h:3200
0xb56ebb update_costs_from_allocno
/home/alecop01/toolchain/src/gcc/gcc/ira-color.c:1410
0xb574ed update_costs_from_copies
/home/alecop01/toolchain/src/gcc/gcc/ira-color.c:1478
0xb585b8 assign_hard_reg
/home/alecop01/toolchain/src/gcc/gcc/ira-color.c:1969
0xb61321 pop_allocnos_from_stack
/home/alecop01/toolchain/src/gcc/gcc/ira-color.c:2707
0xb61321 color_allocnos
/home/alecop01/toolchain/src/gcc/gcc/ira-color.c:3251
0xb61321 color_pass
/home/alecop01/toolchain/src/gcc/gcc/ira-color.c:3363
0xb4ad3f ira_traverse_loop_tree(bool, ira_loop_tree_node*, void
(*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*))
/home/alecop01/toolchain/src/gcc/gcc/ira-build.c:1778
0xb5d464 do_coloring
/home/alecop01/toolchain/src/gcc/gcc/ira-color.c:3514
0xb5d464 color
/home/alecop01/toolchain/src/gcc/gcc/ira-color.c:4885
0xb5d464 ira_color()
/home/alecop01/toolchain/src/gcc/gcc/ira-color.c:5014
0xb4339f ira
/home/alecop01/toolchain/src/gcc/gcc/ira.c:5368
0xb4339f execute
/home/alecop01/toolchain/src/gcc/gcc/ira.c:5668
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/97093] New: ICE on C++20 code: memory corruption when chaining requirements (in hashtab_chk_error, at hash-table.c:137)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97093
Bug ID: 97093
Summary: ICE on C++20 code: memory corruption when chaining
requirements (in hashtab_chk_error, at
hash-table.c:137)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dimitri.gorokhovik at free dot fr
Target Milestone: ---
The following code:
template
concept C = requires (T t)
{
requires t.some_const < 2
#if BUG
|| requires { t.some_fn (); }
#endif
;
};
template
struct c
{};
template
concept P = requires (T t, c <0, 1> v)
{
#if BUG
{ t (v) };
#else
true;
#endif
};
template
struct m
{
constexpr auto operator () (C auto) const
{};
};
struct pc
{
constexpr auto operator () (C auto) const
{};
};
constexpr auto cc = pc {};
constexpr auto mmcc = m {};
when compiled as:
g++ -std=c++20 -fconcepts-diagnostics-depth=3 -o bug-5.o -c bug-5.cpp -DBUG=1
gives an ICE (stack traces below) with a frequency of 60-70% -- might need to
run it a few times to see. Defining BUG to > 0 and setting
-fconcepts-diagnostics-depth to > 2 are required to reproduce.
Version:
g++ (GCC) 11.0.0 20200917 (experimental)
Output from the compiler:
dgorokho@desktop:~/Sources/Rete$ /home/dgorokho/gcc-trunk/trunk/dist/bin/g++
-std=c++20 -fconcepts-diagnostics-depth=25 -o bug-5.o -c bug-5.cpp -DBUG=1
bug-5.cpp:43:28: error: placeholder constraints not satisfied
43 | constexpr auto mmcc = m {};
|^
bug-5.cpp:43:28: note: constraints not satisfied
bug-5.cpp:18:9: required for the satisfaction of ‘P’
bug-5.cpp:18:13: in requirements with ‘T t’, ‘c<0, 1> v’ [with T = pc]
bug-5.cpp:21:7: note: the required expression ‘t(v)’ is invalid, because
21 | { t (v) };
| ~~^~~
bug-5.cpp:21:7: error: no match for call to ‘(pc) (c<0, 1>&)’
bug-5.cpp:37:18: note: candidate: ‘template requires C
constexpr auto pc::operator()(auto:2) const’
37 | constexpr auto operator () (C auto) const
| ^~~~
bug-5.cpp:37:18: note: template argument deduction/substitution failed:
bug-5.cpp:37:18: note: constraints not satisfied
bug-5.cpp: In substitution of ‘template requires C
constexpr auto pc::operator()(auto:2) const [with auto:2 = c<0, 1>]’:
bug-5.cpp:21:7: required from here
bug-5.cpp:2:9: required for the satisfaction of ‘C’ [with auto:2 =
c<0, 1>]
bug-5.cpp:2:14: in requirements with ‘T t’ [with T = c<0, 1>]
bug-5.cpp:6:3: note: nested requirement ‘((t.some_const < 2) ||
requires{t.some_fn();})’ is not satisfied, because
4 | requires t.some_const < 2
|
5 | #if BUG
| ~~~
6 | || requires { t.some_fn (); }
| ^
hash table checking failed: equal operator returns true for a pair of values
with a different hash value
bug-5.cpp:4:12: internal compiler error: in hashtab_chk_error, at
hash-table.c:137
4 | requires t.some_const < 2
| ~^~~~
5 | #if BUG
| ~~~
6 | || requires { t.some_fn (); }
| ~
0x88c89a hashtab_chk_error()
../../src/gcc/hash-table.c:137
0x8f276c hash_table::verify(sat_entry* const&,
unsigned int)
../../src/gcc/hash-table.h:1033
0x8f292b hash_table::find_with_hash(sat_entry*
const&, unsigned int)
../../src/gcc/hash-table.h:918
0x8f0806 satisfy_constraint_r
../../src/gcc/hash-table.h:430
0x8f05c5 satisfy_constraint_r
../../src/gcc/cp/constraint.cc:2482
0x8f0db8 satisfy_constraint
../../src/gcc/cp/constraint.cc:2701
0x8f00b3 diagnose_nested_requirement
../../src/gcc/cp/constraint.cc:3413
0x8f00b3 diagnose_requirement
../../src/gcc/cp/constraint.cc:3433
0x8f00b3 diagnose_requires_expr
../../src/gcc/cp/constraint.cc:3457
0x8f00b3 diagnose_atomic_constraint
../../src/gcc/cp/constraint.cc:3493
0x8f0c58 satisfy_constraint_r
../../src/gcc/cp/constraint.cc:2652
0x8f0db8 satisfy_constraint
../../src/gcc/cp/constraint.cc:2701
0x8f20ed constraint_satisfaction_value
../../src/gcc/cp/constraint.cc:2719
0x8f2187 diagnose_constraints(unsigned int, tree_node*, tree_node*)
../../src/gcc/cp/constraint.cc:3563
0xa5196c fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
../../src/gcc/cp/pt.c:21317
0x8a1378 print_z_candidate
../../src/gcc/cp/call.c:3788
0x8a2e2f print_z_candidates
../../src/gcc/cp/call.c:3868
0x8b0713 build_op_call_1
../../src/gcc/cp/call.c:4893
0x8b0713 build_op_call(tree_node*, vec**, int)
../../src/gcc/cp/call.c
[Bug c++/90995] [8 Regression] ICE in grokdeclarator, at cp/decl.c:12024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90995 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Jakub Jelinek --- Fixed for 8.5 too.
[Bug middle-end/93399] [8 Regression] Annotate assembler option failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93399 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from Jakub Jelinek --- Fixed for 8.5 too.
[Bug middle-end/93566] [8 Regression] tree-nested.c ICE on C OpenMP array section reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93566 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Jakub Jelinek --- Fixed for 8.5 too.
[Bug fortran/93553] ICE in scan_omp_1_op, at omp-low.c:3485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93553 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Jakub Jelinek --- Fixed for 8.5 in r8-10510-g6b326d90d2195f00eb37dbf1be963ee3880af3b9 , and by above commits for 9.4+, 10.3+ and 11.1+.
[Bug target/94046] cast to __m256d in mask argument of avx2 float gather intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94046 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Fixed for 8.5 too.
[Bug c++/93931] ICE using lambda capture in openMP parallel for reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93931 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Jakub Jelinek --- Fixed for 8.5 and 9.4+ too.
[Bug tree-optimization/94114] [8 Regression] ICE in gimplify_modify_expr, at gimplify.c:5936
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94114 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Jakub Jelinek --- Fixed for 8.5 too.
[Bug middle-end/94111] Wrong constant folding: decimal floating-point infinity casted to double -> zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94111 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jakub Jelinek --- Fixed for 8.5, 9.4+, 10.1+.
[Bug target/94121] ICE on aarch64-linux-gnu: in abs_hwi, at hwint.h:324
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94121 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Jakub Jelinek --- Fixed for 8.5, 9.4+ and 10.1+.
[Bug tree-optimization/94130] [8 Regression] Unintended result with optimization option when assigning two structures, memset and 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94130 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Jakub Jelinek --- Fixed for 8.5 too.
[Bug target/94134] pdp11-aout puts initial variable into .text section rather than .data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94134 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Jakub Jelinek --- Should be now fixed for 8.5 and 9.4+ too.
[Bug c/94172] [arm-none-eabi] ICE in expand_debug_locations, at cfgexpand.c:5403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94172 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Jakub Jelinek --- Fixed for 8.5 and 9.4+ too.
[Bug debug/94167] [8 Regression] pr71109.c -fcompare-debug failures on x86_64 and powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94167 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Should be now fixed for 8.5 too.
[Bug tree-optimization/94211] [8 Regression] -fcompare-debug failure on phi-opt-13.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94211 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Jakub Jelinek --- Fixed for 8.5 too.
[Bug debug/94283] [8 Regression] gcc: error: gcc/testsuite/gcc.dg/fold-bopcond-1.c: ‘-fcompare-debug’ failure since r7-4804-gb54819879e0518b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94283 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Jakub Jelinek --- Fixed for 8.5 too.
[Bug middle-end/94303] [8 Regression] Program result error When using global object array (partially initialized with a special constructor, and the rest with the default constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94303 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Jakub Jelinek --- Fixed for 8.5 in r8-10475-g0aa738f8d4469434c131dc36711a045cfd8ecd7f too.
[Bug sanitizer/94325] [8/9 Regression] UBSAN: "invalid vptr" false positive for virtual inheritance with -fno-sanitize-recover=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94325 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed for 8.5 in r8-10484-g1298b488c37c44abf33cca6932e760ef69dd7815 and by the above commit for 9.4+ too.
[Bug tree-optimization/94329] [8 Regression] error: use_only.f90: ‘-fcompare-debug’ failure (length)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94329 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed for 8.5 in r8-10476-gc53f6b6c38fd3c61257c9f311ca9dc21135223b4.
[Bug target/94438] [8/9 Regression] ICE: verify_gimple failed: position plus size exceeds size of referenced object in 'bit_field_ref' with -mavx512vbmi -mavx512vl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94438 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Jakub Jelinek --- Fixed for 8.5 in r8-10485-g212ae35e5a9b554748c1340015968fda1d1fa0d8 and by the above commit for 9.4+ too.
[Bug middle-end/94412] [8 Regression] wrong code with vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94412 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Jakub Jelinek --- Fixed for 8.5 in r8-10478-gff421cb31d2d51f337dffdaf6b008fe1737d239f too.
[Bug debug/94459] Missing c++ debug information for 'auto&' return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94459 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Fixed for 8.5 in r8-10481-gbd748b6b448ef47f56922ec67244037915f721c2 and by the above commit for 9.4+ too.
[Bug target/94460] wrong code with __builtin_ia32_phsubw256() or __builtin_ia32_phsubd256()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94460 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jakub Jelinek --- Fixed for 8.5 too in r8-10480-g6fc550e75d4aac02953510215abf8a76f9adeaaa .
[Bug target/94488] [AArch64] ICE on right shift of V2DImode by DImode shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94488 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jakub Jelinek --- Fixed for 8.5 too in r8-10482-g84d649d3c71e80269ebd9764652131c51ff4a895 .
[Bug target/94509] wrong code with -mavx512bw and __builtin_shuffle()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94509 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed for 8.5 too in r8-10483-g62138a256af79900ef9958e32806f5acc333bd93 .
[Bug tree-optimization/94524] [8/9 Regression] wrong code with vector modulo operation since r0-117580
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94524 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed for 8.5 in r8-10486-g7146b8fd63e5107f1cf896df92fbaed99aa5ac0d and for 9.4+ by the above commit too.
[Bug c++/94571] Error: Expected comma or semicolon, comma found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94571 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Jakub Jelinek --- Fixed for 8.5 in r8-10487-g189c10499d796877e22c7f019a2805099fab8509 and by the above commit for 9.4+ too.
[Bug rtl-optimization/94618] [8/9 Regression] '-fcompare-debug' failure (length) with -O2 -fnon-call-exceptions since r8-565-g7581ce9a1ad6df9c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94618 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from Jakub Jelinek --- Fixed for 8.5 in r8-10488-g00191dfc2914b2e66a3fbe50aa79ef6a5fc2be46 and by the above commit for 9.4+ too.
[Bug c/94641] -Wpadded -fsanitize=undefined together cause warning on main()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94641 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jakub Jelinek --- Fixed for 8.5 in r8-10489-g3e8a10bb21b4c830e1884ff43edd639eae5bf5ce and by the above commit for 9.4+ too.
[Bug c/94705] [8/9 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in diag_attr_exclusions, at attribs.c:396 since r8-5161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94705 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed for 8.5 in r8-10490-g1dd77eeccc2941323607e88a6fe37625a2dc6698 and by the above commit for 9.4+ too.
[Bug target/94710] [8/9 Regression] Assembler messages: Error: operand out of range (4 is not between 0 and 3) (xxsldwi 0,32,33,4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94710 --- Comment #12 from Jakub Jelinek --- Worked around for 8.5 in r8-10491-gb3a45adc90bbbdf7a62e9ff301b32f43ba93cdad and for 9.4+ by the above commit.
[Bug c++/94742] [8/9 Regression] Incorrect "no return statement" warning with [[noreturn]] and __FUNCTION__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94742 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed for 8.5 in r8-10492-g012e366a3928303aa1082876313e0bc3ea67190e and by the above commit for 9.4+ too.
