[Bug target/99718] [11 regression] ICE in new test case gcc.target/powerpc/pr98914.c for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718
--- Comment #19 from luoxhu at gcc dot gnu.org ---
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567395.html
This patch extends variable vec_insert to all 32bit VSX targets including
Power7{BE} {32,64}, Power8{BE}{32, 64}, Power8{LE}{64}, Power9{LE}{64}, all
tested pass for power testcases, though AIX is not tested yet. @Segher, please
review this one instead of the previous that disables 32 bit variable
vec_insert, thanks.
For Altivec targets like power5/6/G4/G5, take the previous "vector store/scalar
store/vector load" code path.
-mcpu=power6 -O2 -maltivec -c -S
f2:
.LFB0:
.cfi_startproc
addi 10,1,-16
sldi 5,5,2
li 9,32
addi 8,1,-48
stvx 2,8,9
stwx 6,10,5
lvx 2,8,9
blr
[Bug fortran/99711] Crash when reading an allocated character array in namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711 --- Comment #17 from Jerry DeLisle --- (In reply to Jerry DeLisle from comment #16) > FWIW it also segfaults on: > > write(unit=6, nml=nam_bu_ru) > > I have been digging around with gdb in trans-io.c and I can see the cl is > 0x0 in the sym->ts.u.cl and I can find nothing else accessible at this > point. I think I am going to have to go back to the "trans" for the allocate > which should have the length resolved and stuff it into the sym. In trans-stmt.c (gfc_trans_allocate (gfc_code * code)) I find: (gdb) p *code->ext->alloc.ts.u.cl.length.value.integer._mp_d $41 = 10 So it is there and there is code to handle it in that function. However, I do not yet understand the inner workings of frontend to see what the problem is.
[Bug tree-optimization/95638] [10 Regression] Legit-looking code doesn't work with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95638 bin cheng changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||10.2.0 Resolution|--- |FIXED --- Comment #15 from bin cheng --- Confirmed fixed for 10.2.0 also. Closing.
[Bug libstdc++/96416] to_address() is broken by static_assert in pointer_traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
--- Comment #13 from Arthur O'Dwyer ---
> And are you recommending that everyone who defines their custom contiguous
> iterators specializes pointer_traits for them? Call it _quite_ annoying...
Definitely not! When you define a contiguous iterator type, you should just
give it a sixth nested typedef alongside the other five (or three in C++20):
`using element_type = value_type;`. This enables contiguous-iterator machinery.
See
https://stackoverflow.com/questions/65712091/in-c20-how-do-i-write-a-contiguous-iterator/66050521#66050521
You should never specialize std::pointer_traits for your own type.
("Can" you? Yes. "Should" you? No.)
[Bug libstdc++/96416] to_address() is broken by static_assert in pointer_traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416 Jonathan Wakely changed: What|Removed |Added Summary|address_of() is broken by |to_address() is broken by |static_assert in|static_assert in |pointer_traits |pointer_traits --- Comment #12 from Jonathan Wakely --- (In reply to Giuseppe D'Angelo from comment #10) > (By the way, finding this bug is quite hard. Could "address_of" be changed > to "to_address" , in the bug description? Done.
[Bug middle-end/60488] missing uninitialized warning (address taken, VOP)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60488
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2016-08-23 00:00:00 |2021-3-26
Known to fail|7.0 |11.0
--- Comment #6 from Martin Sebor ---
Reconfirming with GCC 11.
The problem is that when the address of a variable escapes, because GCC doesn't
track when, when the function from which it escapes calls another that might
access the escaped variable, the warning (as a result of relying on the
conservative assumptions the optimizers must make) assumes the called function
initializes the variable. Another example of this is function h() below.
The irony (and I'd say the bug) here is that the warning uses the same
conservative assumptions to trigger in cases when an equivalent same situation
might lead to the variable not having been initialized such as in g() below.
These conflicting assumptions make the warning seem unpredictable.
$ cat z.c && gcc -O2 -S -Wall z.c
void f (void);
int i, *p;
int g (int j)
{
int x;
if (i) // assume i is zero
x = j + 1;
f ();// assume call sets i
if (i)
return x; // issue -Wmaybe-uninitalized
return i;
}
int h (int j)
{
int x;
p = // address of x escapes
f ();// assume call sets x
return x;// avoid warning here
}
z.c: In function ‘g’:
z.c:14:12: warning: ‘x’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
14 | return x; // issue -Wmaybe-uninitalized
|^
z.c:7:7: note: ‘x’ was declared here
7 | int x;
| ^
[Bug libstdc++/96416] address_of() is broken by static_assert in pointer_traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416 --- Comment #11 from Glen Joseph Fernandes --- > if it can never be used. You're misunderstanding. to_address(p) requires that pointer_traits is valid. It just doesn't need to have a to_address member function. Example 1. You have a pointer-like type Ptr1. You haven't specialized pointer_traits, but pointer_traits is valid. Here it will call to_address(p1.operator->()). Example 2. You have a pointer-like type Ptr2. You have specialized pointer_traits with a to_address function. Here it will call pointer_traits::to_address(p2). to_address() was intended for used with pointers and pointer-like types (and pointer_traits was always required to be valid). It was intended for use with allocator pointers, and the original standard library implementations had a return type of: typename pointer_traits::element_type* If (for contiguous iterators, which came later) you want pointer_traits to be valid even when X does not have element_type, that is a design change to pointer_traits.
[Bug fortran/99711] Crash when reading an allocated character array in namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711 --- Comment #16 from Jerry DeLisle --- FWIW it also segfaults on: write(unit=6, nml=nam_bu_ru) I have been digging around with gdb in trans-io.c and I can see the cl is 0x0 in the sym->ts.u.cl and I can find nothing else accessible at this point. I think I am going to have to go back to the "trans" for the allocate which should have the length resolved and stuff it into the sym.
[Bug preprocessor/60723] Line directives with incorrect system header flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60723 Eric Gallager changed: What|Removed |Added CC||acpy00 at outlook dot com, ||blue at cmd dot nu, ||egallager at gcc dot gnu.org, ||ktkachov at gcc dot gnu.org, ||matt at godbolt dot org, ||nicholas.ormrod at hotmail dot com ||, oliver at bway dot net --- Comment #31 from Eric Gallager --- Redoing some CCs that got silently removed without showing up in the bug history (presumably due to the server migration)
[Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99334 --- Comment #10 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:1cdfc98a9981768c475fabf069ba4d3e460deb2a commit r11-7870-g1cdfc98a9981768c475fabf069ba4d3e460deb2a Author: Jakub Jelinek Date: Sat Mar 27 00:20:42 2021 +0100 dwarf2cfi: Defer queued register saves some more [PR99334] On the testcase in the PR with -fno-tree-sink -O3 -fPIC -fomit-frame-pointer -fno-strict-aliasing -mstackrealign we have prologue: <_func_with_dwarf_issue_>: 0: 4c 8d 54 24 08 lea0x8(%rsp),%r10 5: 48 83 e4 f0 and$0xfff0,%rsp 9: 41 ff 72 f8 pushq -0x8(%r10) d: 55 push %rbp e: 48 89 e5mov%rsp,%rbp 11: 41 57 push %r15 13: 41 56 push %r14 15: 41 55 push %r13 17: 41 54 push %r12 19: 41 52 push %r10 1b: 53 push %rbx 1c: 48 83 ec 20 sub$0x20,%rsp and emit 0014 CIE Version: 1 Augmentation: "zR" Code alignment factor: 1 Data alignment factor: -8 Return address column: 16 Augmentation data: 1b DW_CFA_def_cfa: r7 (rsp) ofs 8 DW_CFA_offset: r16 (rip) at cfa-8 DW_CFA_nop DW_CFA_nop 0018 0044 001c FDE cie= pc=..01d5 DW_CFA_advance_loc: 5 to 0005 DW_CFA_def_cfa: r10 (r10) ofs 0 DW_CFA_advance_loc: 9 to 000e DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0) DW_CFA_advance_loc: 13 to 001b DW_CFA_def_cfa_expression (DW_OP_breg6 (rbp): -40; DW_OP_deref) DW_CFA_expression: r15 (r15) (DW_OP_breg6 (rbp): -8) DW_CFA_expression: r14 (r14) (DW_OP_breg6 (rbp): -16) DW_CFA_expression: r13 (r13) (DW_OP_breg6 (rbp): -24) DW_CFA_expression: r12 (r12) (DW_OP_breg6 (rbp): -32) ... unwind info for that. The problem is when async signal (or stepping through in the debugger) stops after the pushq %rbp instruction and before movq %rsp, %rbp, the unwind info says that caller's %rbp is saved there at *%rbp, but that is not true, caller's %rbp is either still available in the %rbp register, or in *%rsp, only after executing the next instruction - movq %rsp, %rbp - the location for %rbp is correct. So, either we'd need to temporarily say: DW_CFA_advance_loc: 9 to 000e DW_CFA_expression: r6 (rbp) (DW_OP_breg7 (rsp): 0) DW_CFA_advance_loc: 3 to 0011 DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0) DW_CFA_advance_loc: 10 to 001b or to me it seems more compact to just say: DW_CFA_advance_loc: 12 to 0011 DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0) DW_CFA_advance_loc: 10 to 001b I've tried instead to deal with it through REG_FRAME_RELATED_EXPR from the backend, but that failed miserably as explained in the PR, dwarf2cfi.c has some rules (Rule 16 to Rule 19) that are specific to the dynamic stack realignment using drap register that only the i386 backend does right now, and by using REG_FRAME_RELATED_EXPR or REG_CFA* notes we can't emulate those rules. The following patch instead does the deferring of the hard frame pointer save rule in dwarf2cfi.c Rule 18 handling and emits it on the (set hfp sp) assignment that must appear shortly after it and adds assertion that it is the case. The difference before/after the patch on the assembly is: --- pr99334.s~ 2021-03-26 15:42:40.881749380 +0100 +++ pr99334.s 2021-03-26 17:38:05.729161910 +0100 @@ -11,8 +11,8 @@ _func_with_dwarf_issue_: andq$-16, %rsp pushq -8(%r10) pushq %rbp - .cfi_escape 0x10,0x6,0x2,0x76,0 movq%rsp, %rbp + .cfi_escape 0x10,0x6,0x2,0x76,0 pushq %r15 pushq %r14 pushq %r13 i.e. does just what we IMHO need, after pushq %rbp %rbp still contains parent's frame value and so the save rule doesn't need to be overridden there, ditto at the start of the next insn before the side-effect took effect, and we override it only after it when %rbp already has the right value. If some other target adds dynamic stack realignment in the future and the offset 0 case wouldn't be true there, the code can be adjusted so that it works on all the drap architectures, I'm pretty sure the code would need other adjustments too. For the rule 18 and for the (set hfp sp) after it we already have asserts for the drap
[Bug target/99718] [11 regression] ICE in new test case gcc.target/powerpc/pr98914.c for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718 --- Comment #18 from Segher Boessenkool --- (In reply to luoxhu from comment #12) > Not sure whether TARGET_DIRECT_MOVE_64BIT is the right MACRO to correctly > differentiate m32 and m64? It is not. It looks at TARGET_POWERPC64 only, and that can be set for -m32 just fine.
[Bug tree-optimization/59970] Bogus Wuninitialized warnings at low optimization levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59970 --- Comment #8 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:980b12cc81979e52f491bf0dfe961d30c07fe864 commit r11-7869-g980b12cc81979e52f491bf0dfe961d30c07fe864 Author: Martin Sebor Date: Fri Mar 26 16:37:34 2021 -0600 PR tree-optimization/59970 - Bogus -Wmaybe-uninitialized at low optimization levels PR tree-optimization/59970 * gcc.dg/uninit-pr59970.c: New test.
[Bug target/99718] [11 regression] ICE in new test case gcc.target/powerpc/pr98914.c for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718 --- Comment #17 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #10) > https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567215.html Ah, that is more recent than anything I have replied to :-(
[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 59970, which changed state. Bug 59970 Summary: Bogus Wuninitialized warnings at low optimization levels https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59970 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/59970] Bogus Wuninitialized warnings at low optimization levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59970 Martin Sebor changed: What|Removed |Added Target Milestone|--- |7.0 CC||msebor at gcc dot gnu.org Known to fail||4.8.4, 4.9.4, 5.5.0, 6.4.0 Keywords||diagnostic Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Sebor --- The test case in comment #0 is not diagnosed anymore. Bisection points to r240221 as the fix. Ditto for attachment 35384 from comment #3. Let me add the one from attachment 31970 to the test suite and resolve this as fixed.
[Bug other/99796] New: gfortran.dg/class_assign_4.f90 fails for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99796
Bug ID: 99796
Summary: gfortran.dg/class_assign_4.f90 fails for 32 bits
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
These failures occurs for powerpc64 32 bit and happen with trunk, gcc 10, and
gcc 9. I am not sure if this is related to PR99307 or not.
If was introduced in gcc 9 here (which mentioned it is a backport):
g:cd34d8b7b50f0f3592deb76983191c3d9a5dbcb9, r9-9249
make -k check-gcc-fortran RUNTESTFLAGS="--target_board=unix'{-m32}'
dg.exp=gfortran.dg/class_assign_4.f90"
FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test
FAIL: gfortran.dg/class_assign_4.f90 -O1 execution test
FAIL: gfortran.dg/class_assign_4.f90 -O2 execution test
FAIL: gfortran.dg/class_assign_4.f90 -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/class_assign_4.f90 -O3 -g execution test
FAIL: gfortran.dg/class_assign_4.f90 -Os execution test
# of expected passes6
# of unexpected failures6
Running /home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/dg.exp ...
*** Error in `./class_assign_4.exe': free(): invalid next size (fast):
0x10032068 ***
=== Backtrace: =
/lib/libc.so.6(cfree+0x458)[0xfaf4cf8]
./class_assign_4.exe[0x10008db8]
./class_assign_4.exe[0x10009648]
./class_assign_4.exe[0x100096a4]
/lib/libc.so.6(+0x220b4)[0xfa820b4]
/lib/libc.so.6(+0x22250)[0xfa82250]
=== Memory map:
0010-0012 r-xp 00:00 0 [vdso]
0fa6-0fc2 r-xp fd:00 67854221
/usr/lib/libc-2.17.so
0fc2-0fc3 r--p 001b fd:00 67854221
/usr/lib/libc-2.17.so
0fc3-0fc4 rw-p 001c fd:00 67854221
/usr/lib/libc-2.17.so
0fc5-0fcb r-xp fd:02 5387991358
/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libquadmath/.libs/libquadmath.so.0.0.0
0fcb-0fcc r--p 0005 fd:02 5387991358
/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libquadmath/.libs/libquadmath.so.0.0.0
0fcc-0fcd rwxp 0006 fd:02 5387991358
/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libquadmath/.libs/libquadmath.so.0.0.0
0fce-0fd0 r-xp fd:02 2166253499
/home/seurer/gcc/git/build/gcc-test/gcc/32/libgcc_s.so.1
0fd0-0fd1 r--p 0001 fd:02 2166253499
/home/seurer/gcc/git/build/gcc-test/gcc/32/libgcc_s.so.1
0fd1-0fd2 rwxp 0002 fd:02 2166253499
/home/seurer/gcc/git/build/gcc-test/gcc/32/libgcc_s.so.1
0fd3-0fe0 r-xp fd:00 67408437
/usr/lib/libm-2.17.so
0fe0-0fe1 r--p 000c fd:00 67408437
/usr/lib/libm-2.17.so
0fe1-0fe2 rw-p 000d fd:00 67408437
/usr/lib/libm-2.17.so
0fe3-0ffd r-xp fd:02 5400562421
/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libgfortran/.libs/libgfortran.so.5.0.0
0ffd-0ffe r--p 0019 fd:02 5400562421
/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libgfortran/.libs/libgfortran.so.5.0.0
0ffe-0fff rwxp 001a fd:02 5400562421
/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libgfortran/.libs/libgfortran.so.5.0.0
1000-1001 r-xp fd:02 4325512450
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/class_assign_4.exe
1001-1002 r--p fd:02 4325512450
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/class_assign_4.exe
1002-1003 rw-p 0001 fd:02 4325512450
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/class_assign_4.exe
1003-1006 rw-p 00:00 0 [heap]
f7f9-f7fa rw-p 00:00 0
f7fa-f7fd r-xp fd:00 67820991
/usr/lib/ld-2.17.so
f7fd-f7fe r--p 0002 fd:00 67820991
/usr/lib/ld-2.17.so
f7fe-f7ff rw-p 0003 fd:00 67820991
/usr/lib/ld-2.17.so
fffc- rw-p 00:00 0
[stack]
FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test
*** Error in `./class_assign_4.exe': free(): invalid next size (fast):
0x10032068 ***
=== Backtrace: =
/lib/libc.so.6(cfree+0x458)[0xfaf4cf8]
[Bug middle-end/57832] compiling sha-256 code (xz 5.0.5) generates false warnings when using -march=native on Atom CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57832
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2018-10-09 00:00:00 |2021-3-26
Known to fail||10.2.0, 11.0, 4.8.4, 4.9.4,
||5.5.0, 6.4.0, 7.2.0, 8.3.0,
||9.1.0
CC||msebor at gcc dot gnu.org
--- Comment #4 from Martin Sebor ---
Reconfirmed with GCC 11 and a slightly further reduced test case:
int a, b, d;
void f (void)
{
unsigned c;
for (int e = 0; e < 64; e += 6)
{
if (e)
b = e;
else
c = d;
if (e)
a += c;
}
}
The output with a slightly patched GCC to add notes after the warning shows the
condition under which the variable is used uninitialized:
pr57832.c: In function ‘f’:
pr57832.c:15:11: warning: ‘c’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
15 | a += c;
| ^~
pr57832.c:5:12: note: used when ‘ivtmp != 0’
5 | unsigned c;
|^
pr57832.c:5:12: note: ‘c’ was declared here
The annotated dump below helps explain what's going on: the c_21 PHI in bb 3 is
(partly) uninitialized. The warning finds its first use (1) in c_21 in bb 3.
It then finds its use (2) in c_25 in bb 5. Finally, it finds c_25's use (3) in
the assignment to _4 in bb 4. In other words, the uninitialized c flows from
-> -> -> -> -> . I don't see anything in the IL to avoid coming to this conclusion so I
don't think there's anything to change in the warning code to suppress it.
;; Function f (f, funcdef_no=0, decl_uid=1946, cgraph_uid=1, symbol_order=3)
[WORKLIST]: add to initial list: c_21 = PHI
[CHECK]: examining phi: c_21 = PHI
[CHECK] Found def edge 1 in c_25 = PHI
[CHECK]: Found unguarded use: c_25 = PHI
[WORKLIST]: Update worklist with phi: c_25 = PHI
[CHECK] Found def edge 1 in c_25 = PHI
[CHECK]: Found unguarded use: _4 = a.2_3 + c_21;
{
unsigned int ivtmp.11;
unsigned int ivtmp.10;
int a_lsm.7;
int b_lsm.6;
int e;
unsigned int c;
int d.0_1;
unsigned int a.2_3;
unsigned int _4;
int _5;
[local count: 89442694]:
d.0_1 = d;
c_14 = (unsigned int) d.0_1;
a_lsm.7_18 = a;
[local count: 984299128]:
# c_21 = PHI<<< use 1: c_12(D) is
uninitialized
# a_lsm.7_11 = PHI
# ivtmp.10_2 = PHI
# ivtmp.11_20 = PHI
e_22 = (int) ivtmp.10_2;
if (e_22 != 0)
goto ; [64.00%]
else
goto ; [36.00%]
[local count: 354347685]:
goto ; [100.00%]
[local count: 629951444]:
a.2_3 = (unsigned int) a_lsm.7_11;
_4 = a.2_3 + c_21; <<< use 3:
-Wmaybe-uninitialized
_5 = (int) _4;
e_17 = (int) ivtmp.11_20;
if (e_17 <= 63)
goto ; [86.98%]
else
goto ; [13.02%]
[local count: 547959327]: <<< c_21(8) = c21(3)
[local count: 902307011]:
# c_25 = PHI <<< use 2: c_25 =
c_21(8)
# a_lsm.7_10 = PHI <_5(8), a_lsm.7_11(7)>
ivtmp.10_7 = ivtmp.10_2 + 6;
ivtmp.11_26 = ivtmp.11_20 + 6;
goto ; [100.00%]
[local count: 89442696]:
b = e_22;
a = _5;
return;
}
[Bug ipa/99785] Awful lot of time spent building gl.cc in Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99785 --- Comment #16 from Jan Hubicka --- OK,we seem to handle all relevant always_inlines in early passes and then we produce functions large function with many non-always_inline calls that we spend a lot of time inlining. This is becuase we have relative function growth bounds that are quite high and we manage to get a lot of inlining done. I guess clang hits cap on those earlier. I will check if I can save some compile time. Honza
[Bug ipa/99785] Awful lot of time spent building gl.cc in Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99785 --- Comment #15 from Jan Hubicka --- We run into the size estimate with always inlines because after inlining we update the size of caller (because that does matter when inlining normal functions). We already have special purepose always inliner to avoid some of the issues, so I guess we keep running into this during the late IPA inlining? Honza
[Bug fortran/99348] ICE in resolve_structure_cons, at fortran/resolve.c:1286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99348
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #3 from anlauf at gcc dot gnu.org ---
There's no ICE when x is scalar:
type(t), parameter :: x = t('abc')
With the following patch we avoid the NULL pointer dereference at
resolve.c:1286
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 1c9b0c5cb62..0b9e11cdd41 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -1282,7 +1282,7 @@ resolve_structure_cons (gfc_expr *expr, int init)
/* A constructor may have references if it is the result of substituting a
parameter variable. In this case we just pull out the component we
want. */
- if (expr->ref)
+ if (expr->ref && expr->ref->u.c.sym)
comp = expr->ref->u.c.sym->components;
else
comp = expr->ts.u.derived->components;
but later run into an issue at expr.c:1917:
1913 for (c = gfc_constructor_first
(p->value.constructor);
1914 c; c = gfc_constructor_next (c))
1915{
1916 c->expr->ref = gfc_copy_ref (p->ref->next);
1917 if (!simplify_const_ref (c->expr))
1918return false;
1919}
(gdb) p c->expr->ts.u.cl->length
$104 = (gfc_expr *) 0x0
(gdb) p c->expr->value.character.length
$105 = 3
This leads to an ICE during processing simplify_const_ref.
[Bug c++/98352] [9/10/11 Regression] ICE in implicitly_declare_fn, at cp/method.c:2914 since r9-6097-g9d35a27a8353b57e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98352 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Fixed in GCC 11.
[Bug libstdc++/99789] std::span or std::string_view are not zero-overhead on microsoft abi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99789 --- Comment #11 from cqwrteur --- (In reply to Jonathan Wakely from comment #10) > We don't want the assembly file. If you want to investigate what Rust does, > you are free to do that. But stop asking us to do that for you. There is no > GCC bug here. Well. Is that any attribute for my custom types to make them spreads for multiple registers? I am not asking std::span or std::string_view here.
[Bug c++/98352] [9/10/11 Regression] ICE in implicitly_declare_fn, at cp/method.c:2914 since r9-6097-g9d35a27a8353b57e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98352 --- Comment #3 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:c453a817129c2c362726a9773390419f1df7dda3 commit r11-7868-gc453a817129c2c362726a9773390419f1df7dda3 Author: Marek Polacek Date: Fri Mar 26 11:20:03 2021 -0400 c++: ICE on invalid with NSDMI in C++98 [PR98352] NSDMIs are a C++11 thing, and here we ICE with them on the non-C++11 path. Fortunately all we need is a small tweak to my recent r11-7835 patch. gcc/cp/ChangeLog: PR c++/98352 * method.c (implicitly_declare_fn): Pass to synthesized_method_walk. gcc/testsuite/ChangeLog: PR c++/98352 * g++.dg/cpp0x/inh-ctor37.C: Remove dg-error. * g++.dg/cpp0x/nsdmi17.C: New test.
[Bug fortran/96012] [9/10/11 Regression] ICE in fold_convert_loc, at fold-const.c:2558
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96012 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #6 from anlauf at gcc dot gnu.org --- This PR appears to remain an 8-only regression, as the testcases in comment#0 do compile now. Shall this PR be closed?
[Bug ipa/99785] Awful lot of time spent building gl.cc in Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99785 Jeff Muizelaar changed: What|Removed |Added CC||jmuizelaar at mozilla dot com --- Comment #14 from Jeff Muizelaar --- re: __builtin_shuffle vs __builtin_shufflevector - It looks like __builtin_shuffle doesn't support constructing vectors of a different size than input type. That's mostly what we're using __builtin_shufflevector for. __builtin_shufflevector https://github.com/servo/webrender/blob/master/swgl/src/vector_type.h I briefly tried to get the gcc variant of the code compiling with clang but ran into a number of issues including clang's lack of support for '__builtin_shuffle'. If you'd like to try, the swgl code is pretty easy to build locally if you. You should be able to just checkout https://github.com/servo/webrender/ navigate to the the 'swgl' directory and run 'cargo build --release' re: inlining huge functions - We tried not inlining blend_pixels with clang and it seems to have a negative impact on a number of benchmarks.
[Bug libstdc++/85494] implementation of random_device on mingw is useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85494 --- Comment #19 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:5f070ba29803c99a5fe94ed7632d7b8c55593df3 commit r11-7867-g5f070ba29803c99a5fe94ed7632d7b8c55593df3 Author: Jonathan Wakely Date: Fri Mar 26 18:39:49 2021 + libstdc++: Add PRNG fallback to std::random_device This makes std::random_device usable on VxWorks when running on older x86 hardware. Since the r10-728 fix for PR libstdc++/85494 the library will use the new code unconditionally on x86, but the cpuid checks for RDSEED and RDRAND can fail at runtime, depending on the hardware where the code is executing. If the OS does not provide /dev/urandom then this means the std::random_device constructor always fails. In previous releases if /dev/urandom is unavailable then std::mt19937 was used unconditionally. This patch adds a fallback for the case where the runtime cpuid checks for x86 hardware instructions fail, and no /dev/urandom is available. When this happens a std::linear_congruential_engine object will be used, with a seed based on hashing the engine's address and the current time. Distinct std::random_device objects will use different seeds, unless an object is created and destroyed and a new object created at the same memory location within the clock tick. This is not great, but is better than always throwing from the constructor, and better than always using std::mt19937 with the same seed (as GCC 9 and earlier do). libstdc++-v3/ChangeLog: * src/c++11/random.cc (USE_LCG): Define when a pseudo-random fallback is needed. [USE_LCG] (bad_seed, construct_lcg_at, destroy_lcg_at, __lcg): New helper functions and callback. (random_device::_M_init): Add 'prng' and 'all' enumerators. Replace switch with fallthrough with a series of 'if' statements. [USE_LCG]: Construct an lcg_type engine and use __lcg when cpuid checks fail. (random_device::_M_init_pretr1) [USE_MT19937]: Accept "prng" token. (random_device::_M_getval): Check for callback unconditionally and always pass _M_file pointer. * testsuite/26_numerics/random/random_device/85494.cc: Remove effective-target check. Use new random_device_available helper. * testsuite/26_numerics/random/random_device/94087.cc: Likewise. * testsuite/26_numerics/random/random_device/cons/default-cow.cc: Remove effective-target check. * testsuite/26_numerics/random/random_device/cons/default.cc: Likewise. * testsuite/26_numerics/random/random_device/cons/token.cc: Use new random_device_available helper. Test "prng" token. * testsuite/util/testsuite_random.h (random_device_available): New helper function.
[Bug c++/99283] [modules] ICE in assert_definition, at cp/module.cc:4608
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99283 --- Comment #11 from Nathan Sidwell --- more fixes * d82797420c2 2021-03-26 | c++: imported templates and alias-template changes [PR 99283
[Bug c++/99283] [modules] ICE in assert_definition, at cp/module.cc:4608
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99283 --- Comment #10 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:d82797420c2238e31a7a25fe6db6bd05cd37224d commit r11-7866-gd82797420c2238e31a7a25fe6db6bd05cd37224d Author: Nathan Sidwell Date: Fri Mar 26 10:46:31 2021 -0700 c++: imported templates and alias-template changes [PR 99283] During development of modules, I had difficulty deciding whether the module flags of a template should live on the decl_template_result, the template_decl, or both. I chose the latter, and require them to be consistent. This and a few other defects show how hard that consistency is. Hence this patch move to holding the flags on the template-decl-result decl. That's the entity various bits of the parser have at the appropriate time. Once needs STRIP_TEMPLATE in a bunch of places, which this patch adds. Also a check that we never give a TEMPLATE_DECL to the module flag accessors. This left a problem with how I was handling template aliases. These were in two parts -- separating the TEMPLATE_DECL from the TYPE_DECL. That seemed somewhat funky, but development showed it necessary. Of course, that causes problems if the TEMPLATE_DECL cannot contain 'am imported' information. Investigating now shows that we do not need to treat them separately. By reverting a bit of template instantiation machinery that caused the problem, we're back on course. I think what has happened is that between then and now, other typedef fixes have corrected the underlying problem this separation was working around. It allows a bunch of cleanup in the decl streamer, as we no longer have to handle a null TEMPLATE_DECL_RESULT. PR c++/99283 gcc/cp/ * cp-tree.h (DECL_MODULE_CHECK): Ban TEMPLATE_DECL. (SET_TYPE_TEMPLATE_INFO): Restore Alias template setting. * decl.c (duplicate_decls): Remove template_decl module flag propagation. * module.cc (merge_kind_name): Add alias tmpl spec as a thing. (dumper::impl::nested_name): Adjust for template-decl module flag change. (trees_in::assert_definition): Likewise. (trees_in::install_entity): Likewise. (trees_out::decl_value): Likewise. Remove alias template separation of template and type_decl. (trees_in::decl_value): Likewise. (trees_out::key_mergeable): Likewise, (trees_in::key_mergeable): Likewise. (trees_out::decl_node): Adjust for template-decl module flag change. (depset::hash::make_dependency): Likewise. (get_originating_module, module_may_redeclare): Likewise. (set_instantiating_module, set_defining_module): Likewise. * name-lookup.c (name_lookup::search_adl): Likewise. (do_pushdecl): Likewise. * pt.c (build_template_decl): Likewise. (lookup_template_class_1): Remove special alias_template handling of DECL_TI_TEMPLATE. (tsubst_template_decl): Likewise. gcc/testsuite/ * g++.dg/modules/pr99283-2_a.H: New. * g++.dg/modules/pr99283-2_b.H: New. * g++.dg/modules/pr99283-2_c.H: New. * g++.dg/modules/pr99283-3_a.H: New. * g++.dg/modules/pr99283-3_b.H: New. * g++.dg/modules/pr99283-4.H: New. * g++.dg/modules/tpl-alias-1_a.H: Adjust scans. * g++.dg/modules/tpl-alias-1_b.C: Adjust scans.
[Bug fortran/96859] Wrong answer with intrinsic merge_bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96859 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #13 from anlauf at gcc dot gnu.org --- Anything left to do or can the PR be closed?
[Bug target/99781] [11 Regression] ICE in partial_subreg_p, at rtl.h:3144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99781 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- ICEs since r8-6032-g43cacb12fc859b671464b63668794158974b2a34 when SVE support has been added, so doesn't look like a regression to me, as before that it would not accept that option: invalid feature modifier in ‘-march=armv8-a+sve’
[Bug c++/99790] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_2 since r7-3811
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99790 --- Comment #2 from Jakub Jelinek --- Though, that doesn't make much sense, maybe r241137 instead?
[Bug c++/99790] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99790
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |8.5
CC||jakub at gcc dot gnu.org
Priority|P3 |P2
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-03-26
Summary|internal compiler error: in |[8/9/10/11 Regression]
|expand_expr_real_2 |internal compiler error: in
||expand_expr_real_2
--- Comment #1 from Jakub Jelinek ---
Original testcase (we always want them in bugzilla rather than some external
site):
#include
#include
#include
template
struct Variable{
std::string_view name;
void (*set)(T*);
};
struct test{
int var=0;
struct metadata{
static constexpr std::array, 1> fields{
Variable{"var",
[](test* obj){obj->*(::var)=42;}
}};
};
};
int main(){
test t;
test::metadata::fields[0].set();
std::cout << t.var << "\n";
}
Reduced:
struct a {
constexpr a(const char *) : b{}, c{} {}
long b;
char c;
};
using d = a;
struct e;
struct f;
template struct m { typedef e g; };
template struct o {
typename m::g i;
void operator[](long) const;
};
struct e {
d j;
void (*k)(f *);
};
struct f {
int l;
struct p {
static constexpr o<1> fields{"", [](f *n) { n->*::l = 2; }};
};
};
int main() { f::p::fields[0]; }
With -std=c++1z started to ICE with
r7-3811-g253abb2a156c6ea7d1631bbe9da32070fdfe901b
[Bug target/96582] aarch64:ICE during GIMPLE pass: veclower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96582 --- Comment #6 from rsandifo at gcc dot gnu.org --- (In reply to Alex Coplan from comment #5) > so not sure if the issue was really fixed or perhaps just hidden. Yeah, agree it's probably just gone latent.
[Bug c++/99795] [8/9/10/11 Regression] -Wnarrowing/-Woverflow false-negative in constant expression in undeduced context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99795 Marek Polacek changed: What|Removed |Added Target Milestone|--- |8.5 Summary|-Wnarrowing/-Woverflow |[8/9/10/11 Regression] |false-negative in constant |-Wnarrowing/-Woverflow |expression in undeduced |false-negative in constant |context |expression in undeduced ||context
[Bug c++/99795] -Wnarrowing/-Woverflow false-negative in constant expression in undeduced context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99795 Marek Polacek changed: What|Removed |Added Last reconfirmed||2021-03-26 Keywords||accepts-invalid Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed, thanks for opening.
[Bug target/99787] [11 Regression] ICE in curr_insn_transform, at lra-constraints.c:4133 since r11-7807-gbe70bb5e4babdf9d3d33e8f4658452038407fa8e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99787 Vladimir Makarov changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Vladimir Makarov --- The patch for PR99766 has fixed this. *** This bug has been marked as a duplicate of bug 99766 ***
[Bug target/99766] [11 Regression] ICE: unable to generate reloads with SVE code since r11-7807-gbe70bb5e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99766 Vladimir Makarov changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #9 from Vladimir Makarov --- *** Bug 99787 has been marked as a duplicate of this bug. ***
[Bug target/99766] [11 Regression] ICE: unable to generate reloads with SVE code since r11-7807-gbe70bb5e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99766 --- Comment #8 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:0d37e2d3ead072ba57e03fcb97a041504a22e721 commit r11-7864-g0d37e2d3ead072ba57e03fcb97a041504a22e721 Author: Vladimir Makarov Date: Fri Mar 26 17:09:24 2021 + [PR99766] Consider relaxed memory associated more with memory instead of special memory. Relaxed memory should be considered more like memory then special memory. gcc/ChangeLog: PR target/99766 * ira-costs.c (record_reg_classes): Put case with CT_RELAXED_MEMORY adjacent to one with CT_MEMORY. * ira.c (ira_setup_alts): Ditto. * lra-constraints.c (process_alt_operands): Ditto. * recog.c (asm_operand_ok): Ditto. * reload.c (find_reloads): Ditto. gcc/testsuite/ChangeLog: PR target/99766 * g++.target/aarch64/sve/pr99766.C: New.
[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013 --- Comment #10 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #9) > > > Sometime the test ICE with > > > > > > f951: internal compiler error: gfc_code2string(): Bad code > > > > > > which cannot be fixed by the patch in comment 6. > > > > > > > Don't know anything about libsantize. > > The error has nothing to do with libsanitize. So, then why are you posting incomprehensible garbage from libsanitize, which may have absolutely nothing to do with this patch. The patch in comment #6 prevents the segfault; thereby allowing f951 to continue with the processing of the source code. > It is generated by gfc_code2string in gcc/fortran/misc.c > in a random manner. I cannot reproduce your results. Without a method to reproduce the issue and/or a complete backtrace with line numbers, I standby my assertion that the patch in comment #6 fixes the segfault reported by Gerhard. More importantly, it does not matter if the patch fixes the segfault, because no one is going to commit it anyway.
[Bug c++/99795] New: -Wnarrowing/-Woverflow false-negative in constant expression in undeduced context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99795
Bug ID: 99795
Summary: -Wnarrowing/-Woverflow false-negative in constant
expression in undeduced context
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
CC: jason at redhat dot com, mpolacek at gcc dot gnu.org
Target Milestone: ---
template struct X {};
template X foo();
int x = sizeof(foo());
template
struct bar { typedef X t; };
bar y;
GCC 4.6-6 had an -Woverflow warning here; since GCC 7 -Wconversion warning was
emitted instead, but since bug 99331 is fixed there is no warning at all.
[Bug fortran/56670] Allocatable-length character var causes bogus warning with -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56670 Martin Sebor changed: What|Removed |Added Known to fail||10.2.0, 11.0, 4.8.4, 4.9.4, ||5.5.0, 6.4.0, 7.2.0, 8.3.0, ||9.1.0 Last reconfirmed|2014-03-22 00:00:00 |2021-3-26 CC||msebor at gcc dot gnu.org --- Comment #10 from Martin Sebor --- Reconfirming with GCC 11.
[Bug tree-optimization/56654] uninit warning behaves erratically (always executed block, "is" vs "may", order when walking uses)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56654 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Last reconfirmed|2014-09-12 00:00:00 |2021-3-26 Known to fail||10.2.0, 11.0, 4.9.3, 5.3.0, ||6.2.0, 7.5.0, 8.3.0, 9.3.0 CC||msebor at gcc dot gnu.org --- Comment #4 from Martin Sebor --- Reconfirming with GCC 11.
[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013 --- Comment #9 from Dominique d'Humieres --- > > Sometime the test ICE with > > > > f951: internal compiler error: gfc_code2string(): Bad code > > > > which cannot be fixed by the patch in comment 6. > > > > Don't know anything about libsantize. The error has nothing to do with libsanitize. It is generated by gfc_code2string in gcc/fortran/misc.c in a random manner.
[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #8 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #7) > Sometime the test ICE with > > f951: internal compiler error: gfc_code2string(): Bad code > > which cannot be fixed by the patch in comment 6. > Don't know anything about libsantize. You can fix that issue. The patch I supplied in comment 6 fixes the issue reported by Gerhard. (Un)Fortunately, no one will ever commit the patch. So, I suppose we're all good here.
[Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99334
--- Comment #9 from Jakub Jelinek ---
As I said on the mailing list, the above patch has problems, it relies on the
insn that clobbers_queued_reg_save to be a single hardware instruction so that
a debug info consumer or unwinding can't stop "in the middle of the
instruction".
We have various NONJUMP_INSN_P insns that violate that, for one inline asm, but
also various patterns that emit more than one insn.
E.g. on x86 they are usually (but unsure if we can guarantee that) marked by
get_attr_type (insn) == TYPE_MULTI.
I have tried to instead deal with this on the i386.c side with:
--- i386.c.jj3 2021-03-25 21:05:35.554309579 +0100
+++ i386.c 2021-03-26 15:56:21.349642695 +0100
@@ -8355,9 +8355,33 @@ ix86_expand_prologue (void)
if (m->fs.sp_offset == frame.hard_frame_pointer_offset)
{
+ if (stack_realign_drap)
+ {
+ /* Pretend the push %[re]bp instruction is just
+add $-wordsize, [%re]sp for CFI purposes. */
+ rtx spadj = plus_constant (Pmode, stack_pointer_rtx,
+-UNITS_PER_WORD);
+ rtx r = gen_rtx_SET (stack_pointer_rtx, spadj);
+ add_reg_note (insn, REG_FRAME_RELATED_EXPR, r);
+ }
+
insn = emit_move_insn (hard_frame_pointer_rtx, stack_pointer_rtx);
RTX_FRAME_RELATED_P (insn) = 1;
+ if (stack_realign_drap)
+ {
+ /* And that the mov %[re]sp, %[re]bp instruction acts as
+both mov %[re]bp, (%[re]sp) and mov %[re]sp, %[re]bp
+together for CFI purposes. */
+ rtx r = gen_rtx_PARALLEL (VOIDmode, rtvec_alloc (2));
+ XVECEXP (r, 0, 0)
+ = gen_rtx_SET (gen_rtx_MEM (word_mode, stack_pointer_rtx),
+ hard_frame_pointer_rtx);
+ XVECEXP (r, 0, 1)
+ = gen_rtx_SET (hard_frame_pointer_rtx, stack_pointer_rtx);
+ add_reg_note (insn, REG_FRAME_RELATED_EXPR, r);
+ }
+
if (m->fs.cfa_reg == stack_pointer_rtx)
m->fs.cfa_reg = hard_frame_pointer_rtx;
m->fs.fp_offset = m->fs.sp_offset;
but unfortunately that doesn't work properly, because dwarf2cfi.c has special
rule for that push %[re]bp with drap active, described as Rule 18.
So I think we should instead change the dwarf2cfi.c rule 18 handling so that it
waits with the reg save until the hfp = sp instruction after it.
Generally, there is also the option of e.g. adding some insn attribute on
targets that want it which would say which instructions are single undivisible
hw instructions and use that get_attr_{single,undivisible} or how it would be
called in dwarf2cfi.c to decide whether to emit queued reg saves before it or
after it.
[Bug d/91595] Version (Windows) is not defined in GCC D Compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91595 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #13 from Iain Buclaw --- Necessary versions have been committed to mainline. I've created a new PR for tracking library fixes in pr99794.
[Bug d/99794] New: libphobos: Support building on *-*mingw*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99794 Bug ID: 99794 Summary: libphobos: Support building on *-*mingw* Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ibuclaw at gdcproject dot org Target Milestone: --- Baseline compiler support has been added in pr91595, this issue is for finishing off the library port.
[Bug ipa/99466] internal compiler error: in function_and_variable_visibility, at ipa-visibility.c:795
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99466 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Iain Buclaw --- Committed, and backported to gcc-10 and gcc-9.
[Bug ipa/99466] internal compiler error: in function_and_variable_visibility, at ipa-visibility.c:795
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99466 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:fd23b0bb77d483c07bc14f86cc349f82b1b38320 commit r9-9310-gfd23b0bb77d483c07bc14f86cc349f82b1b38320 Author: Iain Buclaw Date: Sat Mar 13 17:05:52 2021 +0100 Fix ICE: in function_and_variable_visibility, at ipa-visibility.c:795 [PR99466] In get_emutls_init_templ_addr, only thread-local declarations that were DECL_ONE_ONLY would have a public initializer symbol, ignoring variables that were declared with __attribute__((weak)). gcc/ChangeLog: PR ipa/99466 * tree-emutls.c (get_emutls_init_templ_addr): Mark initializer of weak TLS declarations as public. gcc/testsuite/ChangeLog: PR ipa/99466 * gcc.dg/tls/pr99466-1.c: New test. * gcc.dg/tls/pr99466-2.c: New test. (cherry picked from commit 8f5e18db259c8a9790feb1d73bb0348182264f15)
[Bug ipa/99466] internal compiler error: in function_and_variable_visibility, at ipa-visibility.c:795
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99466 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:1df9bfdd24388adccdb6a07eda6161ef6626dac5 commit r10-9547-g1df9bfdd24388adccdb6a07eda6161ef6626dac5 Author: Iain Buclaw Date: Sat Mar 13 17:05:52 2021 +0100 Fix ICE: in function_and_variable_visibility, at ipa-visibility.c:795 [PR99466] In get_emutls_init_templ_addr, only thread-local declarations that were DECL_ONE_ONLY would have a public initializer symbol, ignoring variables that were declared with __attribute__((weak)). gcc/ChangeLog: PR ipa/99466 * tree-emutls.c (get_emutls_init_templ_addr): Mark initializer of weak TLS declarations as public. gcc/testsuite/ChangeLog: PR ipa/99466 * gcc.dg/tls/pr99466-1.c: New test. * gcc.dg/tls/pr99466-2.c: New test. (cherry picked from commit 8f5e18db259c8a9790feb1d73bb0348182264f15)
[Bug middle-end/56574] False "may be uninitialized variable" warning (&& converted to &)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56574
Martin Sebor changed:
What|Removed |Added
Keywords||missed-optimization
Known to fail||10.2.0, 11.0, 4.7.4, 4.8.4,
||4.9.4, 5.5.0, 6.4.0, 7.2.0,
||8.3.0, 9.1.0
CC||msebor at gcc dot gnu.org
Last reconfirmed|2013-03-11 00:00:00 |2021-3-26
--- Comment #12 from Martin Sebor ---
Reconfirming for GCC 11.
With a slightly tweaked test case and a patched GCC to print the conditions
under which it determines the variable is uninitialized the note after the
warning makes it clear even without looking at the dump that the warning is a
false positive.
$ cat pr56574.c && gcc -O2 -S -Wuninitialized -Wmaybe-uninitialized
-fdump-tree-uninit=/dev/stdout pr56574.c
int f (void);
void g (int i)
{
int x;
if (i == 0)
x = f ();
for (;;)
{
if (i == 0 && x)
continue;
if (i == 0)
break;
}
}
;; Function g (g, funcdef_no=0, decl_uid=1945, cgraph_uid=1, symbol_order=0)
0 dep_chains for phi_bb 4, use_bb 4:
tmp chain = i_6(D) == 0
one_pred = i_6(D) == 0
pr56574.c: In function ‘g’:
pr56574.c:12:16: warning: ‘x’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
12 | if (i == 0 && x)
|^~
pr56574.c:5:7: note: when ‘i != 0’
5 | int x;
| ^
pr56574.c:5:7: note: ‘x’ was declared here
void g (int i)
{
int x;
_Bool _14;
_Bool _15;
_Bool _16;
[local count: 79134772]:
if (i_6(D) == 0)
goto ; [33.00%]
else
goto ; [67.00%]
[local count: 53020297]:
goto ; [100.00%]
[local count: 26114475]:
x_10 = f ();
[local count: 79134772]:
# x_11 = PHI
_14 = i_6(D) == 0;
_15 = x_11 != 0;
_16 = _14 & _15;
[local count: 719407024]:
[local count: 1073741824]:
if (_16 != 0)
goto ; [33.00%]
else
goto ; [67.00%]
[local count: 354334800]:
goto ; [100.00%]
[local count: 719407024]:
if (i_6(D) == 0)
goto ; [11.00%]
else
goto ; [89.00%]
[local count: 640272252]:
goto ; [100.00%]
[local count: 79134772]:
return;
}
[Bug c++/99331] [8/9/10 Regression] -Wconversion false-positive in immediate context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99331 --- Comment #8 from Marek Polacek --- Yeah, that's expected (but it's a bug!): https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566449.html Opening a separate issue would be nice, thanks.
[Bug ipa/99466] internal compiler error: in function_and_variable_visibility, at ipa-visibility.c:795
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99466 --- Comment #7 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:8f5e18db259c8a9790feb1d73bb0348182264f15 commit r11-7849-g8f5e18db259c8a9790feb1d73bb0348182264f15 Author: Iain Buclaw Date: Sat Mar 13 17:05:52 2021 +0100 Fix ICE: in function_and_variable_visibility, at ipa-visibility.c:795 [PR99466] In get_emutls_init_templ_addr, only thread-local declarations that were DECL_ONE_ONLY would have a public initializer symbol, ignoring variables that were declared with __attribute__((weak)). gcc/ChangeLog: PR ipa/99466 * tree-emutls.c (get_emutls_init_templ_addr): Mark initializer of weak TLS declarations as public. gcc/testsuite/ChangeLog: PR ipa/99466 * gcc.dg/tls/pr99466-1.c: New test. * gcc.dg/tls/pr99466-2.c: New test.
[Bug d/91595] Version (Windows) is not defined in GCC D Compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91595 --- Comment #12 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:2892e2f70287f961e3bac990b926232cc2a5b123 commit r11-7847-g2892e2f70287f961e3bac990b926232cc2a5b123 Author: Iain Buclaw Date: Sun Mar 22 01:18:42 2020 +0100 d: Add windows support for D compiler [PR91595] gcc/ChangeLog: PR d/91595 * config.gcc (*-*-cygwin*): Add winnt-d.o (*-*-mingw*): Likewise. * config/i386/cygwin.h (EXTRA_TARGET_D_OS_VERSIONS): New macro. * config/i386/mingw32.h (EXTRA_TARGET_D_OS_VERSIONS): Likewise. * config/i386/t-cygming: Add winnt-d.o. * config/i386/winnt-d.c: New file.
[Bug d/99691] OpenBSD support for GDC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99691 --- Comment #3 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:8ab1d637440532d9698daae84cc81a43d36b4aa8 commit r11-7845-g8ab1d637440532d9698daae84cc81a43d36b4aa8 Author: Iain Buclaw Date: Sun Mar 21 11:00:29 2021 +0100 d: Add openbsd support for D compiler [PR99691] gcc/ChangeLog: PR d/99691 * config.gcc (*-*-openbsd*): Add openbsd-d.o. * config/t-openbsd: Add openbsd-d.o. * config/openbsd-d.c: New file.
[Bug tree-optimization/99793] New: missed optimization for dead code elimination at -Os, -O2 and -O3 (vs. -O1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99793
Bug ID: 99793
Summary: missed optimization for dead code elimination at -Os,
-O2 and -O3 (vs. -O1)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
[610] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210326 (experimental) [master revision
9d45e848d02:ca344bbd24f:6081d8994ed1a0aef6b7f5fb34f091faa3580416] (GCC)
[611] %
[611] % gcctk -O1 -S -o O1.s small.c
[612] % gcctk -O3 -S -o O3.s small.c
[613] %
[613] % wc O1.s O3.s
17 38 365 O1.s
37 78 633 O3.s
54 116 998 total
[614] %
[614] % grep foo O1.s
[615] % grep foo O3.s
callfoo
[616] %
[616] % cat small.c
extern void foo(void);
static int a, *b = , c, *d =
int main() {
int **e =
if (!((unsigned)((*e = d) == 0) - (*b = 1)))
foo();
return 0;
}
[Bug target/99786] [11 Regression] ICE in in extract_insn, at recog.c:2770 since r11-4199-g0f41b5e02fa47db2080b77e4e1f7cd3305457c05
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99786 Christophe Lyon changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from Christophe Lyon --- I'd like to submit the small patch I proposed in comment #2, but I have a trouble writing a testcase that is accepted by the assembler as described. The testcase would be the same as ubsan/pr79904.c, with the addition of V4HI vectors.
[Bug libstdc++/96416] address_of() is broken by static_assert in pointer_traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416 --- Comment #10 from Giuseppe D'Angelo --- (By the way, finding this bug is quite hard. Could "address_of" be changed to "to_address" , in the bug description? I think that's the intended meaning. And, "to_pointer", mentioned a few times, doesn't exist.)
[Bug debug/99654] Incorrect DW_AT_entry_pc values for inlined function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99654 --- Comment #3 from Will Cohen --- Created attachment 50480 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50480=edit Default assembly code generated by compiler Default Assembly generated by compiler to compare to the -gno-as-locview-support version that has more reasonable DW_AT_entry_pc values
[Bug target/99773] ARM v8.1-m MVE interaction with -mfloat-abi not clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773 --- Comment #5 from Christophe Lyon --- Compiling with -march=armv8.1-m.main+mve -mfloat-abi=hard defines: TARGET_SOFT_FLOAT 1 TARGET_HARD_FLOAT 0 TARGET_HARD_FLOAT_ABI 1 TARGET_VFP_SINGLE 1 so indeed what you propose does the trick. (Sorry I proposed comment #3 yesterday too in a hurry)
[Bug target/99792] New: MVE: Assemble failure with "branch out of range" at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99792
Bug ID: 99792
Summary: MVE: Assemble failure with "branch out of range" at
-O3
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following fails:
$ cat test.c
short a[2][19][6][844];
char b[2][19][40];
long long c[2][722];
void d() {
for (int e; e < 2; ++e)
for (int f = 0; f < 19; ++f)
for (int g = 0; g < 6; ++g)
for (int h = 0; h < 11; ++h)
for (int i = 0; i < 3; ++i)
a[e][f][g][h + i] = 0;
for (int e = 0; e < 2; ++e)
for (int f = 0; f < 19; ++f)
for (int g = 0; g < 6; ++g)
for (int h = 0; h < 3; ++h)
b[e][f][g * 6 + h] = 3;
for (int e = 0; e < 2; ++e)
for (int f = 0; f < 9; ++f)
for (int g = 0; g < 26; ++g)
for (int h = 0; h < 13; ++h)
c[e][f * 9 + g + h] = 90719611319;
}
$ arm-eabi-gcc -c test.c -march=armv8.1-m.main+mve -mfloat-abi=hard -O3
-mtune=cortex-a72
/tmp/ccaAJzi3.s: Assembler messages:
/tmp/ccaAJzi3.s:104: Error: branch out of range
Obviously the choice of scheduling is questionable given the choice of -march,
but we shouldn't generate out-of-range branches in any case.
[Bug debug/99654] Incorrect DW_AT_entry_pc values for inlined function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99654 --- Comment #2 from Will Cohen --- Created attachment 50479 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50479=edit assembly file compiled with -gno-as-locview-support Resulting assembly language file generated by: gcc -O3 -g -gno-as-locview-support -fverbose-asm -S -o test3_gcc_nolocview.s test3.c This can be compared to test3_gcc_locview.s that will be uploaded in a moment.
[Bug libstdc++/96416] address_of() is broken by static_assert in pointer_traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416 Giuseppe D'Angelo changed: What|Removed |Added CC||dangelog at gmail dot com --- Comment #9 from Giuseppe D'Angelo --- Hi, Stumbled across this indeed when trying to use contiguous iterators. Sure enough, pointer_traits for them is ill-formed. But then I don't understand why the "otherwise to_address(p.operator->())" part is in the Standard at all, if it can never be used. Has this been raised as a library defect? And are you recommending that everyone who defines their custom contiguous iterators specializes pointer_traits for them? Call it _quite_ annoying...
[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #35 from Iain Sandoe --- (In reply to Matt Thompson from comment #34) > Apologies. I forgot about this. Seeing as I'm now using GNU 10.2.0 on my > Macbook...I guess it's working. great! > and I can't wait for 10.3 or 11.0 or whatever is next! 10.3 release candidates should start in a few days, and then GCC-11 will be not too long after that ... > Note: I'm still on an Intel Mac, so I won't need to bother "Iain Sandoe, > master of M1 GNU" about that for a while. :D heh, M1 support in GCC12 is my objective - but there's a lot of work to do to get it there, let's see if 'experimental' can be morphed into 'production'.
[Bug target/99718] [11 regression] ICE in new test case gcc.target/powerpc/pr98914.c for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718 --- Comment #16 from Jakub Jelinek --- (In reply to luoxhu from comment #15) > Do you mean Power7 for the plain old VSX? I verified the pr98914.c on > Power7, it exactly ICEs on "gcc_assert (CONST_INT_P (elt_rtx));" for both > m64 and m32. This is still not fixed by the patch in #c11 yet. Sure, any CPU that has VSX or Altivec support. So VSX for power7 and Altivec for power5/6/G4/G5 or whatever has Altivec support.
[Bug c++/99331] [8/9/10 Regression] -Wconversion false-positive in immediate context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99331
--- Comment #7 from Nikita Kniazev ---
The fix silenced the true warning (though it was saying 'may') in these:
template struct X {};
template X foo();
int x = sizeof(foo());
template struct X {};
template
struct foo { using t = X; };
foo x;
Should I post this as a separate issue?
[Bug c/99791] New: -Wno-system-headers hides enum range Warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99791
Bug ID: 99791
Summary: -Wno-system-headers hides enum range Warning
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: listnothrow at gmail dot com
Target Milestone: ---
Created attachment 50478
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50478=edit
glimits.h from gcc 10.2.0 (commit 99dee82307f1e163e150c9c810452979994047ce)
When setting enum values using system header defines
like LONG_MAX or ULONG_MAX gcc won't complain about them being out of range of
int,
when compiling with -Wall -Wextra -pedantic
Using -Wsystem-headers will enable the warnings.
Using -save-temps will warn for LONG_MAX but not ULONG_MAX.
The bug can not be reproduced completely using -save-temps,
(LONG_MAX doesn't get annotated as coming from a system header)
I reckon that's a bug too.
To reproduce instead, I copied glimits.h (from gcc 10.2.0 see attached)
to the system include folder.
I hope that's okay in this case.
%cat warn_enum.c
#include
enum test {
warns_on_save_tmps = LONG_MAX,
doesnt_warn = ULONG_MAX
};
int main(){ return 0; }
%gcc --version
gcc (GCC) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
%gcc -Wall -Wextra -pedantic warn_enum.c
%gcc -Wall -Wextra -pedantic -save-temps warn_enum.c
warn_enum.c:4:20: warning: ISO C restricts enumerator values to range of ‘int’
[-Wpedantic]
4 | warns_save_tmps = LONG_MAX,
|^~
%gcc -Wall -Wextra -pedantic -Wsystem-headers warn_enum.c
warn_enum.c:4:21: warning: ISO C restricts enumerator values to range of ‘int’
[-Wpedantic]
4 | warns_save_tmps = LONG_MAX,
| ^~~~
In file included from warn_enum.c:1:
warn_enum.c:5:16: warning: ISO C restricts enumerator values to range of ‘int’
[-Wpedantic]
5 | doesnt_warn = ULONG_MAX
|
[Bug libstdc++/99789] std::span or std::string_view are not zero-overhead on microsoft abi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99789 --- Comment #10 from Jonathan Wakely --- We don't want the assembly file. If you want to investigate what Rust does, you are free to do that. But stop asking us to do that for you. There is no GCC bug here.
[Bug libstdc++/99789] std::span or std::string_view are not zero-overhead on microsoft abi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99789 --- Comment #9 from cqwrteur --- (In reply to Jakub Jelinek from comment #8) > Bugzilla is for reporting bugs, not for general programming advices. > > There is no bug here, the C++ standard for 64-bit architectures with its > requirements on std::string_view etc. effectively mandates that the class > stores a pointer and size which better should be also size_t and not > something narrower. > And you or your users made a choice of some ABI where passing this by value > means it is not passed in registers. but how rust works with that? Rust did pass them by registers even on msvc abi which makes me curious. I think I can send you the assembly file.
[Bug libstdc++/99789] std::span or std::string_view are not zero-overhead on microsoft abi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99789 --- Comment #8 from Jakub Jelinek --- Bugzilla is for reporting bugs, not for general programming advices. There is no bug here, the C++ standard for 64-bit architectures with its requirements on std::string_view etc. effectively mandates that the class stores a pointer and size which better should be also size_t and not something narrower. And you or your users made a choice of some ABI where passing this by value means it is not passed in registers.
[Bug c++/99790] New: internal compiler error: in expand_expr_real_2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99790 Bug ID: 99790 Summary: internal compiler error: in expand_expr_real_2 Product: gcc Version: 10.2.0 URL: https://godbolt.org/z/PsMrafh9c Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: antiro42 at gmail dot com Target Milestone: --- internal compiler error: in expand_expr_real_2, at expr.c:8701 Error is reproducible in compiler explorer with both gcc 10.2 and gcc trunk. See attached URL for a minimal reproduction scenario. The error seems to occur when trying to use the stored pointer to member in the lambda. I tried adding the suggested compiler flags but this did not influence the result. The code compiles fine in clang 11.
[Bug libstdc++/99789] std::span or std::string_view are not zero-overhead on microsoft abi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99789 --- Comment #7 from cqwrteur --- (In reply to Jonathan Wakely from comment #6) > Users of your library on Window will be affected by the ABI on Windows. > That's not a libstdc++ problem. > > Nobody said that std::span and std::string_view are guaranteed to always be > zero-overhead. yeah. So what's the solution if I am writing something else instead of using std::string_view or std::span without paying for the overhead. Do you have any attributes for that?
[Bug target/99718] [11 regression] ICE in new test case gcc.target/powerpc/pr98914.c for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718
--- Comment #15 from luoxhu at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #14)
> You still have:
> if (VECTOR_MEM_VSX_P (mode))
> {
> if (!CONST_INT_P (elt_rtx))
> {
> if ((TARGET_P9_VECTOR && TARGET_POWERPC64) || width == 8)
> return ..._p9 (...);
> else if (TARGET_P8_VECTOR)
> return ..._p8 (...);
> }
>
> if (mode == V2DFmode)
> insn = gen_vsx_set_v2df (target, target, val, elt_rtx);
>
> else if (mode == V2DImode)
> insn = gen_vsx_set_v2di (target, target, val, elt_rtx);
>
> else if (TARGET_P9_VECTOR && TARGET_POWERPC64)
> {
> ...
> }
> if (insn)
> return;
> }
>
> gcc_assert (CONST_INT_P (elt_rtx));
>
> while the vector.md condition is VECTOR_MEM_ALTIVEC_OR_VSX_P (mode),
> i.e. true for TARGET_ALTIVEC for many modes already (V4SI, V8HI, V16QI, V4SF
> and
> for TARGET_VSX also V2DF and V2DI, right).
> I somehow don't see how this can work properly.
> Looking at vsx_set_v2df and vsx_set_v2di, neither of them will handle
> non-constant elt_rtx (it ICEs on anything but const0_rtx and const1_rtx).
>
> So, questions:
> 1) does the rs6000_expand_vector_set_var_p9 routine for width == 8 (i.e.
> V2DImode or V2DFmode?)
> handle everything, even when TARGET_P9_VECTOR or TARGET_POWERPC64 is not
> true, plain old VSX?
Yes. V2DI/V2DF for P8 {BE,LE} {m32,m64} will call
rs6000_expand_vector_set_var_p9 instead of xxx_p8.
Do you mean Power7 for the plain old VSX? I verified the pr98914.c on Power7,
it exactly ICEs on "gcc_assert (CONST_INT_P (elt_rtx));" for both m64 and m32.
This is still not fixed by the patch in #c11 yet.
For builtin call in rs6000-c.c:altivec_build_resolved_builtin, it is guarded by
TARGET_P8_VECTOR, so Power7 doesn't generate IFN VEC_INSERT before. This ICE
also comes from internal optimization gimple-isel.c:gimple_expand_vec_set_expr,
can_vec_set_var_idx_p doesn't return false due to VECTOR_MEM_ALTIVEC_OR_VSX_P
is true when Power7 VSX, change the "if (VECTOR_MEM_VSX_P (mode))" to "if
(VECTOR_MEM_ALTIVEC_OR_VSX_P (mode))" in rs6000.c:rs6000_expand_vector_set and
remove TARGET_P8_VECTOR in the else branch could fix the ICE on P7 {m32,64}, so
this means even P7 VSX could benefit from this optimization, which is different
from what discussed before.
> 2) what happens if TARGET_P8_VECTOR is false and TARGET_VSX is true and mode
> is other than V2DI/V2DF? If I read the code right, it will fall through to
> gcc_assert (CONST_INT_P (elt_rtx));
Same like 1)?
> 3) what happens if !TARGET_VSX (more specifically, when VECTOR_MEM_VSX_P
> (mode) is false.
> I see there just the assertion that would fail right away.
> Perhaps I'm missing something obvious and those cases are impossible, but if
> that is the case, it would still be better to add further assertion at least
> to the if (...) else if (...) as else gcc_assert ...
Thanks for pointing out, the "gcc_assert (CONST_INT_P (elt_rtx));" should be
moved into the "if (!CONST_INT_P (elt_rtx))" condition like you said.
gen_vsx_set_v2df and gen_vsx_set_v2di are supposed to handle only const
elt_rtx.
[Bug libstdc++/99789] std::span or std::string_view are not zero-overhead on microsoft abi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99789 Jonathan Wakely changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #6 from Jonathan Wakely --- Users of your library on Window will be affected by the ABI on Windows. That's not a libstdc++ problem. Nobody said that std::span and std::string_view are guaranteed to always be zero-overhead.
[Bug libstdc++/99789] std::span or std::string_view are not zero-overhead on microsoft abi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99789 --- Comment #5 from cqwrteur --- (In reply to Jakub Jelinek from comment #1) > And what can libstdc++ do about that? > Just use a different OS with better ABIs... I use a lot of different systems. FreeBSD, MSDOS, Linux, Windows, etc. Using different OS is not an option tbh since I am a library author I cannot control how my users are going to use the library.
[Bug libstdc++/99789] std::span or std::string_view are not zero-overhead on microsoft abi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99789 --- Comment #4 from cqwrteur --- (In reply to Jakub Jelinek from comment #1) > And what can libstdc++ do about that? > Just use a different OS with better ABIs... Well, I tested that with Rust on windows, the parameters are passed by registers. If changing that in libstdc++ is impossible, can we provide another attribute to do this in some part of code? For example use "sysv_abi" but do not clean the SIMD registers.
[Bug libstdc++/99789] std::span or std::string_view are not zero-overhead on microsoft abi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99789 --- Comment #3 from cqwrteur --- Created attachment 50477 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50477=edit demo assembly
[Bug libstdc++/99789] std::span or std::string_view are not zero-overhead on microsoft abi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99789 --- Comment #2 from cqwrteur --- Created attachment 50476 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50476=edit demo source file
[Bug libstdc++/99789] std::span or std::string_view are not zero-overhead on microsoft abi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99789 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- And what can libstdc++ do about that? Just use a different OS with better ABIs...
[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013 --- Comment #7 from Dominique d'Humieres --- Sometime the test ICE with f951: internal compiler error: gfc_code2string(): Bad code which cannot be fixed by the patch in comment 6. A sanitized version with the patch at https://gcc.gnu.org/pipermail/fortran/2021-March/055811.html fails with ==51183==ERROR: AddressSanitizer: heap-use-after-free on address 0x6130351a at pc 0x0001002bac61 bp 0x7ffeefbfe6d0 sp 0x7ffeefbfe6c8 READ of size 1 at 0x6130351a thread T0 #0 0x1002bac60 in write_symbol(int, gfc_symbol*) module.c:5889 #1 0x1002bb0d3 in write_symbol1_recursion(sorted_pointer_info*) module.c:6122 #2 0x1002bb1be in write_symbol1_recursion(sorted_pointer_info*) module.c:6125 #3 0x1002bb43b in write_symbol1(pointer_info*) module.c:6155 #4 0x1002c51e0 in write_module() module.c:6302 #5 0x1002c568f in dump_module(char const*, int) module.c:6431 #6 0x1002c5df6 in gfc_dump_module(char const*, int) module.c:6488 #7 0x10038ac06 in gfc_parse_file() parse.c:6509 #8 0x10057734e in gfc_be_parse_file() f95-lang.c:212 #9 0x10715ded6 in compile_file() toplev.c:457 #10 0x10716c319 in do_compile() toplev.c:2201 #11 0x10a205550 in toplev::main(int, char**) toplev.c:2340 #12 0x10a20b4eb in main main.c:39 #13 0x7fff2066d620 in start+0x0 (libdyld.dylib:x86_64+0x15620) ...
[Bug libstdc++/99789] New: std::span or std::string_view are not zero-overhead on MS abi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99789 Bug ID: 99789 Summary: std::span or std::string_view are not zero-overhead on MS abi Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- The issue is that on Microsoft abi, any trivially copyable type whose size is not 1,2,4,8 bytes will be passed by pointer instead of value. The empty object will also waste one precious register even it does nothing. That means std::span, std::string_view etc incur extremely large overhead.
[Bug target/99766] [11 Regression] ICE: unable to generate reloads with SVE code since r11-7807-gbe70bb5e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99766
--- Comment #7 from Alex Coplan ---
Here is a testcase with SVE intrinsics that ICEs in the same way at -Os:
$ cat test.cc
#include
char a;
void c(unsigned &, const unsigned &);
void d(char, bool, short, int, int, char e, int, short f, unsigned g) {
for (int h; h; h++)
c(g, f);
while (e)
a = svaddv(svptrue_pat_b8(SV_VL1),
svadd_z(svptrue_b8 (), svdup_s8(g), 0));
}
$ aarch64-linux-gnu-gcc -c -Os test.cc -march=armv8.2-a+sve
test.cc: In function ‘void d(char, bool, short int, int, int, char, int, short
int, unsigned int)’:
test.cc:10:1: error: unable to generate reloads for:
10 | }
| ^
(insn 39 89 40 5 (set (reg:VNx16QI 121 [ _5 ])
(unspec:VNx16QI [
(reg:VNx16BI 119)
(vec_duplicate:VNx16QI (mem/c:QI (plus:DI (reg/f:DI 65 ap)
(const_int 64 [0x40])) [1 g+0 S1 A128]))
(const_vector:VNx16QI [
(const_int 0 [0])
])
] UNSPEC_SEL)) "test.cc":8:15 4782 {sve_ld1rvnx16qi}
(expr_list:REG_DEAD (reg:VNx16BI 119)
(nil)))
during RTL pass: reload
test.cc:10:1: internal compiler error: in curr_insn_transform, at
lra-constraints.c:4133
[Bug tree-optimization/99788] missed optimization for dead code elimination at -O3 (vs. -O1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99788 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Honza? (why do we inline into cold main()?)
[Bug tree-optimization/99788] missed optimization for dead code elimination at -O3 (vs. -O1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99788 Richard Biener changed: What|Removed |Added Last reconfirmed||2021-03-26 Version|unknown |11.0 Component|ipa |tree-optimization Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- Confirmed. The issue is that at -O3 we inline e() and while inside e() we eliminate the call to foo since the preceeding for() loop does not terminate (CCP figures this out), the inline copy has the loop header PHI not simplified at the point CCP runs (and it doesn't run later again): [local count: 43379093]: a = 1; a.3_4 = a; [local count: 350976297]: # a.3_3 = PHI a.2_6 = (unsigned char) a.3_3; _7 = a.2_6 + 2; _8 = (char) _7; a = _8; a.3_5 = a; if (a.3_5 != 0) goto ; [87.64%] else goto ; [12.36%] [local count: 43379093]: foo (); vs. [local count: 955630225]: # a.3_22 = PHI <_3(3), 1(2)> a.2_1 = (unsigned char) a.3_22; _2 = a.2_1 + 2; _3 = (char) _2; a = _3; if (_3 != 0) goto ; [89.00%] else goto ; [11.00%] [local count: 118111600]: foo (); and the difference starts with loop header copying which is applied to the outline but not the inline copy of the loop. Analyzing loop 1 Loop 1 is not do-while loop: latch is not empty. Will duplicate bb 4 Not duplicating bb 3: it is single succ. Duplicating header of the loop 1 up to edge 4->3, 3 insns. Loop 1 is do-while loop Loop 1 is now do-while loop. vs. Analyzing loop 1 Analyzing loop 2 Loop 2 is not do-while loop: latch is not empty. Not duplicating bb 5: optimizing for size. where the decision on optimizing for size is because this is main(). Renaming main() to baz() fixes the issue. But I wonder why we inline e() into cold main at all. Honza? I see Processing frequency f/9 Called by main/11 that is normal or hot t.c:24:3: note: Inlining f/9 to main/11 with frequency 1.00 so here main() is normal or hot but loop header copying sees optimize_loop_for_size_p () == true!? IPA inlining sees Considering d/10 with 20 size to be inlined into main/11 in t.c:17 Estimated badness is -0.46, frequency 0.00. Badness calculation for main/11 -> d/10 size growth 16, time 8428.908463 unspec 8428.908463 -0.11: guessed profile. frequency 0.000400, count -1 caller count -1 time saved 0.004400 overall growth -4 (current) -4 (original) -4 (compensated) Adjusted by hints -0.46 Updated mod-ref summary for main/11 loads: Limits: 32 bases, 16 refs Every base stores: Limits: 32 bases, 16 refs Accounting size:17.00, time:2.97 on predicate exec:(true) Processing frequency d/10 Called by main/11 that is executed once Processing frequency e/13 Called by d/10 that is executed once Node e/13 promoted to executed once. Accounting size:-2.00, time:-0.00 on predicate exec:(true) Accounting size:1.00, time:0.40 on predicate exec:(true) t.c:17:5: optimized: Inlined d/10 into main/11 which now has time 8.370758 and size 24, net change of -4. so something is off with how we process speed/size optimization. Note it looks like the loop copy in main gets cold also because it is predicated by if (b) which is predicted as very cold: [local count: 1073741824]: b.0_2 = b; if (b.0_2 != 0) goto ; [0.04%] else goto ; [99.96%] [local count: 429496]: [local count: 43379093]: a = 1; goto ; [100.00%] [local count: 350976297]: a.2_6 = (unsigned char) a.3_5; _7 = a.2_6 + 2; _8 = (char) _7; a = _8; [local count: 394355390]: a.3_5 = a; if (a.3_5 != 0) goto ; [89.00%] else goto ; [11.00%] still when the function is not called main() we're not getting the optimize_loop_for_size () predicate evaluated to true (with the exact same local profile as above!).
[Bug target/99773] ARM v8.1-m MVE interaction with -mfloat-abi not clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773
--- Comment #4 from Richard Earnshaw ---
(In reply to Christophe Lyon from comment #3)
> I tried changing TARGET_HARD_FLOAT_SUB in arm.h to:
> #define TARGET_HARD_FLOAT_SUB (arm_float_abi != ARM_FLOAT_ABI_SOFT\
> && (bitmap_bit_p (arm_active_target.isa, \
> isa_bit_vfpv2) \
> || bitmap_bit_p (arm_active_target.isa, \
> isa_bit_mve)) \
> && TARGET_32BIT)
>
> but that has other implications, like enabing VFP patterns: for instance
> mulsf3_vfp becomes enabled, leading to a failure when builing libgcc
> (vmul.f32 is generated for powisf2, but rejected by the assembler)
>
> So maybe we just change the condition to emit the attributes in
> arm_file_start?
>
> Something like:
> if (! TARGET_SOFT_FLOAT || TARGET_HAVE_MVE)
> {
> if ((TARGET_HARD_FLOAT && TARGET_VFP_SINGLE) || TARGET_HAVE_MVE)
> arm_emit_eabi_attribute ("Tag_ABI_HardFP_use", 27, 1);
>
> if (TARGET_HARD_FLOAT_ABI || TARGET_HAVE_MVE)
> arm_emit_eabi_attribute ("Tag_ABI_VFP_args", 28, 1);
> }
>
It doesn't look right, either. Why would you want to set Tag_ABI_HardFP_use to
1 when there's no single-precision only FPU present?
Untested, but I think something like
if (TARGET_HARD_FLOAT && TARGET_VFP_SINGLE)
arm_emit_eabi_attribute ("Tag_ABI_HardFP_use", 27, 1);
if (TARGET_HARD_FLOAT_ABI)
arm_emit_eabi_attribute ("Tag_ABI_VFP_args", 28, 1);
is probably the right solution, removing the ! TARGET_SOFT_FLOAT entirely.
[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447 Richard Biener changed: What|Removed |Added Resolution|WORKSFORME |--- Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Keywords||lto Component|lto |ipa Priority|P3 |P1 Status|RESOLVED|ASSIGNED --- Comment #14 from Richard Biener --- (In reply to Matthias Klose from comment #13) > rechecked with trunk 20210321, and gcc-10 branch. I can't reproduce this > anymore. That's just bad luck. The issue needs resolving and analysis has identified two things we can improve (cgraph edges & SSA name def stmts).
[Bug ipa/99785] Awful lot of time spent building gl.cc in Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99785 --- Comment #13 from Richard Biener --- On trunk (with release checking) at -O2 the situation is not different from -O1 or the GCC 10 branch (so it's not 4 hours), the profile looks the same as well.
[Bug target/99719] ICE during RTL pass: pro_and_epilogue on MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99719 --- Comment #8 from cqwrteur --- (In reply to cqwrteur from comment #7) > (In reply to Eric Botcazou from comment #6) > > > However, it looks like swapping to ms_abi from sysv_abi will cleanup SIMD > > > registers. Is that correct? > > > > Fiddling with the ABI is highly discouraged in anything else than very > > low-level code, so templatized C++ very likely does not qualify. > > the issue is that on MSVC abi, types like std::string_view, std::span are > passed by reference instead of passing them in the registers. (since they > are 16 bytes). > > I do not know whether we have a solution to pass them in registers > temporarily for some functions. That means std::string_view/std::span is not zero-overhead. They are extremely slow.
[Bug target/99719] ICE during RTL pass: pro_and_epilogue on MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99719 --- Comment #7 from cqwrteur --- (In reply to Eric Botcazou from comment #6) > > However, it looks like swapping to ms_abi from sysv_abi will cleanup SIMD > > registers. Is that correct? > > Fiddling with the ABI is highly discouraged in anything else than very > low-level code, so templatized C++ very likely does not qualify. the issue is that on MSVC abi, types like std::string_view, std::span are passed by reference instead of passing them in the registers. (since they are 16 bytes). I do not know whether we have a solution to pass them in registers temporarily for some functions.
[Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447 Matthias Klose changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME CC||doko at gcc dot gnu.org --- Comment #13 from Matthias Klose --- rechecked with trunk 20210321, and gcc-10 branch. I can't reproduce this anymore.
[Bug tree-optimization/99777] [11 Regression] ICE in build2, at tree.c:4869 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99777
--- Comment #3 from Jakub Jelinek ---
So, one thing is that tree-affine.c during store motion alias analysis feeds
very questionable expressions to the folder, in particular it attempts to fold
MULT_EXPR of (sizetype) (vector(4) short int *) ((int) ivtmp.46_14 * 3)
where ivtmp.46_14 is unsigned int, and (sizetype) -1.
Note e.g. the cast from int to pointer of different size, or pointer back to
sizetype.
And another thing is that extract_muldiv{,_1} really relies on integral types
only, is called when the divisor or second multiplication operand is
INTEGER_CST and the multiplication/division aren't defined for other types that
represent
constants as INTEGER_CST (e.g. pointers, NULLPTR_TYPE etc.). Vector types
really should use VECTOR_CSTs...
The ICE can be fixed with:
--- gcc/fold-const.c.jj 2021-03-25 13:41:55.0 +0100
+++ gcc/fold-const.c2021-03-26 11:51:57.901091895 +0100
@@ -6713,6 +6713,8 @@ extract_muldiv_1 (tree t, tree c, enum t
break;
CASE_CONVERT: case NON_LVALUE_EXPR:
+ if (!INTEGRAL_TYPE_P (TREE_TYPE (op0)))
+ break;
/* If op0 is an expression ... */
if ((COMPARISON_CLASS_P (op0)
|| UNARY_CLASS_P (op0)
@@ -6721,8 +6723,7 @@ extract_muldiv_1 (tree t, tree c, enum t
|| EXPRESSION_CLASS_P (op0))
/* ... and has wrapping overflow, and its type is smaller
than ctype, then we cannot pass through as widening. */
- && (((ANY_INTEGRAL_TYPE_P (TREE_TYPE (op0))
- && TYPE_OVERFLOW_WRAPS (TREE_TYPE (op0)))
+ && ((TYPE_OVERFLOW_WRAPS (TREE_TYPE (op0))
&& (TYPE_PRECISION (ctype)
> TYPE_PRECISION (TREE_TYPE (op0
/* ... or this is a truncation (t is narrower than op0),
@@ -6737,8 +6738,7 @@ extract_muldiv_1 (tree t, tree c, enum t
/* ... or has undefined overflow while the converted to
type has not, we cannot do the operation in the inner type
as that would introduce undefined overflow. */
- || ((ANY_INTEGRAL_TYPE_P (TREE_TYPE (op0))
- && TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (op0)))
+ || (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (op0))
&& !TYPE_OVERFLOW_UNDEFINED (type
break;
[Bug ipa/99788] New: missed optimization for dead code elimination at -O3 (vs. -O1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99788
Bug ID: 99788
Summary: missed optimization for dead code elimination at -O3
(vs. -O1)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
CC: marxin at gcc dot gnu.org
Target Milestone: ---
[606] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210326 (experimental) [master revision
9d45e848d02:ca344bbd24f:6081d8994ed1a0aef6b7f5fb34f091faa3580416] (GCC)
[607] %
[607] % gcctk -O1 -S -o O1.s small.c
[608] % gcctk -O3 -S -o O3.s small.c
[609] %
[609] % wc O1.s O3.s
79 162 986 O1.s
109 229 1433 O3.s
188 391 2419 total
[610] %
[610] % grep foo O1.s
[611] % grep foo O3.s
callfoo
[612] %
[612] % cat small.c
extern void foo(void);
char a;
int b, *c, g, h = 1, i = 1, j, *k =
static void d();
static int *e() {
for (a = 1; a; a = a+2)
;
foo();
h = (g % h) % i;
*k = -j;
return 0;
}
static void f() {
if (b)
d(e);
}
void d() {
for (;;)
c = e();
}
int main() {
f();
return 0;
}
[Bug target/99786] [11 Regression] ICE in in extract_insn, at recog.c:2770 since r11-4199-g0f41b5e02fa47db2080b77e4e1f7cd3305457c05
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99786 --- Comment #2 from Christophe Lyon --- This fixes the ICE: diff --git a/gcc/config/arm/vec-common.md b/gcc/config/arm/vec-common.md index 48ee659..86563d9 100644 --- a/gcc/config/arm/vec-common.md +++ b/gcc/config/arm/vec-common.md @@ -103,7 +103,7 @@ (define_expand "mul3" [(set (match_operand:VDQWH 0 "s_register_operand") (mult:VDQWH (match_operand:VDQWH 1 "s_register_operand") (match_operand:VDQWH 2 "s_register_operand")))] - "ARM_HAVE__ARITH" + "ARM_HAVE__ARITH && (!TARGET_REALLY_IWMMXT || mode == V4HImode)" ) However, I am getting errors from the assembler: pr79904.s:29: Error: selected processor does not support `wldrd wr0,[r3]' in ARM mode pr79904.s:30: Error: selected processor does not support `wldrd wr2,.L2' in ARM mode pr79904.s:31: Error: selected processor does not support `wmulul wr0,wr0,wr2' in ARM mode pr79904.s:33: Error: selected processor does not support `wstrd wr0,[r3]' in ARM mode I am compiling with arm-eabi-gcc -mcpu=iwmmxt. These errors are unrelated to the PR, but I am wondering why they appear?
[Bug ipa/99785] Awful lot of time spent building gl.cc in Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99785 --- Comment #12 from Richard Biener --- (In reply to Richard Biener from comment #11) > Btw, GCC 10 branch tip with -O1: > > ipa inlining heuristics: 962.91 ( 85%) 0.39 ( 4%) 971.66 ( > 84%) 1103801 kB ( 10%) > alias stmt walking : 40.95 ( 4%) 1.07 ( 11%) 42.13 ( > 4%) 25965 kB ( 0%) > integration: 13.66 ( 1%) 3.23 ( 33%) 16.18 ( > 1%) 4931059 kB ( 43%) > TOTAL :1135.79 9.69 1153.79 > 11462287 kB > 1135.79user 9.73system 19:13.82elapsed 99%CPU (0avgtext+0avgdata > 4090216maxresident)k > 0inputs+0outputs (0major+959014minor)pagefaults 0swaps And a profile of trunk with release checking shows Samples: 4M of event 'cycles:u', Event count (approx.): 4811472248176 Overhead Samples Command Shared Object Symbol 31.07% 1371974 cc1plus cc1plus [.] update_callee_keys 25.52% 1128500 cc1plus cc1plus [.] edge_badness 4.91%216874 cc1plus cc1plus [.] evaluate_properties_for_edge 3.90%172368 cc1plus cc1plus [.] cgraph_node::get_availability 3.83%169169 cc1plus cc1plus [.] do_estimate_edge_time 2.56%113399 cc1plus cc1plus [.] symtab_node::ultimate_alias_target_1 I wonder why we even run into this for the always inlines.
[Bug target/99780] ICE in verify_curr_properties, at passes.c:2152
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99780 Martin Liška changed: What|Removed |Added Target Milestone|--- |12.0
[Bug target/99780] ICE in verify_curr_properties, at passes.c:2152
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99780
--- Comment #4 from Martin Liška ---
verify_curr_properties fails because is targetclone pass requires:
const pass_data pass_data_target_clone =
{
SIMPLE_IPA_PASS, /* type */
"targetclone",/* name */
OPTGROUP_NONE,/* optinfo_flags */
TV_NONE, /* tv_id */
( PROP_ssa | PROP_cfg ), /* properties_required */
0,/* properties_provided */
0,/* properties_destroyed */
0,/* todo_flags_start */
TODO_update_ssa /* todo_flags_finish */
};
but the property PROP_ssa is missing. Likely due to the error.
[Bug target/99786] [11 Regression] ICE in in extract_insn, at recog.c:2770 since r11-4199-g0f41b5e02fa47db2080b77e4e1f7cd3305457c05
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99786 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #1 from Christophe Lyon --- Looks like a similar problem to PR99724 and PR98849. IIUC, iwmmxt only supports mult:V4HI (see mulv4hi3_iwmmxt in iwmmxt.md), so the condition ARM_HAVE__ARITH on define_expand "mul3" in vec-common.md is not strict enough.
[Bug target/99786] [11 Regression] ICE in in extract_insn, at recog.c:2770 since r11-4199-g0f41b5e02fa47db2080b77e4e1f7cd3305457c05
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99786 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 Priority|P3 |P1
[Bug target/99787] [11 Regression] ICE in curr_insn_transform, at lra-constraints.c:4133 since r11-7807-gbe70bb5e4babdf9d3d33e8f4658452038407fa8e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99787 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/94212] [8/9/10/11 Regression] Incorrect vectorization of loop with FP calculations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94212
--- Comment #11 from rguenther at suse dot de ---
On Fri, 26 Mar 2021, qianjh at cn dot fujitsu.com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94212
>
> Qian Jianhua changed:
>
>What|Removed |Added
>
> CC||qianjh at cn dot fujitsu.com
>
> --- Comment #10 from Qian Jianhua ---
> I simplified the testcase as below.
> --
> #include
>
> #define POLY(arg) (1.0d - 2.0d * arg + 3.0d * arg * arg - 4.0 * arg * arg *
> arg)
> double v[2]={106.0d,108.0d};
>
> int main(int argc, char** argv) {
> double res = 0.0d;
> res = v[1]*POLY(v[0]);
> printf("RESULT:%lf\n", res);
> return 0;;
> }
> --
>
> The result is also different with/without -ffp-contract=off.
> Assembly has no problem.
>
> So I think there are differences in FP accuracy between mul+add and fmadd.
> They are not equivalent for some specific numbers.
Of course they are not. fmadd elides the intermediate rounding step
of the multiplication. The result can differ in 1ulp
