[Bug tree-optimization/98775] missing optimization opportunity on nbody
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98775 --- Comment #2 from Richard Biener --- A quick check comparing GCC 10 to GCC 11 shows an improvement from 3.5s to 2.7s on a Zen2 machine (with -march=native).
[Bug c++/98744] [11 Regression] ICE in gimple_call_arg, at gimple.h:3246 since r11-6735-g424deca72b63e644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98744 --- Comment #5 from Martin Liška --- > > Jason, is it possible a wrong constructor is emitted to the IL? > Thank you Martin for the analysis. That explains why the bisection point to Jason's revision. @Jason: Can you please take a look?
[Bug ipa/96431] [11 regression] ipa-clone-2.c fails since r11-2482-g13cdbb6a97c3d853cd380e5a03be8e0d35966c1e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96431 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Richard Biener --- It seems to work now on both arm and aarch64.
[Bug c++/98625] UBSAN: gcc/cp/module.cc:977:15: runtime error: left shift of negative value -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98625 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Martin Liška --- Fixed with: commit 911f797a9be2dc8ef59f5d5bd6d68baf650b8822 Author: Nathan Sidwell Date: Wed Jan 20 09:21:02 2021 -0800 c++: Avoid UB in signed shift [PR 98625] I'd forgotten that left shifting a negative value is UB until C++20. Insert some casts to do unsigned shifts. PT c++/98625 gcc/cp/ * module.cc (bytes_in::i, bytes_in::wi): Avoid left shift of signed type. @Nathan: That was very close, s/PT/PR :)
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 98625, which changed state. Bug 98625 Summary: UBSAN: gcc/cp/module.cc:977:15: runtime error: left shift of negative value -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98625 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/98777] New: [11 Regression] ICE in update_equiv at gcc/lra-constraints.c:504 since r11-6819-g4334b52427420312
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98777
Bug ID: 98777
Summary: [11 Regression] ICE in update_equiv at
gcc/lra-constraints.c:504 since
r11-6819-g4334b52427420312
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: vmakarov at gcc dot gnu.org
Target Milestone: ---
I see the following ICE with:
$ gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/sse4_1-set-v16qi-1.c
-m32 --param=max-iterations-to-track=1000 --param=max-completely-peeled-insns=0
-Ofast -funroll-loops -fno-forward-propagate -fsanitize=undefined
-fno-peel-loops -fno-isolate-erroneous-paths-dereference -Winvalid-pch
--param=hwasan-instrument-allocas=1 --param=max-delay-slot-insn-search=0
-fno-ivopts --param=modref-max-accesses=1542230368 -c
during RTL pass: reload
In file included from
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/sse4_1-check.h:4,
from
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/set-v16qi-1.h:5,
from
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/sse4_1-set-v16qi-1.c:8:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/m128-check.h: In
function ‘check_union128i_b’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/m128-check.h:96:1:
internal compiler error: Segmentation fault
96 | }
| ^
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/m128-check.h:99:1:
note: in expansion of macro ‘CHECK_EXP’
99 | CHECK_EXP (union128i_b, char, "%d")
| ^
0xe6ec5a crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:327
0xe5242a simplify_replace_fn_rtx(rtx_def*, rtx_def const*, rtx_def*
(*)(rtx_def*, rtx_def const*, void*), void*)
/home/marxin/Programming/gcc/gcc/simplify-rtx.c:515
0xcd93bb update_equiv
/home/marxin/Programming/gcc/gcc/lra-constraints.c:504
0xcd93bb lra_constraints(bool)
/home/marxin/Programming/gcc/gcc/lra-constraints.c:5035
0xcc559f lra(_IO_FILE*)
/home/marxin/Programming/gcc/gcc/lra.c:2332
0xc7e3c4 do_reload
/home/marxin/Programming/gcc/gcc/ira.c:5821
0xc7e3c4 execute
/home/marxin/Programming/gcc/gcc/ira.c:6007
or one can see it with riscv64 cross compiler for the following test-case:
$ cat struct-by-value.i
typedef struct {
_Complex e;
_Complex f;
_Complex g;
_Complex h;
_Complex i;
_Complex j;
_Complex k;
_Complex l;
_Complex m;
_Complex n;
_Complex o;
_Complex p;
} Scl16;
Scl16 g1sScl16, g2sScl16, g3sScl16, g4sScl16, g5sScl16, g6sScl16, g7sScl16,
g8sScl16, g9sScl16, g10sScl16, g11sScl16, g12sScl16, g13sScl16, g14sScl16,
g15sScl16, g16sScl16;
void testvaScl16();
void
testitScl16() {
testvaScl16(g10sScl16, g11sScl16, g12sScl16, g13sScl16, g14sScl16, g1sScl16,
g2sScl16, g3sScl16, g4sScl16, g5sScl16, g6sScl16, g7sScl16,
g8sScl16, g9sScl16, g10sScl16, g11sScl16, g12sScl16, g13sScl16,
g14sScl16, g15sScl16, g16sScl16);
}
$ ~/BIG/bin/riscv64/dev/shm/buildbot/install/gcc/bin/riscv64-linux-gnu-gcc
struct-by-value.i -fstrict-aliasing -O -c
during RTL pass: reload
struct-by-value.i: In function ‘testitScl16’:
struct-by-value.i:28:1: internal compiler error: Segmentation fault
28 | }
| ^
0xafe90f crash_signal
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/toplev.c:327
0xaea4b7 simplify_replace_fn_rtx(rtx_def*, rtx_def const*, rtx_def*
(*)(rtx_def*, rtx_def const*, void*), void*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/simplify-rtx.c:408
0x9a9348 update_equiv
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/lra-constraints.c:504
0x9a9348 lra_constraints(bool)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/lra-constraints.c:5035
0x997d62 lra(_IO_FILE*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/lra.c:2332
0x955f81 do_reload
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/ira.c:5821
0x955f81 execute
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/ira.c:6007
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug rtl-optimization/98777] [11 Regression] ICE in update_equiv at gcc/lra-constraints.c:504 since r11-6819-g4334b52427420312
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98777 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to fail||11.0 Ever confirmed|0 |1 Target Milestone|--- |11.0 Priority|P3 |P1 Last reconfirmed||2021-01-21 Known to work||10.2.0
[Bug inline-asm/98778] New: asm() accepts certain "i" (symbol) constructs despite -fpie for x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98778
Bug ID: 98778
Summary: asm() accepts certain "i" (symbol) constructs despite
-fpie for x86-64
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: jbeulich at suse dot com
Target Milestone: ---
While in the example below all 3 variants get refused ("impossible constraint")
with -fpic or with "-m32 -fpie", the ones in cases 0 and 2 get accepted with
just -fpie, producing non-position-independent code (or more precisely
unsuitable relocations).
void efn(void);
void(*efp)(void);
void*test(int i) {
void*res;
switch(i) {
case 0:
asm("mov %1,%0" : "=r" (res) : "i" (test));
break;
#ifndef __PIE__
case 1:
asm("mov %1,%0" : "=r" (res) : "i" (efn));
break;
#endif
case 2:
asm("mov %1,%0" : "=r" (res) : "i" (&efp));
break;
default:
res = (void*)0;
break;
}
return res;
}
[Bug testsuite/97299] [11 regression] gcc.dg/vect/slp-reduc-3.c fails after r11-3563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97299
--- Comment #7 from Richard Biener ---
Created attachment 50017
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50017&action=edit
patch
OK, so the arm fails are because they use load_lanes. Which means adjusting
like
/* { dg-final { scan-tree-dump-times "VEC_PERM_EXPR" 0 "vect" { xfail { {
vect_widen_sum_hi_to_si_pattern || { ! vect_unpack } } && { ! vect_load_lanes }
} } } } */
should work there. Then we have solaris which likely does not vectorize this
at all which means we need to condition all scans on the 'vectorized 1 loops'
scan. Meh, complicated target selectors :/
Rainer, can you test the attached patch?
[Bug testsuite/97299] [11 regression] gcc.dg/vect/slp-reduc-3.c fails after r11-3563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97299 --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #7 from Richard Biener --- > Created attachment 50017 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50017&action=edit > patch [...] > Rainer, can you test the attached patch? Sure, just did on sparc-sun-solaris2.11 and (for good measure) i386-pc-solaris2.11: worked fine on both. Thanks.
[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461 --- Comment #25 from Richard Biener --- How about allocating memory by other means (brk/mmap) instead? That is, run your own simple allocator? I suppose gcov never frees things (until the end) so it could be quite simple one? And fall back to static allocated counters for targets that we do not handle? Is there a command-line option to choose "static" counters? More possibilities involve libdl and dlsym to iterate to 'malloc' from a different shared object than the one profiled. Or on glibc platforms use __malloc instead of malloc (via alias). That said, using plain 'malloc' was a bad idea.
[Bug testsuite/98224] [11 regression] gcc.dg/Walloca-2.c XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98224 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Richard Biener --- Indeed. commit fa9d1ad2ff6578dccfa181d909f72e2cb745df63 (HEAD -> trunk, origin/master, origin/HEAD) Author: Richard Biener Date: Thu Jan 21 10:30:56 2021 +0100 testsuite/98224 - un-XFAIL Walloca-2.c on ilp32 As reported this now XPASSes with ranger. 2021-01-21 Richard Biener * gcc.dg/Walloca-2.c: Un-XFAIL.
[Bug testsuite/98241] [11 regression] gcc.dg/pr78973.c XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98241 --- Comment #1 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:8afef308b49c9d8dfe38fab7bbb5f6bb070b093d commit r11-6830-g8afef308b49c9d8dfe38fab7bbb5f6bb070b093d Author: Richard Biener Date: Thu Jan 21 10:35:11 2021 +0100 testsuite/98241 - remove ilp32 XFAIL of gcc.dg/pr78973.c XPASSes as reported. 2021-01-21 Richard Biener PR testsuite/98241 * gcc.dg/pr78973.c: Remove ilp32 XFAIL.
[Bug testsuite/98241] [11 regression] gcc.dg/pr78973.c XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98241 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Biener --- Done.
[Bug testsuite/98325] [11 regression] gcc.dg/pr25376.c fails after r11-5027
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98325 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Richard Biener --- PASSes with a ppc64le cross, assuming fixed.
[Bug target/98694] GCC produces incorrect code for loops with -O3 for skylake-avx512 and icelake-server
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98694 Richard Biener changed: What|Removed |Added Summary|[11 Regression] GCC |GCC produces incorrect code |produces incorrect code for |for loops with -O3 for |loops with -O3 for |skylake-avx512 and |skylake-avx512 and |icelake-server |icelake-server | Target Milestone|11.0|--- Known to work||11.0 --- Comment #10 from Richard Biener --- Fixed on trunk, latent on the branch(es) where we don't have a testcase(?)
[Bug libstdc++/94080] -mabi=ieeelongdouble and -mfloat128 cause libstc++ header breakage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94080 --- Comment #2 from Bill Schmidt --- Let's see, with patches from late last year, can this be closed now?
[Bug tree-optimization/85804] [8/9/10/11 Regression][AArch64] Mis-compilation of loop with strided array access and xor reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85804 Richard Biener changed: What|Removed |Added Status|NEW |WAITING --- Comment #12 from Richard Biener --- It looks like we now classify as VMAT_ELEMENTWISE (but we don't actually dump the choice) and fail to vectorize because of cost issues and the vectorization with -fno-vect-cost-model is different enough. So fixed on trunk? Can somebody bisect what fixed it? I suppose it was commit 04b99da898a9817e72fedb4063589648b7961ac5 Author: Richard Biener Date: Thu Oct 1 15:12:35 2020 +0200 tree-optimization/97236 - fix bad use of VMAT_CONTIGUOUS This avoids using VMAT_CONTIGUOUS with single-element interleaving when using V1mode vectors. Instead keep VMAT_ELEMENTWISE but continue to avoid load-lanes and gathers. 2020-10-01 Richard Biener PR tree-optimization/97236 * tree-vect-stmts.c (get_group_load_store_type): Keep VMAT_ELEMENTWISE for single-element vectors. * gcc.dg/vect/pr97236.c: New testcase. which sounds like a duplicate?
[Bug testsuite/97299] [11 regression] gcc.dg/vect/slp-reduc-3.c fails after r11-3563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97299 --- Comment #9 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:f46a40112caa7e039d949beda94386ff4e436a35 commit r11-6831-gf46a40112caa7e039d949beda94386ff4e436a35 Author: Richard Biener Date: Thu Jan 21 10:57:18 2021 +0100 testsuite/97299 - more gcc.dg/vect/slp-reduc-3.c massaging This adds more guards to the VEC_PERM_EXPR scan, namely that we also could end up with load-lanes and of course no vectorization at all. Need dependent scans (scan-if-scan-X PASSed ...). 2021-01-21 Richard Biener PR testsuite/97299 * gcc.dg/vect/slp-reduc-3.c: Amend target selectors.
[Bug testsuite/97299] [11 regression] gcc.dg/vect/slp-reduc-3.c fails after r11-3563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97299 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #10 from Richard Biener --- Fixed again (fingers crossing...)
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #28 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:eaf883710c0039eca5caea5115e848adb4ab67bd commit r11-6832-geaf883710c0039eca5caea5115e848adb4ab67bd Author: Paul Thomas Date: Thu Jan 21 10:00:00 2021 + Fortran: This patch fixes comments 23 and 24 of PR96320. 2021-01-21 Paul Thomas gcc/fortran PR fortran/96320 * decl.c (gfc_match_modproc): It is not an error to find a module procedure declaration within a contains block. * expr.c (gfc_check_vardef_context): Pure procedure result is assignable. Change 'own_scope' accordingly. * resolve.c (resolve_typebound_procedure): A procedure that has the module procedure attribute is almost certainly a module procedure, whatever its interface. gcc/testsuite/ PR fortran/96320 * gfortran.dg/module_procedure_5.f90 : New test. * gfortran.dg/module_procedure_6.f90 : New test.
[Bug ipa/98078] ICE in cgraph_add_edge_to_call_site_hash, at cgraph.c:698 since r6-1705-gd88511aec7338a93
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98078 --- Comment #4 from Martin Jambor --- Actually no, that would be papering over a bigger problem. After looking at the issue a bit more, I proposed a patch on the mailing list: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563962.html
[Bug libgcc/98779] New: [arm] libgcc incompatible with -mpure-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98779 Bug ID: 98779 Summary: [arm] libgcc incompatible with -mpure-code Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- As discussed in https://gcc.gnu.org/pipermail/gcc-patches/2021-January/562934.html some parts of libgcc for arm are incompatible with -mpure-code. There is currently no multilib using -mpure-code, so incompatible code may be silently linked from libgcc with code compiled with -mpure-code. The parts of libgcc written in C would be OK if compiled with -mpure-code, but the parts written in assembly would need to: - avoid the offending code sequences - be placed in a section with SHF_ARM_PURECODE It's probably undesirable to rewrite the assembly parts in a -mpure-code compatible way unconditionally: it has a negative impact on both performance and code size. It's not clear yet if we'd like to introduce a multilib for this case. We also have to keep in mind that the linker puts .text and .text.noread sections in different segments, and does not emit a warning when the two types of code are linked together. I have looked at which libgcc functions contain code incompatible with -mpure-code: * assembly, use constant pool __clzsi2 __ctzsi2 * macro test_div_by_zero in bpabi-v6m.S uses a constant pool __aeabi_ldivmod __aeabi_uldivmod * code in fixed-bit.c generates a constant pool if not compiled with -mpure-code: z = ((UINT_C_TYPE) 1) << I_F_BITS; if (x >= 0) z -= (UINT_C_TYPE) 1; ldr r3, .L8 lsrsr0, r2, #31 mov ip, r3 add r0, r0, ip b .L1 .L9: .align 2 .L8: .word 2147483647 this impacts the following functions: __gnu_ssaddsq3 __gnu_ssadddq3 __gnu_ssaddsa3 __gnu_ssaddda3 __gnu_sssubsq3 __gnu_sssubdq3 __gnu_sssubsa3 __gnu_sssubda3 __gnu_ssnegsq2 __gnu_ssnegdq2 __gnu_ssnegsa2 __gnu_ssnegda2 __gnu_usaddusq3 __gnu_usaddudq3 __gnu_usaddusa3 __gnu_usadduda3 __gnu_usnegusq2 __gnu_usnegudq2 __gnu_usnegusa2 __gnu_usneguda2 __gnu_fractqiusq __gnu_fractqiudq __gnu_fracthiusq __gnu_fracthiudq __gnu_fractsiusq __gnu_fractsiudq __gnu_fractdiusq __gnu_fractdiudq __gnu_satfractqqsq2 __gnu_satfractqqsa __gnu_satfracthqsq2 __gnu_satfractsqda __gnu_satfracthasq __gnu_satfracthasa2 __gnu_satfracthausq __gnu_satfracthaudq __gnu_satfractsasq __gnu_satfractsausq __gnu_satfractsaudq __gnu_satfractdausq __gnu_satfractdaudq __gnu_satfractuhasq __gnu_satfractuhadq __gnu_satfractuhausq __gnu_satfractuhaudq __gnu_satfractusasq __gnu_satfractusadq __gnu_satfractusausq __gnu_satfractusaudq __gnu_satfractudadq __gnu_satfractudaudq __gnu_satfractqisq __gnu_satfractqisa __gnu_satfracthisq __gnu_satfracthisa __gnu_satfractsisq __gnu_satfractsisa __gnu_satfractsiusa __gnu_satfractdiusq __gnu_satfractdiusa __gnu_satfractdiuda __gnu_fractunsqiusq __gnu_fractunsqiudq __gnu_fractunshiusq __gnu_fractunshiudq __gnu_fractunssiusq __gnu_fractunssiudq __gnu_fractunsdiusq __gnu_fractunsdiudq __gnu_satfractunsqisq __gnu_satfractunsqidq __gnu_satfractunsqisa __gnu_satfractunsqida __gnu_satfractunsqiusa __gnu_satfractunsqiuda __gnu_satfractunshisq __gnu_satfractunshidq __gnu_satfractunssisq __gnu_satfractunssidq __gnu_satfractunssisa __gnu_satfractunssiusa __gnu_satfractunsdisq __gnu_satfractunsdidq __gnu_satfractunsdisa __gnu_satfractunsdida __gnu_satfractunsdiuda Other functions performing load/stores outside of the stack include: __gnu_thumb1_case_sqi __gnu_thumb1_case_uqi __gnu_thumb1_case_shi __gnu_thumb1_case_uhi __gnu_thumb1_case_si These are OK, because they are used in PIC mode, which is incompatible with -mpure-code anyway. __gcc_bcmp __gnu_saturate1qq __gnu_saturate1hq __gnu_saturate1sq __gnu_saturate1ha __gnu_saturate1sa __gnu_saturate1uqq __gnu_saturate1uhq __gnu_saturate1uha __gnu_saturate1usa __gnu_saturate2dq __gnu_saturate2da __gnu_saturate2udq __gnu_saturate2uda __aeabi_uread4 __aeabi_uread8 __gnu_float2h_internal emutls_alloc These are OK as long as their pointer parameters point to data in suitable locations. Finally all the functions related to unwinding rely to their parameters pointing to data with read access rights.
[Bug debug/98780] New: Missing line table entry for inlined stmt at -g -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98780
Bug ID: 98780
Summary: Missing line table entry for inlined stmt at -g -O0
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Created attachment 50018
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50018&action=edit
source file
[ Spinoff of gdb PR25884 - "Stepping over inlined function without line number
statement fails" (https://sourceware.org/bugzilla/show_bug.cgi?id=25884). ]
Consider test source gdb/testsuite/gdb.opt/inline-cmds.c (attached).
When compiled with -O0 -g, this bit:
...
71result = 0; /* set breakpoint 3 here */
72
73func1 (); /* first call */
74func1 (); /* second call */
75marker ();
...
where func1 is:
...
33 inline __attribute__((always_inline)) int func1(void)
34 {
35bar ();
36return x * y;
37 }
...
is represented in the line info as:
...
Line numberStarting addressViewStmt
710x64 x
350x6e x
750x78 x
...
where the insn are:
...
64: c7 05 00 00 00 00 00movl $0x0,0x0(%rip)# 6e
6b: 00 00 00
6e: e8 00 00 00 00 callq 73
73: e8 00 00 00 00 callq 78
78: e8 00 00 00 00 callq 7d
...
The calls to bar at 6e and 73 represent different instantiations of the same
statement, but they get a single entry in the line table.
It would be more accurate to have two entries.
Note that each call to bar has its own DW_TAG_inlined_subroutine descriptor:
...
<2><11e>: Abbrev Number: 10 (DW_TAG_inlined_subroutine)
<11f> DW_AT_abstract_origin: <0x208>
<123> DW_AT_low_pc : 0x6e
<12b> DW_AT_high_pc : 0x5
<133> DW_AT_call_file : 1
<134> DW_AT_call_line : 73
<135> DW_AT_call_column : 3
<2><136>: Abbrev Number: 10 (DW_TAG_inlined_subroutine)
<137> DW_AT_abstract_origin: <0x208>
<13b> DW_AT_low_pc : 0x73
<143> DW_AT_high_pc : 0x5
<14b> DW_AT_call_file : 1
<14c> DW_AT_call_line : 74
<14d> DW_AT_call_column : 3
...
so at some level gcc knows that these are different statements.
[ The problem with gdb is that it ignores the DW_TAG_inlined_subroutine on the
second call because there's no corresponding line table entry. ]
[Bug c++/98750] does not detect dead code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98750 Jonathan Wakely changed: What|Removed |Added Ever confirmed|1 |0 Status|WAITING |UNCONFIRMED --- Comment #3 from Jonathan Wakely --- GCC's -Wunreachable was removed years ago.
[Bug c++/98744] [11 Regression] ICE in gimple_call_arg, at gimple.h:3246 since r11-6735-g424deca72b63e644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98744
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
If the testcase is compiled with -O0, then it looks clearly like a wrong-code:
B::B (_1);
is the call in C::C, while the ctor it is calling is:
void B::B (struct B * const this, const void * * __vtt_parm)
{
const void * _1;
:
_1 = *__vtt_parm_3(D);
this_4(D)->_vptr.B = _1;
return;
}
pushq %rbp
movq%rsp, %rbp
movq%rdi, -8(%rbp)
movq%rsi, -16(%rbp)
movq-16(%rbp), %rax
movq(%rax), %rdx
movq-8(%rbp), %rax
movq%rdx, (%rax)
nop
popq%rbp
and actually uses the second argument which is not passed.
[Bug debug/98780] Missing line table entry for inlined stmt at -g -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98780
--- Comment #1 from Tom de Vries ---
At final, we have:
...
(note 113 30 112 2 0x7f53d1836de0 NOTE_INSN_BLOCK_BEG)
(note 112 113 31 2 0x7f53d1836e40 NOTE_INSN_BLOCK_BEG)
(call_insn 31 112 114 2 (call (mem:QI (symbol_ref:DI ("bar") [flags 0x41]
) [0 bar S1 A8])
(const_int 0 [0])) "src/gdb/testsuite/gdb.opt/inline-cmds.c":35:3 813
{*call}
(nil)
(nil))
(note 114 31 115 2 0x7f53d1836e40 NOTE_INSN_BLOCK_END)
(note 115 114 117 2 0x7f53d1836de0 NOTE_INSN_BLOCK_END)
(note 117 115 116 2 0x7f53d1836d20 NOTE_INSN_BLOCK_BEG)
(note 116 117 38 2 0x7f53d1836d80 NOTE_INSN_BLOCK_BEG)
(call_insn 38 116 118 2 (call (mem:QI (symbol_ref:DI ("bar") [flags 0x41]
) [0 bar S1 A8])
(const_int 0 [0])) "src/gdb/testsuite/gdb.opt/inline-cmds.c":35:3 813
{*call}
(nil)
(nil))
(note 118 38 119 2 0x7f53d1836d80 NOTE_INSN_BLOCK_END)
(note 119 118 45 2 0x7f53d1836d20 NOTE_INSN_BLOCK_END)
...
So if we reset last_linenum when encountering a BLOCK_END:
...
diff --git a/gcc/final.c b/gcc/final.c
index b037e07fca0..a5da1ce7224 100644
--- a/gcc/final.c
+++ b/gcc/final.c
@@ -2385,6 +2385,8 @@ final_scan_insn_1 (rtx_insn *insn, FILE *file, int
optimize_p AT
TRIBUTE_UNUSED,
debug_hooks->end_block (high_block_linenum, n);
gcc_assert (BLOCK_IN_COLD_SECTION_P (NOTE_BLOCK (insn))
== in_cold_section_p);
+
+ last_linenum = 0;
}
if (write_symbols == DBX_DEBUG)
{
...
I get:
...
Line numberStarting addressViewStmt
710x64 x
350x6e x
350x73 x
750x78 x
...
[Bug target/98694] GCC produces incorrect code for loops with -O3 for skylake-avx512 and icelake-server
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98694 --- Comment #11 from Hongtao.liu --- (In reply to Richard Biener from comment #10) > Fixed on trunk, latent on the branch(es) where we don't have a testcase(?) Yes, not sure about the backport.
[Bug tree-optimization/98772] Widening patterns causing missed vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98772 --- Comment #2 from Joel Hutton --- Yes, it is aarch64, I have updated the field.
[Bug libstdc++/98781] New: Poor std::hash for bitset and vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98781
Bug ID: 98781
Summary: Poor std::hash for bitset and vector
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ABI
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
The std::hash specializations for std::bitset and std::vector do not
differentiate between sequences that have different number of zero bits at the
end, if they don't spill over into a new byte.
e.g. the following all have the same representation, a single byte with the low
bit set:
std::bitset<1> b1(1);
std::bitset<2> b2(1);
std::bitset<8> b8(1);
As a result, they all hash to the same value. This is less problematic for
std::bitset where they have different types anyway, but it's more noticeable
for std::vector:
std::vector b{true};
std::hash> h;
for (int i = 0; i < 10; ++i)
{
std::cout << b.size() << '\t' << h(b) << '\n';
b.push_back(false);
}
Each iteration produces different values (which don't compare equal) but the
hash value only changes when the size increases by a multiple of CHAR_BIT:
1 4334672815104069193
2 4334672815104069193
3 4334672815104069193
4 4334672815104069193
5 4334672815104069193
6 4334672815104069193
7 4334672815104069193
8 4334672815104069193
9 9994027557101822035
10 9994027557101822035
The hash function could combine the result of hashing the value bytes with the
hash of the sequence length. That would produce a distinct hash for each value
above. That would be an ABI change though, as different translation units could
give different hash results for the same inputs.
FWIW MSVC has the same problem, but the hash only changes for multiples of 32,
and libc++ never changes the result for any number of trailing zeros (it
appears to hash vector as a simple XOR of the integer words).
[Bug libstdc++/98781] Poor std::hash for bitset and vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98781 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-01-21 Severity|normal |enhancement --- Comment #1 from Jonathan Wakely --- We should consider this for the ABI-unstable "gnu-versioned-namespace" mode.
[Bug tree-optimization/98335] [9/10/11 Regression] Poor code generation for partial struct initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98335 --- Comment #5 from Jakub Jelinek --- So I think we want to improve that + /* If more than a word remains, then make sure to keep the + starting point at least word aligned. */ + if (last_live - first_live > UNITS_PER_WORD) +*trim_head &= (UNITS_PER_WORD - 1); Note, last_live is the start of the last live byte (so last_live + 1 is the end of that). For the small sizes, I'd say we should consider both alignment and exact head/tail trim values. Whole word store is definitely more efficient than 7 bytes store at offset 1, ditto head trim 2 and 3, storing just second half is ok. So shall we e.g. call by_pieces_ninsns for the before/after the expected triming and determine only trim if it doesn't increase number of by pieces store insns? It could also iterate on those.
[Bug target/92095] [8/9/10 regression] internal error with -O1 -mcpu=niagara2 -fPIE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92095 Romain Naour changed: What|Removed |Added CC||romain.naour at gmail dot com --- Comment #9 from Romain Naour --- Hello, This patch produce a regression on sparcv8 SS10 platform. In Buildroot we have a defconfig qemu_sparc_ss10_defconfig that was working (booting) with gcc 7.4, 8.3 and 9.2. But it doesn't boot anymore with gcc 8.4, 9.3 and 10.2. I reverted this patch to be able to boot the system. See: http://patchwork.ozlabs.org/project/buildroot/patch/20210120230234.2086807-1-romain.na...@gmail.com/ Best regards, Romain
[Bug libstdc++/98731] s390x: Large classes of std::bitset and std::vector hash the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98731 Jonathan Wakely changed: What|Removed |Added Target|s390x-linux-gnu |s390x-linux-gnu, ||powerpc-*-*, powerpc64-*-* Keywords||ABI --- Comment #4 from Jonathan Wakely --- (In reply to Matthias Klose from comment #0) > It appears that the hash value is completely dependent on the size of > the object in bytes. It's not *completely* dependent on the size. Only the last x.size()%64 bits are hashed incorrectly. For x.size() < 32 it's completely dependent, because we never look at the right bits. For larger numbers of bits we look at *some* of them. Fixing it is an ABI break though, because it would mean that the same value produces a different hash when compiled with an old GCC or a fixed GCC. Inserting an element into an unordered_map in one TU and then looking it up in another TU could fail.
[Bug inline-asm/98778] asm() accepts certain "i" (symbol) constructs despite -fpie for x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98778 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- I don't think anything guarantees that this should work.
[Bug inline-asm/98778] asm() accepts certain "i" (symbol) constructs despite -fpie for x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98778 --- Comment #2 from Jakub Jelinek --- In particular it is up to the inline asm writer to ensure that the result is PIC compatible through a wise choice of constraints etc.
[Bug target/98348] [10/11 Regression] GCC 10.2 AVX512 Mask regression from GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98348 --- Comment #15 from Jakub Jelinek --- I haven't seen the patch posted to gcc-patches, have I missed it? Patch review should happen there.
[Bug c++/98295] [8/9/10/11 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:4312
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98295 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Perhaps related to PR98463 ?
[Bug tree-optimization/98255] [10/11 Regression] wrong code at -Os and above with -fPIC on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98255 --- Comment #2 from Jakub Jelinek --- Martin, can you please have a look? Thanks.
[Bug ipa/98690] [10/11 Regression] unexpected "'removed_return.213' may be used uninitialized in this function" causes crash since r10-3311-gff6686d2e5f797d6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98690 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Assuming fixed.
[Bug tree-optimization/97960] [8/9/10/11 Regression] Wrong code at -O3 since r8-6511-g3ae129323d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97960 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Richard, did you have time to look into this yet?
[Bug c++/97627] [9/10/11 Regression] loop end condition missing - endless loop with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97627 --- Comment #8 from Jakub Jelinek --- Still broken on current 10 branch, as written works fine on the trunk due to the C++ FE loop changes. Bin, did you have time to look into this yet?
[Bug c++/97627] [9/10/11 Regression] loop end condition missing - endless loop with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97627 --- Comment #9 from bin cheng --- (In reply to Jakub Jelinek from comment #8) > Still broken on current 10 branch, as written works fine on the trunk due to > the C++ FE loop changes. > Bin, did you have time to look into this yet? I am very sorry, seems I have two correctness PRs now? Will try to investigate these on this WE.
[Bug inline-asm/98778] asm() accepts certain "i" (symbol) constructs despite -fpie for x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98778 --- Comment #3 from jbeulich at suse dot com --- (In reply to Jakub Jelinek from comment #2) > In particular it is up to the inline asm writer to ensure that the result is > PIC compatible through a wise choice of constraints etc. Perhaps the description wasn't clear enough (but I think the title disambiguates it): I don't mean this to be made work. I'd expect an error on all three constructs, like with -fpic, rather than just on one of them.
[Bug tree-optimization/98255] [10/11 Regression] wrong code at -Os and above with -fPIC on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98255 --- Comment #3 from Martin Jambor --- So SRA sees statements: n[0][2] = "\t\x02\b"; and later _11 = n[0][3][4294967294]; The latter loads a scalar sitting inside what the store above initialized (according to get_ref_base_and_extent) and so SRA creates a single char replacement for it which is initialized with: n$0$3$4294967294_24 = "\t\x02\b"[4294967294]; the RHS being: unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x774e63f0 precision:8 min max pointer_to_this > arg:0 sizes-gimplified BLK size unit-size align:8 warn_if_not_align:0 symtab:0 alias-set 0 canonical-type 0x77601498 domain > constant "\011\002\010"> arg:1 constant 4294967294> pr98255.c:20:21 start: pr98255.c:20:14 finish: pr98255.c:20:23> At expansion time, that the 4294967294 index is not however sign-expanded and so the program ends up loading from a bad memory address. Is "\t\x02\b"[4294967294] something the expander should sign-extend or should SRA avoid re-using array_refs with indices which change when sign-extended to a pointer width integer?
[Bug target/98618] aarch64: oob adrp offset causes relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98618 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Wilco Dijkstra : https://gcc.gnu.org/g:1e18f4bbd8318db1e606f7092a224e4bb21a8a26 commit r9-9193-g1e18f4bbd8318db1e606f7092a224e4bb21a8a26 Author: Wilco Dijkstra Date: Wed Oct 16 14:24:41 2019 + [AArch64] Fix symbol offset limit (PR 98618) In aarch64_classify_symbol symbols are allowed large offsets on relocations. This means the offset can use all of the +/-4GB offset, leaving no offset available for the symbol itself. This results in relocation overflow and link-time errors for simple expressions like &global_array + 0xff00. To avoid this, unless the offset_within_block_p is true, limit the offset to +/-1MB so that the symbol needs to be within a 3.9GB offset from its references. For the tiny code model use a 64KB offset, allowing most of the 1MB range for code/data between the symbol and its references. gcc/ PR target/98618 * config/aarch64/aarch64.c (aarch64_classify_symbol): Apply reasonable limit to symbol offsets. gcc/testsuite/ PR target/98618 * gcc.target/aarch64/symbol-range.c: Improve testcase. * gcc.target/aarch64/symbol-range-tiny.c: Likewise. (cherry picked from commit 7d3b27ff12610fde9d6c4b56abc70c6ee9b6b3db)
[Bug tree-optimization/98255] [10/11 Regression] wrong code at -Os and above with -fPIC on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98255 --- Comment #4 from Jakub Jelinek --- The return n[0][3][-2U]; access is UB in the program, so if it would be reached, it can do anything, but the important thing is that it is guarded with while (g) where g is always 0 during the exection of the program. The sra bug is that it hoists the n[0][3][-2U] read from where it was in the IL to the start of the function. That is perhaps fine for memory reads that can't trap (are within the bounds of the object), though even for those it might not be beneficial from optimization POV (higher register pressure), but for memory references for which tree_could_trap_p is true as in this case, they shouldn't be hoisted in the IL before their guarding condition.
[Bug c++/98530] [11 Regression] g++.dg/modules/string-1_b.C etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98530 --- Comment #4 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:3c1cf7350bff6ba03faaa61b44d74bf8a06c6543 commit r11-6834-g3c1cf7350bff6ba03faaa61b44d74bf8a06c6543 Author: Nathan Sidwell Date: Thu Jan 21 04:48:39 2021 -0800 c++: Stat-hack for members [PR 98530] This was a header file that deployed the stat-hack inside a class (both a member-class and a [non-static data] member had the same name). Due to the way that's represented in name lookup we missed the class. Sadly just changing the representation globally has detrimental effects elsewhere, and this is a rare case, so just creating a new overload on the fly shouldn't be a problem. PR c++/98530 gcc/cp/ * name-lookup.c (lookup_class_binding): Rearrange a stat-hack. gcc/testsuite/ * g++.dg/modules/stat-mem-1.h: New. * g++.dg/modules/stat-mem-1_a.H: New. * g++.dg/modules/stat-mem-1_b.C: New.
[Bug c++/98530] [11 Regression] g++.dg/modules/string-1_b.C etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98530 Nathan Sidwell changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Nathan Sidwell --- 3c1cf7350bf 2021-01-21 | c++: Stat-hack for members [PR 98530]
[Bug libgomp/98738] task-detach-6.f90 hangs intermittently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98738 --- Comment #9 from Kwok Yeung --- I have a patch for this now. In addition to posting other semaphores in omp_fulfill_event, GOMP_taskwait also needs to be made aware of detached tasks. Also, task_running_count should not include completed tasks that are waiting for event completion, since these are not really still running, and may lead to a failure to wake up the barrier thread when required.
[Bug c++/98624] UBSAN: gcc/cp/module.cc:5895:29: runtime error: member call on null pointer of type 'struct module_state'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98624 Nathan Sidwell changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #3 from Nathan Sidwell --- I flubbed testing
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 98624, which changed state. Bug 98624 Summary: UBSAN: gcc/cp/module.cc:5895:29: runtime error: member call on null pointer of type 'struct module_state' https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98624 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug libgomp/98738] task-detach-6.f90 hangs intermittently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98738 --- Comment #10 from Jakub Jelinek --- I've been wondering whether it wouldn't be best to pass through omp_eventhandle_t the pointer to the gomp_task rather than some particular semaphore and in omp_fulfill_event then decide based on that task, one case would be if it is the included task, then it should post a semaphore and be done with it, otherwise (not included task), it should find the corresponding team (which might not be necessary the omp_fulfill_event's task), lock the task_lock and figure out in which of the many cases the task is in, if not yet finished, perhaps just clear detach bool and be done with it, if in the state after that, figure out what is waiting for that task and deal with that. Not sure if a per-task semaphore is what we want in that case, e.g. we could have a taskwait, taskgroup end or barrier waiting for multiple tasks with detach clause and if that is the only thing they might be waiting on, then those should be sleeping on taskwait_sem, taskgroup_sem or on the barrier, so depending on what they are sleeping on that should be awaken.
[Bug tree-optimization/98772] Widening patterns causing missed vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98772 --- Comment #3 from Richard Biener --- But the issue seems to be t.c:3:22: note: ==> examining statement: _34 = *pix1_19; t.c:3:22: missed: permutation requires at least three vectors _34 = *pix1_19; t.c:3:22: missed: unsupported load permutation t.c:6:24: missed: not vectorized: relevant stmt not supported: _34 = *pix1_19; t.c:3:22: note: removing SLP instance operations starting from: *_44 = _45; t.c:3:22: missed: unsupported SLP instances t.c:3:22: note: re-trying with SLP disabled so SLP vectorization failing because of unsupported permutes with the larger vector size and the non-SLP case failing with t.c:3:22: missed: loop does not have enough iterations to support vectorization. t.c:3:22: note: * Analysis failed with vector mode V16QI so I don't see the connection with the pattern. Only for V8QI I see it remotely mentioned, but there we have _different_ pattens matched... I think the permute issue is "old" and goes away if you make it strided-slp by incrementing pix1/2 by a non-constant, then we can load the vector by char[4] pieces. We just don't consider that possibility when instead trying "strided" (with gap at the end). The widen patterns are a red herring here I think.
[Bug target/96372] [11 regression] arm/ivopts.c fails since r11-2012
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96372 --- Comment #3 from CVS Commits --- The master branch has been updated by Andrea Corallo : https://gcc.gnu.org/g:0568f801effcea6f4e066c40bc346513d6b946c5 commit r11-6836-g0568f801effcea6f4e066c40bc346513d6b946c5 Author: Andrea Corallo Date: Fri Jan 15 15:34:19 2021 +0100 arm: [testuiste] Fix ivopts.c target test [PR96372] gcc/ 2021-01-15 Andrea Corallo PR target/96372 * doc/sourcebuild.texi (arm_thumb2_no_arm_v8_1_lob): Document. gcc/testsuite/ 2021-01-15 Andrea Corallo PR target/96372 * lib/target-supports.exp (check_effective_target_arm_thumb2_no_arm_v8_1_lob): Define proc. * gcc.target/arm/ivopts.c: Use target 'arm_thumb2_no_arm_v8_1_lob'.
[Bug target/98348] [10/11 Regression] GCC 10.2 AVX512 Mask regression from GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98348 --- Comment #16 from Hongtao.liu --- (In reply to Jakub Jelinek from comment #15) > I haven't seen the patch posted to gcc-patches, have I missed it? > Patch review should happen there. https://gcc.gnu.org/pipermail/gcc-patches/2021-January/562903.html
[Bug ada/98773] [11 regression] Bootstrap failure: "Trmsgggg" conflicts with declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98773 Rainer Orth changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #2 from Rainer Orth --- I misspoke initially: the failure happens in stage 3. I've now run a reghunt and found this patch as the culprit: commit 261cdd23195bc921737fd7a44e34a93ccc44 Author: Richard Biener Date: Wed Jan 20 11:28:30 2021 +0100 Handle overflow in dependence analysis lambda ops gracefully
[Bug tree-optimization/98255] [10/11 Regression] wrong code at -Os and above with -fPIC on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98255 --- Comment #5 from Martin Jambor --- Right, the issue is that SRA depends on get_ref_base_and_extent to figure out what is being accessed (and so whether it is safe) and that function believes the load is safely from within the array.
[Bug sanitizer/95693] [8/9/10/11 Regression] Incorrect error from undefined behavior sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95693 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 50019 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50019&action=edit gcc11-pr95693.patch This untested patch reverts Alex' build_zero_init* change and instead does it in the caller where we know it is only for error recovery (we've emitted an error earlier about it).
[Bug tree-optimization/98255] [10/11 Regression] wrong code at -Os and above with -fPIC on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98255 --- Comment #6 from Jakub Jelinek --- get_ref_base_and_extent is not the right API to check for the UBs caused by out of bounds accesses, tree_could_trap_p is.
[Bug tree-optimization/98255] [10/11 Regression] wrong code at -Os and above with -fPIC on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98255
--- Comment #7 from Martin Jambor ---
Even our constant folding thinks the unsigned expression wraps around. If I
tell SRA to fold the expression if the base is a string_cst, the invalid
dereference is avoided. My experiment was (I am not proposing this, but it
illustrates the point):
diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
index d177f1ba11c..d33c0ab63f7 100644
--- a/gcc/tree-sra.c
+++ b/gcc/tree-sra.c
@@ -99,6 +99,7 @@ along with GCC; see the file COPYING3. If not see
#include "dbgcnt.h"
#include "builtins.h"
#include "tree-sra.h"
+#include "gimple-fold.h"
/* Enumeration of all aggregate reductions we can do. */
@@ -1696,6 +1697,14 @@ build_ref_for_model (location_t loc, tree base,
HOST_WIDE_INT offset,
else
{
tree res;
+ if (TREE_CODE (base) == STRING_CST)
+ {
+ res = build_ref_for_offset (loc, base, offset, model->reverse,
+ model->type, gsi, insert_after);
+ res = fold_const_aggregate_ref (res);
+ return res;
+ }
+
if (model->grp_same_access_path
&& !TREE_THIS_VOLATILE (base)
&& (TYPE_ADDR_SPACE (TREE_TYPE (base))
[Bug tree-optimization/98255] [10/11 Regression] wrong code at -Os and above with -fPIC on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98255 --- Comment #8 from Jakub Jelinek --- 503 poly_offset_int woffset 504 = wi::sext (wi::to_poly_offset (index) 505 - wi::to_poly_offset (low_bound), 506 TYPE_PRECISION (TREE_TYPE (index))); in get_ref_base_and_extent indeed looks incorrect to me, for precisions smaller than precision of pointer (or is that sizetype) I think we need to sign or zero extend based on whether index has signed or unsigned type. For arrays with zero low_bound I think what get_inner_reference does is right, in particular: offset = size_binop (PLUS_EXPR, offset, size_binop (MULT_EXPR, fold_convert (sizetype, index), unit_size)); For non-zero low_bound, it does: if (! integer_zerop (low_bound)) index = fold_build2 (MINUS_EXPR, TREE_TYPE (index), index, low_bound); before that and I'm surprised that it assumes index and low_bound will be compatible types. But perhaps they are in the languages that do support non-zero low bounds.
[Bug tree-optimization/98255] [10/11 Regression] wrong code at -Os and above with -fPIC on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98255 --- Comment #9 from Richard Biener --- (In reply to Jakub Jelinek from comment #8) > 503 poly_offset_int woffset > 504 = wi::sext (wi::to_poly_offset (index) > 505 - wi::to_poly_offset (low_bound), > 506 TYPE_PRECISION (TREE_TYPE (index))); > in get_ref_base_and_extent indeed looks incorrect to me, for precisions > smaller than precision of pointer (or is that sizetype) I think we need to > sign or zero extend based on whether index has signed or unsigned type. > For arrays with zero low_bound I think what get_inner_reference does is > right, in particular: > offset = size_binop (PLUS_EXPR, offset, > size_binop (MULT_EXPR, > fold_convert (sizetype, index), > unit_size)); > For non-zero low_bound, it does: > if (! integer_zerop (low_bound)) > index = fold_build2 (MINUS_EXPR, TREE_TYPE (index), >index, low_bound); > before that and I'm surprised that it assumes index and low_bound will be > compatible types. But perhaps they are in the languages that do support > non-zero low bounds. Note all the above "mess" is due to FEs behaving oddly, notably different from just interpreting the index as-is (appropriately sign or zero-extending it to sizetype for the sizetype offset compute). The odd sign-extension is from gb48e22b2bd02
[Bug tree-optimization/98255] [10/11 Regression] wrong code at -Os and above with -fPIC on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98255 --- Comment #10 from Martin Jambor --- OK, adding an additional check whether tree_could_trap_p is of course easy. I'll wait a little while if the discussion about get_ref_base_and_extent perhaps leads to a different solution but if not, I will prepare a patch. Also, please disregard my comment #7, even though it shows that SRA can do better by folding away the reference (and that works), it only shows that fold_const_aggregate_ref can deal with simple MEM_REFs with sane offsets, not arrays into strings with negative index.
[Bug tree-optimization/98255] [10/11 Regression] wrong code at -Os and above with -fPIC on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98255 --- Comment #11 from Richard Biener --- (In reply to Richard Biener from comment #9) > (In reply to Jakub Jelinek from comment #8) > > 503 poly_offset_int woffset > > 504 = wi::sext (wi::to_poly_offset (index) > > 505 - wi::to_poly_offset (low_bound), > > 506 TYPE_PRECISION (TREE_TYPE (index))); > > in get_ref_base_and_extent indeed looks incorrect to me, for precisions > > smaller than precision of pointer (or is that sizetype) I think we need to > > sign or zero extend based on whether index has signed or unsigned type. > > For arrays with zero low_bound I think what get_inner_reference does is > > right, in particular: > > offset = size_binop (PLUS_EXPR, offset, > > size_binop (MULT_EXPR, > > fold_convert (sizetype, index), > > unit_size)); > > For non-zero low_bound, it does: > > if (! integer_zerop (low_bound)) > > index = fold_build2 (MINUS_EXPR, TREE_TYPE (index), > >index, low_bound); > > before that and I'm surprised that it assumes index and low_bound will be > > compatible types. But perhaps they are in the languages that do support > > non-zero low bounds. > > Note all the above "mess" is due to FEs behaving oddly, notably different > from just interpreting the index as-is (appropriately sign or zero-extending > it to sizetype for the sizetype offset compute). The odd sign-extension > is from gb48e22b2bd02 Possibly wi::sext(..., TYPE_PRECISION (sizetype)) is what we want.
[Bug rtl-optimization/98782] New: IRA artificially creating spills due to BB frequencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
Bug ID: 98782
Summary: IRA artificially creating spills due to BB frequencies
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ra
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
CC: jgreenhalgh at gcc dot gnu.org, vmakarov at gcc dot gnu.org
Target Milestone: ---
Created attachment 50020
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50020&action=edit
dumps and source
Hi,
James and I have been investigating the exchange2 regression that has been
haunting Trunk
since:
commit 1118a3ff9d3ad6a64bba25dc01e7703325e23d92
Author: Jan Hubicka
Date: Tue Aug 11 12:02:32 2020 +0200
Do not combine PRED_LOOP_GUARD and PRED_LOOP_GUARD_WITH_RECURSION
That patch fixed the prediction frequency for the basic blocks in some
of the recursively specialized functions in exchange2. Unfortunately, it
also created a large (12+%) performance regression on multiple targets
(including x86).
After initially blaming the new prediction frequencies, and significant work
from Jan and Martin we have good confidence in the probabilities, however they
appear to be exposing issues with the probability-based cost models in IRA
causing additional spills after artificially limiting register pressure by
excluding caller-saved registers across a call site in the loop.
This testcase (tuned) for AArch64 shows the issue:
void bar (int, int, int, int);
int foo (int x, char* foo) {
int tmp = x * 753;
int t2 = tmp + 7;
int t3 = tmp * 7;
int c1 = 753;
int c2 = c1 + 7;
int c3 = c3 * 7;
for (int i = 0; i < 1024; i++) {
if (__builtin_expect_with_probability (foo[i] != 0, 1, SPILLER))
bar(x, tmp, t2, t3);
c1 += foo[i+1];
c2 *= foo[i+1];
c3 += c2;
}
return c1 + c2 + c3;
}
You can see the difference in the basic block labeled with L2 (using ffixed
to provoke register pressure):
Good compile:
gcc -DSPILLER=0.5 -fno-shrink-wrap -fno-schedule-insns -O3 -ffixed-x23
-ffixed-x24 -ffixed-x25 -ffixed-x26 -ffixed-x27 -ffixed-x28 -fno-reorder-blocks
.L2:
ldrbw0, [x19, 1]!
add w22, w22, w0
mul w20, w20, w0
add w21, w21, w20
cmp x7, x19
bne .L5
Bad compile:
gcc -DSPILLER=0.51 -fno-shrink-wrap -fno-schedule-insns -O3 -ffixed-x23
-ffixed-x24 -ffixed-x25 -ffixed-x26 -ffixed-x27 -ffixed-x28 -fno-reorder-blocks
.L2:
ldrbw0, [x19, 1]!
add w21, w21, w0
mul w20, w20, w0
ldr x0, [sp, 64] << Reload of x0
add w22, w22, w20
cmp x0, x19
bne .L5
Neither of us are an expert in this area by any means, I think what we're
seeing can
be explained by this line in the IRA dump:
Good:
Allocno a5r104 of GENERAL_REGS(24) has 17 avail. regs 4-15 18-22, node:
4-15 18-22 (confl regs = 0-3 16-17 23-85)
Bad:
Allocno a5r104 of GENERAL_REGS(24) has 4 avail. regs 19-22, node: 19-22
(confl regs = 0-3 16-17 23-85)
In the bad case it looks like all the available registers go down, but these
particular ones have so few left over that it causes the spill to occur.
The change in available registers comes from this code in
setup_profitable_hardregs:
if (ALLOCNO_UPDATED_MEMORY_COST (a) < costs[j]
/* Do not remove HARD_REGNO for static chain pointer
pseudo when non-local goto is used. */
&& ! non_spilled_static_chain_regno_p (ALLOCNO_REGNO (a)))
CLEAR_HARD_REG_BIT (data->profitable_hard_regs,
hard_regno);
Both sides of the ALLOCNO_UPDATED_MEMORY_COST (a) < costs[j] calculation
make use of frequency, but there is some asymmetry.
In the case of the bigger exchange2 regression if just revert
1118a3ff9d3ad6a64bba25dc01e7703325e23d92 which affects the BB frequencies we
get a slightly higher score than in GCC 10, indicating that the changes in IPA
are indeed sound.
It also gives us a comparison where the entire sequence up to reload is exactly
the same, aside from the counts in the BB and the frequencies.
Good BB:
;; succ: 66 [always] count:53687092 (estimated locally) (FALLTHRU)
;; lr out 29 [x29] 31 [sp] 64 [sfp] 65 [ap] 1438
;; live out 29 [x29] 31 [sp] 64 [sfp] 65 [ap] 1438
;; basic block 66, loop depth 0, count 107374184 (estimated locally), maybe hot
;; prev block 65, next block 67, flags: (REACHABLE, RTL, MODIFIED)
;; pred: 64 [50.0% (guessed)] count:53687092 (estimated locally)
;; 65 [always] count:53687092 (estimated locally) (FALLTHRU)
Bad BB:
;; succ: 66 [always] count:3487081 (estimated locally)
[Bug rtl-optimization/98782] IRA artificially creating spills due to BB frequencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782 James Greenhalgh changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-01-21 Ever confirmed|0 |1
[Bug target/98697] shl not vectorized for v16qi and v8hi with MVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98697 --- Comment #2 from Christophe Lyon --- Why would this be different from right shift, where we don't miss the optimization?
[Bug tree-optimization/98255] [10/11 Regression] wrong code at -Os and above with -fPIC on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98255 Jakub Jelinek changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #12 from Jakub Jelinek --- Yeah, exactly that change I had in mind too. The question is what it will mean to Ada. In any case, from the get_inner_reference code I assume that either low_bound is zero and then index can have any type which is then cast to sizetype before using further, or low_bound is variable or non-zero constant and in that case the FE needs to ensure the indexes have type compatible with the type of the low bound.
[Bug driver/98783] New: Wrong ouput of "-O3 -Q --help=optimizers" on gcc built with --enable-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98783
Bug ID: 98783
Summary: Wrong ouput of "-O3 -Q --help=optimizers" on gcc
built with --enable-frame-pointer
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: hasse.christoph at cern dot ch
Target Milestone: ---
Dear all,
I've got a GCC build that was configured with "--enable-frame-pointer"
./bin/gcc -v:
Using built-in specs.
COLLECT_GCC=./bin/gcc
COLLECT_LTO_WRAPPER=***/gccinstall/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-10.2.0/configure --enable-frame-pointer
--disable-multilib --prefix=***/gccinstall -with-system-zlib
--enable-languages=all
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC)
Yet doing:
./bin/gcc -O3 -Q --help=optimizers | grep omit
prints:
-fomit-frame-pointer[enabled]
I originally tried "--enable-frame-pointer" on gcc 9.3.0, there I noticed that
the above command yields "enabled" for -m64 and "disabled" for -m32.
The fact that the frame-pointer was disabled on 64bit was a bug that was
reported & fixed. (Bug #89221).
I'm mentioning this because in gcc 9.3.0 the command "-O3 -Q --help=optimizers"
at least reported what was enabled and disabled. So I would assume it should do
the same in gcc 10.2.0.
Yet on 10.2.0 this returns "enabled" for both 32 and 64 bit.
However, I think this is only a bug in the printing, because
echo "int main(){}" | ./bin/gcc -O3 -Q -v -x c - 2>&1 | grep omit
correctly prints nothing thus tells us that the "-fomit-frame-pointer" flag is
in fact not in the set of used optimization options which are printed in this
output.
I've done a bit of digging and saw that there was quite a bit of change between
9.3.0 and 10.2.0 in this area.
>From what I can tell right now the "fomit-frame-pointer" flag is set to
disabled in the function ix86_recompute_optlev_based_flags defined in
gcc/config/i386/i386-options.c:1638
I checked and can see that this function is not called when doing "gcc -O3 -Q
--help=optimizers" but it is when doing the test via "echo "int main(){}" |
./bin/gcc -O3 -Q -v -x c - 2>&1"
{more detail:
seems that the target specific override function is called inside
process_options() in gcc/toplev.c:1389
process_options() is called via do_compile() from within toplev::main.
While both of the above commands enter toplev::main, --help triggers an early
exit, thus not calling do_compile and the eventual override.
}
So that's kind of where I lost track as I'm lacking the bigger picture view of
the codebase to figure out if or with what modification one can best make "gcc
-O3 -Q --help=optimizers" work.
[Bug testsuite/98325] [11 regression] gcc.dg/pr25376.c fails after r11-5027
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98325 seurer at gcc dot gnu.org changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED Last reconfirmed||2021-01-21 Ever confirmed|0 |1 --- Comment #2 from seurer at gcc dot gnu.org --- It is still failing on powerpc64 BE but indeed works on LE. Test run on a power 8 BE machine: Tried g:43705f3fa343e08b2fb030460fc5e2a969954398, r11-6839 make -k check-gcc RUNTESTFLAGS="dg.exp=gcc.dg/pr25376.c" FAIL: gcc.dg/pr25376.c scan-assembler-symbol-section symbol simple$ (found .L.simple) has section ^\\.?my_named_section|simple\\[DS\\]|^\\"\\.opd\\" (found .opd) FAIL: gcc.dg/pr25376.c scan-assembler-symbol-section symbol simple$ (found simple) has section ^\\.?my_named_section|simple\\[DS\\]|^\\"\\.opd\\" (found .opd) # of expected passes2 # of unexpected failures2
[Bug target/98730] vceqzq_p64 does not generate vceq with immediate 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98730 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #2 from rsandifo at gcc dot gnu.org --- (In reply to Christophe Lyon from comment #1) > Why does it choose alternative 0 instead of 1 which matches a vector of > constant zeros? I wonder if it's an rtx costing problem. What do the patterns look like in .expand? If the operands are still registers there, what does .fwprop say? It should be able to replace the registers with zero if the target says that that's worthwhile.
[Bug ipa/93385] [10/11 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385 --- Comment #39 from Jakub Jelinek --- What happened to that patch series? Has it been committed without showing it up in the PR, something else?
[Bug other/98689] [11 Regression] FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O1 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98689 John David Anglin changed: What|Removed |Added Summary|FAIL: |[11 Regression] FAIL: |gcc.dg/torture/stackalign/b |gcc.dg/torture/stackalign/b |uiltin-return-1.c -O1 |uiltin-return-1.c -O1 |execution test |execution test --- Comment #1 from John David Anglin --- Revision c4a6b2dadcd:b9a7bc9531b:b5f24739632389d50903bfde6d1bfc06d522c56b was okay.
[Bug tree-optimization/98772] Widening patterns causing missed vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98772 rsandifo at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-01-21 CC||rsandifo at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #4 from rsandifo at gcc dot gnu.org --- To try to summarise a conversation we had on IRC: As things stand, codes like WIDEN_MULT_EXPR are intended to be code-generated as a hi/lo pair, with both the hi and lo operation being vector(N*2) → vector(N) operations. This works for BB SLP if the SLP group size is ≥ N*2, but (as things stand) is bound to fail otherwise. On targets that operate on only a single vector size, a hard failure is not a problem for group sizes < N*2, since we would have failed in the same place even if we hadn't matched a WIDEN_MULT_EXPR. But it hurts on aarch64 because we could vectorise the multiplication and conversions using mixed vector sizes. I think the conclusion was that: (1) We should define vector(N) → vector(N) optabs for each current widening operation. E.g. in the testcase aarch64 would provide v8qi → v8hi widening operations. (2) We should add directly-mapped internal functions for the new optabs. (3) We should make the modifier==NONE paths in vectorizable_conversion use the new internal functions for WIDEN_*_EXPRs.
[Bug target/98730] vceqzq_p64 does not generate vceq with immediate 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98730
--- Comment #3 from Christophe Lyon ---
At expand time, we have:
(insn 13 12 14 2 (set (reg:V2SI 121 [ _11 ])
(neg:V2SI (eq:V2SI (subreg:V2SI (reg:DI 116 [ _6 ]) 0)
(subreg:V2SI (reg:DI 118 [ _8 ]) 0 "arm_neon.h":2404:22
1649 {neon_vceqv2si_insn}
(nil))
(insn 17 16 18 2 (set (reg:V2SI 128 [ _18 ])
(neg:V2SI (eq:V2SI (subreg:V2SI (reg:DI 124 [ _14 ]) 0)
(subreg:V2SI (reg:DI 125 [ _15 ]) 0 "arm_neon.h":2404:22
1649 {neon_vceqv2si_insn}
(nil))
in fwprop1:
starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called
df_worklist_dataflow_doublequeue: n_basic_blocks 3 n_edges 2 count 3 (1)
df_worklist_dataflow_doublequeue: n_basic_blocks 3 n_edges 2 count 3 (1)
change not profitable (cost 0 -> cost 4)
rescanning insn with uid = 12.
verify found no changes in insn with uid = 12.
rescanning insn with uid = 13.
verify found no changes in insn with uid = 13.
rescanning insn with uid = 16.
verify found no changes in insn with uid = 16.
rescanning insn with uid = 17.
verify found no changes in insn with uid = 17.
change not profitable (cost 0 -> cost 12)
change not profitable (cost 0 -> cost 4)
rescanning insn with uid = 13.
verify found no changes in insn with uid = 13.
change not profitable (cost 0 -> cost 4)
change not profitable (cost 80 -> cost 84)
change not profitable (cost 80 -> cost 84)
change not profitable (cost 80 -> cost 84)
rescanning insn with uid = 17.
verify found no changes in insn with uid = 17.
change not profitable (cost 80 -> cost 84)
change not profitable (cost 80 -> cost 84)
and insns 13 and 17 are:
(insn 13 8 14 2 (set (reg:V2SI 121 [ _11 ])
(neg:V2SI (eq:V2SI (subreg:V2SI (reg:V2DI 113 [ v2.0_1 ]) 8)
(subreg:V2SI (reg:V4SI 114 [ _4 ]) 8 "arm_neon.h":2404:22
1649 {neon_vceqv2si_insn}
(expr_list:REG_EQUAL (neg:V2SI (eq:V2SI (subreg:V2SI (reg:V2DI 113 [
v2.0_1 ]) 8)
(const_vector:V2SI [
(const_int 0 [0]) repeated x2
])))
(nil)))
(insn 17 14 18 2 (set (reg:V2SI 128 [ _18 ])
(neg:V2SI (eq:V2SI (subreg:V2SI (reg:V2DI 113 [ v2.0_1 ]) 0)
(subreg:V2SI (reg:V4SI 114 [ _4 ]) 8 "arm_neon.h":2404:22
-1
(expr_list:REG_EQUAL (neg:V2SI (eq:V2SI (subreg:V2SI (reg:V2DI 113 [
v2.0_1 ]) 0)
(const_vector:V2SI [
(const_int 0 [0]) repeated x2
])))
(nil)))
[Bug tree-optimization/98255] [10/11 Regression] wrong code at -Os and above with -fPIC on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98255 --- Comment #13 from Jakub Jelinek --- Created attachment 50021 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50021&action=edit gcc11-pr98255.patch The full patch would be I think this. Am going to bootstrap/regtest it just to see what it breaks or fixes.
[Bug target/92095] [8/9/10 regression] internal error with -O1 -mcpu=niagara2 -fPIE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92095 --- Comment #10 from Eric Botcazou --- > This patch produce a regression on sparcv8 SS10 platform. > > In Buildroot we have a defconfig qemu_sparc_ss10_defconfig that was working > (booting) with gcc 7.4, 8.3 and 9.2. But it doesn't boot anymore with gcc > 8.4, 9.3 and 10.2. > > I reverted this patch to be able to boot the system. > > See: > http://patchwork.ozlabs.org/project/buildroot/patch/20210120230234.2086807-1- > romain.na...@gmail.com/ Unfortunately there is not enough information to investigate here. Please consider creating a new PR as explained on https://gcc.gnu.org/bugs
[Bug c++/98672] constexpr function - for loop with return statement doesn't get recognized as constexpr subexpression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98672 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:0fb7aa205afebe178c06683037ccd4c41104337a commit r11-6840-g0fb7aa205afebe178c06683037ccd4c41104337a Author: Jakub Jelinek Date: Thu Jan 21 17:20:24 2021 +0100 c++: Fix up potential_constant_expression_1 FOR/WHILE_STMT handling [PR98672] The following testcase is rejected even when it is valid. The problem is that potential_constant_expression_1 doesn't have the accurate *jump_target tracking cxx_eval_* has, and when the loop has a condition that isn't guaranteed to be always true, the body isn't walked at all. That is mostly a correct conservative behavior, except that it doesn't detect if there are any return statements in the body, which means the loop might return instead of falling through to the next statement. We already have code for return stmt discovery in code snippets we don't try to evaluate for switches, so this patch reuses that for FOR_STMT and WHILE_STMT bodies. Note, I haven't touched FOR_EXPR, with statement expressions it could have return stmts in it too, or it could have break or continue statements that wouldn't bind to the current loop but to something outer. That case is clearly mishandled by potential_constant_expression_1 even when the condition is missing or is always true, and it wouldn't surprise me if cxx_eval_* didn't handle it right either, so I'm deferring that to separate PR for later. We'd need proper test coverage for all of that. > Hmm, IF_STMT probably also needs to check the else clause, if the condition > isn't a known constant. You're right, I thought it was ok because it recurses with tf_none, but if the then branch is potentially constant and only else returns, continues or breaks, then as the enhanced testcase shows we were mishandling it too. 2021-01-21 Jakub Jelinek PR c++/98672 * constexpr.c (check_for_return_continue_data): Add break_stmt member. (check_for_return_continue): Also look for BREAK_STMT. Handle SWITCH_STMT by ignoring break_stmt from its body. (potential_constant_expression_1) , : If the condition isn't constant true, check if the loop body can contain a return stmt. : Adjust check_for_return_continue_data initializer. : If recursion with tf_none is successful, merge *jump_target from the branches - returns with highest priority, breaks or continues lower. If then branch is potentially constant and doesn't return, check the else branch if it could return, break or continue. * g++.dg/cpp1y/constexpr-98672.C: New test.
[Bug c++/98672] constexpr function - for loop with return statement doesn't get recognized as constexpr subexpression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98672 --- Comment #3 from Jakub Jelinek --- Fixed on the trunk. I think we need to backport this at least to 10.3 eventually.
[Bug target/97981] [11 regression] 32-bit x86 'gcc.dg/atomic/c11-atomic-exec-1.c' execution test since r11-5188-g32934a4f45a72144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97981 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Assuming fixed. Haven't seen the FAILs since Dec 8th.
[Bug c++/98531] [11 Regression] g++.dg/modules/xtreme-header-2_a.H etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98531 --- Comment #5 from Nathan Sidwell --- Created attachment 50022 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50022&action=edit reduced testcase, this is not solaris-specific, but solaris happened to tickle it uniquely
[Bug c++/97597] [11 Regression] ICE in build_over_call, at cp/call.c:9034
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97597 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jason Merrill --- Fixed.
[Bug target/98730] vceqzq_p64 does not generate vceq with immediate 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98730 --- Comment #4 from rsandifo at gcc dot gnu.org --- Hmm, yeah, looks like it might be a cost issue then. arm_rtx_costs_internal seems to give CONST_VECTOR a cost of 1 or 4 instructions, whereas a zero CONST_VECTOR is free in this context. Although that should be fixed, another approach would be to lower vget_high_* and vget_low_* at the gimple level if the argument is a constant.
[Bug target/98618] aarch64: oob adrp offset causes relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98618 --- Comment #7 from CVS Commits --- The releases/gcc-8 branch has been updated by Wilco Dijkstra : https://gcc.gnu.org/g:c9569046bd8ba2671833d600b3bdbdb7de593873 commit r8-10736-gc9569046bd8ba2671833d600b3bdbdb7de593873 Author: Wilco Dijkstra Date: Wed Oct 16 14:24:41 2019 + [AArch64] Fix symbol offset limit (PR 98618) In aarch64_classify_symbol symbols are allowed large offsets on relocations. This means the offset can use all of the +/-4GB offset, leaving no offset available for the symbol itself. This results in relocation overflow and link-time errors for simple expressions like &global_array + 0xff00. To avoid this, unless the offset_within_block_p is true, limit the offset to +/-1MB so that the symbol needs to be within a 3.9GB offset from its references. For the tiny code model use a 64KB offset, allowing most of the 1MB range for code/data between the symbol and its references. gcc/ PR target/98618 * config/aarch64/aarch64.c (aarch64_classify_symbol): Apply reasonable limit to symbol offsets. gcc/testsuite/ PR target/98618 * gcc.target/aarch64/symbol-range.c: Improve testcase. * gcc.target/aarch64/symbol-range-tiny.c: Likewise. (cherry picked from commit 7d3b27ff12610fde9d6c4b56abc70c6ee9b6b3db)
[Bug target/98618] aarch64: oob adrp offset causes relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98618 Wilco changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.5 --- Comment #8 from Wilco --- Backported to GCC8 and GCC9, so fixed on all active branches.
[Bug c++/97742] [10/11 Regression] endless loop with code reduced by creduce/cvise
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97742
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #3 from Marek Polacek ---
Slightly more realistic test:
template
struct X { };
[Bug fortran/98573] Dynamic type lost on assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98573 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #5 from Paul Thomas --- Created attachment 50023 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50023&action=edit Fix for all three tests I believe that attached does the job although I don't quite see as many failing cases as you. It regtests too :-) I will investigate a bit further before I submit. Thanks for the report. Paul
[Bug c++/98624] UBSAN: gcc/cp/module.cc:5895:29: runtime error: member call on null pointer of type 'struct module_state'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98624 --- Comment #4 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:7944753fad501194eb8a828d6b74270e79d14a4d commit r11-6841-g7944753fad501194eb8a828d6b74270e79d14a4d Author: Nathan Sidwell Date: Thu Jan 21 10:37:23 2021 -0800 c++: Fix null this pointer [PR 98624] One may not use a null this pointer to invoke a static member function. This fixes the remaining ubsan errors found with an ubsan bootstrap. PR c++/98624 gcc/cp/ * module.cc (depset::hash::find_dependencies): Add module arg. (trees_out::core_vals): Check state before calling write_location. (sort_cluster, module_state::write): Adjust find_dependencies call.
[Bug c++/98624] UBSAN: gcc/cp/module.cc:5895:29: runtime error: member call on null pointer of type 'struct module_state'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98624 Nathan Sidwell changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #5 from Nathan Sidwell --- 7944753fad5 2021-01-21 | c++: Fix null this pointer [PR 98624]
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 98624, which changed state. Bug 98624 Summary: UBSAN: gcc/cp/module.cc:5895:29: runtime error: member call on null pointer of type 'struct module_state' https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98624 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/90248] [8/9/10/11 Regression] larger than 0 compare fails with -ffinite-math-only -funsafe-math-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90248 --- Comment #15 from Jakub Jelinek --- Created attachment 50024 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50024&action=edit gcc11-pr90248.patch So, I think at minimum we want this, i.e. turn the bogus simplifications into simplifications directly into +-abs if the conditions are multiplied by X. That should work fine even for +/-0.0, except that it perhaps could get the sign of zero wrong (which is why I've kept it guarded on !HONOR_SIGNED_ZEROS). Additionally, we can consider (phiopt?) optimization that will optimize the VCE to signed int ? const : -const into copysign.
[Bug fortran/98573] Dynamic type lost on assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98573 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-01-21 Ever confirmed|0 |1
[Bug driver/98783] Wrong ouput of "-O3 -Q --help=optimizers" on gcc built with --enable-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98783 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-01-21 --- Comment #1 from Martin Liška --- Let me take a look.
[Bug c++/71879] Error in unevaluated context breaks SFINAE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71879 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:f645da0e4ab9438dfd0c047c710c7ec6a7d6d8f3 commit r11-6842-gf645da0e4ab9438dfd0c047c710c7ec6a7d6d8f3 Author: Patrick Palka Date: Thu Jan 21 14:04:55 2021 -0500 c++: Fix excessive instantiation inside decltype [PR71879] Here after resolving the address of a template-id inside decltype, we end up instantiating the chosen specialization (from the call to mark_used in resolve_nondeduced_context), even though only its type is needed. This patch sets cp_unevaluated_operand throughout finish_decltype_type, so that in particular it's set during the call to resolve_nondeduced_context within. gcc/cp/ChangeLog: PR c++/71879 * semantics.c (finish_decltype_type): Set up a cp_unevaluated sentinel at the start of the function. Remove a now-redundant manual adjustment of cp_unevaluated_operand. gcc/testsuite/ChangeLog: PR c++/71879 * g++.dg/cpp0x/decltype-71879.C: New test.
[Bug c++/71879] Error in unevaluated context breaks SFINAE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71879 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |11.0 --- Comment #4 from Patrick Palka --- Fixed for GCC 11. Thanks for the bug report!
[Bug c++/96623] [11 Regression] ICE in inject_parm_decls, at cp/parser.c:23893
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96623
--- Comment #4 from Marek Polacek ---
And an extended test to check that various variables are in scope:
constexpr int x = 0;
struct A {
int a1;
void foo (int p) {
int foovar;
struct B {
int b1;
void bar1 () noexcept(x);
void bar2 () noexcept(noexcept(this->b1));
void bar3 () noexcept(noexcept(this->b2));
void bar4 () noexcept(noexcept(a1));
void bar5 () noexcept(noexcept(a2));
void bar6 () noexcept(noexcept(b1));
void bar7 () noexcept(noexcept(b2));
void bar8 () noexcept(noexcept(foovar));
void bar9 () noexcept(noexcept(p));
int b2;
};
}
int a2;
};
[Bug rtl-optimization/98777] [11 Regression] ICE in update_equiv at gcc/lra-constraints.c:504 since r11-6819-g4334b52427420312
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98777 --- Comment #1 from Vladimir Makarov --- Thank you for reporting this. I've reproduced the bug on riscv64 and started to work on fixing it.
[Bug tree-optimization/96963] [10/11 Regression] -Wstringop-overflow false positive on -O3 or -O2 -ftree-vectorize when assigning consecutive char struct members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96963 Martin Sebor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/96863] [9/10/11 Regression] ICE: in output_constructor_regular_field, at varasm.c:5223
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96863 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Marek Polacek --- Looks like a dup of bug 98463 which has more information. *** This bug has been marked as a duplicate of bug 98463 ***
