[Bug tree-optimization/97980] wrong code with "-O3 -fno-dce -fno-inline-functions-called-once -fno-inline-small-functions -fno-tree-ccp -fno-tree-dce -fno-tree-vrp"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97980 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Component|c |tree-optimization --- Comment #1 from Andrew Pinski --- I think it is due to -fno-tree-dce .
[Bug c/97972] [9/10/11 Regression] ICE in moving_insn_creates_bookkeeping_block_p, at sel-sched.c:2031 since r9-2064-gc4c5ad1d6d1e1e1f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97972 Martin Liška changed: What|Removed |Added Summary|[10/11 Regression] ICE in |[9/10/11 Regression] ICE in |moving_insn_creates_bookkee |moving_insn_creates_bookkee |ping_block_p, at|ping_block_p, at |sel-sched.c:2031|sel-sched.c:2031 since ||r9-2064-gc4c5ad1d6d1e1e1f Target Milestone|--- |8.5 Last reconfirmed||2020-11-25 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org, ||segher at gcc dot gnu.org --- Comment #1 from Martin Liška --- With -fno-common it started with r9-2064-gc4c5ad1d6d1e1e1f.
[Bug c++/97973] [10/11 Regression] ICE in tsubst_copy_and_build, at cp/pt.c:19577 since r10-6170-g8a990ffafaaa1898
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97973 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-11-25 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org, ||msebor at gcc dot gnu.org Summary|[10/11 Regression] ICE in |[10/11 Regression] ICE in |tsubst_copy_and_build, at |tsubst_copy_and_build, at |cp/pt.c:19577 |cp/pt.c:19577 since ||r10-6170-g8a990ffafaaa1898 --- Comment #1 from Martin Liška --- Started to ICE with r10-6170-g8a990ffafaaa1898.
[Bug c++/97974] [9/10/11 Regression] ICE tree check: expected overload, have function_decl in get_class_binding_direct, at cp/name-lookup.c:1332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97974 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-11-25 CC||marxin at gcc dot gnu.org, ||nathan at gcc dot gnu.org --- Comment #1 from Martin Liška --- Started to ICE with r8-7029-g35129fd3a745403b.
[Bug c++/97975] ICE unexpected expression '(int)A< >::b' of kind implicit_conv_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97975 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org Last reconfirmed||2020-11-25 --- Comment #1 from Martin Liška --- At least as old as 4.8.0.
[Bug rtl-optimization/97978] [11 Regression] ICE in lra_assign, at lra-assigns.c:1648 since r11-5066-gbe39636d9f68c437
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97978 Martin Liška changed: What|Removed |Added Known to work||10.2.0 Target Milestone|--- |11.0 CC||marxin at gcc dot gnu.org, ||roger at nextmovesoftware dot com Last reconfirmed||2020-11-25 Known to fail||11.0 Summary|[11 Regression] ICE in |[11 Regression] ICE in |lra_assign, at |lra_assign, at |lra-assigns.c:1648 |lra-assigns.c:1648 since ||r11-5066-gbe39636d9f68c437 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Priority|P3 |P1 --- Comment #1 from Martin Liška --- Started with r11-5066-gbe39636d9f68c437.
[Bug tree-optimization/97979] [11 Regression]: Segmentation fault with "-O3 -fno-toplevel-reorder -fno-tree-ccp" since r11-5271-g4866b2f5db117f9e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97979 Martin Liška changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Known to work||10.2.0 Last reconfirmed||2020-11-25 Target Milestone|--- |11.0 CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Summary|internal compiler error:|[11 Regression]: |Segmentation fault with |Segmentation fault with |"-O3 -fno-toplevel-reorder |"-O3 -fno-toplevel-reorder |-fno-tree-ccp" |-fno-tree-ccp" since ||r11-5271-g4866b2f5db117f9e Known to fail||11.0 --- Comment #1 from Martin Liška --- Started with r11-5271-g4866b2f5db117f9e.
[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969 Richard Biener changed: What|Removed |Added Component|c |target Keywords||compile-time-hog Priority|P3 |P2 Target Milestone|--- |9.4
[Bug tree-optimization/97980] wrong code with "-O3 -fno-dce -fno-inline-functions-called-once -fno-inline-small-functions -fno-tree-ccp -fno-tree-dce -fno-tree-vrp" since r10-3311-gff6686d2e5f797d6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97980 Martin Liška changed: What|Removed |Added Known to fail||10.2.0, 11.0 Known to work||9.3.0 Last reconfirmed||2020-11-25 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Target Milestone|--- |10.3 CC||jamborm at gcc dot gnu.org, ||marxin at gcc dot gnu.org Summary|wrong code with "-O3|wrong code with "-O3 |-fno-dce|-fno-dce |-fno-inline-functions-calle |-fno-inline-functions-calle |d-once |d-once |-fno-inline-small-functions |-fno-inline-small-functions |-fno-tree-ccp -fno-tree-dce |-fno-tree-ccp -fno-tree-dce |-fno-tree-vrp" |-fno-tree-vrp" since ||r10-3311-gff6686d2e5f797d6 --- Comment #2 from Martin Liška --- Started with r10-3311-gff6686d2e5f797d6.
[Bug tree-optimization/97970] [11 regression] 'gcc.dg/gomp/pr82374.c scan-tree-dump-times vect "vectorized 1 loops" 2' for 32-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97970 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Target Milestone|--- |11.0 --- Comment #3 from Richard Biener --- Fixed.
[Bug c/97971] [9/10/11 Regression] ICE in process_alt_operands, at lra-constraints.c:3110
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97971 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.4 Keywords||diagnostic
[Bug rtl-optimization/97972] [9/10/11 Regression] ICE in moving_insn_creates_bookkeeping_block_p, at sel-sched.c:2031 since r9-2064-gc4c5ad1d6d1e1e1f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97972 Richard Biener changed: What|Removed |Added Target Milestone|8.5 |9.4 Component|c |rtl-optimization CC||amonakov at gcc dot gnu.org
[Bug c++/97973] [10/11 Regression] ICE in tsubst_copy_and_build, at cp/pt.c:19577 since r10-6170-g8a990ffafaaa1898
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97973 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.3 Priority|P3 |P2
[Bug c++/97974] [9/10/11 Regression] ICE tree check: expected overload, have function_decl in get_class_binding_direct, at cp/name-lookup.c:1332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97974 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |9.4
[Bug gcov-profile/93680] [GCOV] "do-while" structure in case statement leads to incorrect code coverage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93680 Sunil Kumar changed: What|Removed |Added CC||sunil.kumar3 at ltts dot com --- Comment #2 from Sunil Kumar --- I have executed same code in gcc 7.4.0 and i do not see the same behaviour. The case labels are properly marked as executed 5 times. please can you confirm this behaviour. And also the issues which are open items in gcov bugzilla list and reported in later gcc 7.4.0 version will those are applicable to gcc 7.4.0 ?
[Bug c++/97976] Optimization relating to NULL pointer assumptions in gcc 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97976 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Richard Biener --- For containsBackwards we know it must return 1 unless p is NULL at the beginning, for findBackwards we still need to compute where and for that the loop has to be retained.
[Bug tree-optimization/97979] [11 Regression]: Segmentation fault with "-O3 -fno-toplevel-reorder -fno-tree-ccp" since r11-5271-g4866b2f5db117f9e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97979
--- Comment #2 from Richard Biener ---
/* Fold (X {&,^,|} C2) << C1 into (X << C1) {&,^,|} (C2 << C1)
(X {&,^,|} C2) >> C1 into (X >> C1) & (C2 >> C1). */
(for shift (lshift rshift)
(for bit_op (bit_and bit_xor bit_ior)
(simplify
(shift (convert?:s (bit_op:s @0 INTEGER_CST@2)) INTEGER_CST@1)
(if (tree_nop_conversion_p (type, TREE_TYPE (@0)))
(with { tree mask = int_const_binop (shift, fold_convert (type, @2), @1); }
(bit_op (shift (convert @0) @1) { mask; }))
and mask ends up NULL.
tree mask = int_const_binop (shift, fold_convert (type, captures[3]),
captures[4]);
(gdb) p debug_tree (captures[3])
constant
65535>
(gdb) p debug_tree (captures[4])
constant 4294967294>
(gdb) p debug_tree (type)
[Bug tree-optimization/97980] [10/11 Regression] wrong code with "-O3 -fno-dce -fno-inline-functions-called-once -fno-inline-small-functions -fno-tree-ccp -fno-tree-dce -fno-tree-vrp" since r10-3311-g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97980 Richard Biener changed: What|Removed |Added Summary|wrong code with "-O3|[10/11 Regression] wrong |-fno-dce|code with "-O3 -fno-dce |-fno-inline-functions-calle |-fno-inline-functions-calle |d-once |d-once |-fno-inline-small-functions |-fno-inline-small-functions |-fno-tree-ccp -fno-tree-dce |-fno-tree-ccp -fno-tree-dce |-fno-tree-vrp" since|-fno-tree-vrp" since |r10-3311-gff6686d2e5f797d6 |r10-3311-gff6686d2e5f797d6 Priority|P3 |P2
[Bug target/97981] [11 regression] 32-bit x86 'gcc.dg/atomic/c11-atomic-exec-1.c' execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97981 Richard Biener changed: What|Removed |Added Keywords||needs-bisection, wrong-code Status|UNCONFIRMED |NEW Target||i?86-*-* Target Milestone|--- |11.0 Last reconfirmed||2020-11-25 Component|regression |target Priority|P3 |P1 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- IIRC I've also seen this.
[Bug bootstrap/57076] @ in the src directory name causes failure while building of gcc.info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57076 Francois-Xavier Coudert changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |11.0 --- Comment #9 from Francois-Xavier Coudert --- Fixed indeed
[Bug c++/97962] ICE in build_over_call, at cp/call.c:8976
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97962 Martin Liška changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Started to ICE with r7-3599-g36cbfdb06604b63e, it was rejected before that.
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #13 from Chris Clayton --- (In reply to Martin Liška from comment #9) > Ok, so the question is: does it reproduce with the current master or now? Short answer: Yes, it does. A build done this morning (after pulling the latest changes into the tree I cloned yesterday) fails with the same ICE error messages.
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #14 from Martin Liška --- Thank you Chris, I can really confirm that. Working on that..
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 Martin Liška changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org
[Bug c/97982] New: integer casting after abs() causes undefined behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97982
Bug ID: 97982
Summary: integer casting after abs() causes undefined behavior
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mytbk920423 at gmail dot com
Target Milestone: ---
The following code has different result when compiling with -O0/-O1 and -O2.
Also, ubsan will report an error. But I don't know why the
signed(INT_MIN)->unsigned data conversion is undefined. It's found in GCC
10.2.0 and 4.8.5.
clang does fine with both -O0 and -O2 and reports no ubsan errors.
#include
#include
#include
int main()
{
char str[20];
scanf("%s", str);
int32_t x = strtol(str, NULL, 0);
uint32_t u = abs(x); // x=0x8000 will trigger an undefined behavior
uint64_t val = u;
printf("0x%lx\n", val);
}
[Bug middle-end/97943] [11 Regression] ICE with __builtin_clear_padding on flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97943 --- Comment #8 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a7285c8659689e9ade53fcb996b26d874455a4f3 commit r11-5329-ga7285c8659689e9ade53fcb996b26d874455a4f3 Author: Jakub Jelinek Date: Wed Nov 25 10:37:58 2020 +0100 middle-end: Reject flexible array members in __builtin_clear_padding [PR97943] As mentioned in the PR, we currently ICE on flexible array members in structs and unions during __builtin_clear_padding processing. Jason said in the PR he'd prefer an error in these cases over forcefully handling it as [0] arrays (everything is padding then) or consider the arrays to have as many whole elements as would fit into the tail padding. So, this patch implements that. 2020-11-25 Jakub Jelinek PR middle-end/97943 * gimple-fold.c (clear_padding_union, clear_padding_type): Error on and ignore flexible array member fields. Ignore fields with error_mark_node type. * c-c++-common/builtin-clear-padding-2.c: New test. * c-c++-common/builtin-clear-padding-3.c: New test. * g++.dg/ext/builtin-clear-padding-1.C: New test. * gcc.dg/builtin-clear-padding-2.c: New test.
[Bug middle-end/97943] [11 Regression] ICE with __builtin_clear_padding on flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97943 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from Jakub Jelinek --- Fixed.
[Bug c/97982] integer casting after abs() causes undefined behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97982 --- Comment #1 from Iru Cai --- Hmm, I saw in the abs(3) that "Trying to take the absolute value of the most negative integer is not defined." But it's still strange to see a uint32->uint64_t cast results in a negative value.
[Bug c/97982] integer casting after abs() causes undefined behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97982 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andreas Schwab --- Undefined behaviour means anything can happen.
[Bug libstdc++/97936] [11 Regression] 30_threads/latch/3.cc hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97936 --- Comment #6 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ad9cbcee543ecccd79fa49dafcd925532d2ce210 commit r11-5330-gad9cbcee543ecccd79fa49dafcd925532d2ce210 Author: Jonathan Wakely Date: Wed Nov 25 10:26:09 2020 + libstdc++: Fix handling of futex wake [PR 97936] The __platform_wait function is supposed to wait until *addr != old. The futex syscall checks the initial value and returns EAGAIN if *addr != old is already true, which should cause __platform_wait to return. Instead it loops and keeps doing a futex wait, which keeps returning EAGAIN. libstdc++-v3/ChangeLog: PR libstdc++/97936 * include/bits/atomic_wait.h (__platform_wait): Return if futex sets EAGAIN. * testsuite/30_threads/latch/3.cc: Re-enable test. * testsuite/30_threads/semaphore/try_acquire_until.cc: Likewise.
[Bug target/94791] aarch64: -pg profiling is broken with pac-ret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94791 --- Comment #5 from CVS Commits --- The releases/gcc-8 branch has been updated by Szabolcs Nagy : https://gcc.gnu.org/g:d4fcc365700f94fd15c67b30a3051aeabbb767bc commit r8-10641-gd4fcc365700f94fd15c67b30a3051aeabbb767bc Author: Szabolcs Nagy Date: Tue Jun 2 16:44:41 2020 +0100 aarch64: fix return address access with pac [PR94891][PR94791] This is a big hammer fix for __builtin_return_address (PR target/94891) returning signed addresses (sometimes, depending on wether lr happens to be signed or not at the time of call which depends on optimizations), and similarly -pg may pass signed return address to _mcount (PR target/94791). At the time of return address expansion we don't know if it's signed or not so it is done unconditionally. 2020-07-13 Szabolcs Nagy gcc/ChangeLog: PR target/94891 PR target/94791 * config/aarch64/aarch64-protos.h (aarch64_return_addr_rtx): Declare. * config/aarch64/aarch64.c (aarch64_return_addr_rtx): New. (aarch64_return_addr): Use aarch64_return_addr_rtx. * config/aarch64/aarch64.h (PROFILE_HOOK): Likewise. (cherry picked from commit 463a54e5d4956143f81c1f23b91cbd2d93855741)
[Bug target/94891] aarch64: there is no way to strip PAC from a return address in c code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94891 --- Comment #14 from CVS Commits --- The releases/gcc-8 branch has been updated by Szabolcs Nagy : https://gcc.gnu.org/g:d4fcc365700f94fd15c67b30a3051aeabbb767bc commit r8-10641-gd4fcc365700f94fd15c67b30a3051aeabbb767bc Author: Szabolcs Nagy Date: Tue Jun 2 16:44:41 2020 +0100 aarch64: fix return address access with pac [PR94891][PR94791] This is a big hammer fix for __builtin_return_address (PR target/94891) returning signed addresses (sometimes, depending on wether lr happens to be signed or not at the time of call which depends on optimizations), and similarly -pg may pass signed return address to _mcount (PR target/94791). At the time of return address expansion we don't know if it's signed or not so it is done unconditionally. 2020-07-13 Szabolcs Nagy gcc/ChangeLog: PR target/94891 PR target/94791 * config/aarch64/aarch64-protos.h (aarch64_return_addr_rtx): Declare. * config/aarch64/aarch64.c (aarch64_return_addr_rtx): New. (aarch64_return_addr): Use aarch64_return_addr_rtx. * config/aarch64/aarch64.h (PROFILE_HOOK): Likewise. (cherry picked from commit 463a54e5d4956143f81c1f23b91cbd2d93855741)
[Bug target/94891] aarch64: there is no way to strip PAC from a return address in c code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94891 --- Comment #15 from CVS Commits --- The releases/gcc-8 branch has been updated by Szabolcs Nagy : https://gcc.gnu.org/g:de7352725acf209ebb3e4c647cd35e176062231a commit r8-10642-gde7352725acf209ebb3e4c647cd35e176062231a Author: Szabolcs Nagy Date: Thu Jun 4 13:42:16 2020 +0100 aarch64: fix __builtin_eh_return with pac-ret [PR94891] Currently __builtin_eh_return takes a signed return address, which can cause ABI and API issues: 1) pointer representation problems if the address is passed around before eh return, 2) the source code needs pac-ret specific changes and needs to know if pac-ret is used in the current frame, 3) signed address may not be representible as void * (with ilp32 abi). Using address signing to protect eh return is ineffective because the instruction sequence in the unwinder that starts from the address signing and ends with a ret can be used as a return to anywhere gadget. Using indirect branch istead of ret with bti j landing pads at the target can reduce the potential of such gadget, which also implies that __builtin_eh_return should not take a signed address. This is a big hammer fix to the ABI and API issues: it turns pac-ret off for the caller completely (not just on the eh return path). To harden the caller against ROP attacks, it should use indirect branch instead of ret, this is not attempted so the patch remains small and backportable. 2020-07-13 Szabolcs Nagy gcc/ChangeLog: PR target/94891 * config/aarch64/aarch64.c (aarch64_return_address_signing_enabled): Disable return address signing if __builtin_eh_return is used. gcc/testsuite/ChangeLog: PR target/94891 * gcc.target/aarch64/return_address_sign_1.c: Update test. (cherry picked from commit 2bc95be3bb8c8138e2e87c1c11c84bfede989d61)
[Bug target/94891] aarch64: there is no way to strip PAC from a return address in c code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94891 --- Comment #16 from CVS Commits --- The releases/gcc-8 branch has been updated by Szabolcs Nagy : https://gcc.gnu.org/g:d5f58a0287d2bc4c0a84bf63cade069744ce3185 commit r8-10643-gd5f58a0287d2bc4c0a84bf63cade069744ce3185 Author: Szabolcs Nagy Date: Thu Jun 4 09:33:35 2020 +0100 libgcc: fix the handling of return address mangling [PR94891] Mangling, currently only used on AArch64 for return address signing, is an internal representation that should not be exposed via __builtin_return_address return value, __builtin_eh_return handler argument, _Unwind_DebugHook handler argument. Note that a mangled address might not even fit into a void *, e.g. with AArch64 ilp32 ABI the return address is stored as 64bit, so the mangled return address cannot be accessed via _Unwind_GetPtr. This patch changes the unwinder hooks as follows: MD_POST_EXTRACT_ROOT_ADDR is removed: root address comes from __builtin_return_address which is not mangled. MD_POST_EXTRACT_FRAME_ADDR is renamed to MD_DEMANGLE_RETURN_ADDR, it now operates on _Unwind_Word instead of void *, so the hook should work when return address signing is enabled on AArch64 ilp32. (But for that __builtin_aarch64_autia1716 should be fixed to operate on 64bit input instead of a void *.) MD_POST_FROB_EH_HANDLER_ADDR is removed: it is the responsibility of __builtin_eh_return to do the mangling if necessary. 2020-07-13 Szabolcs Nagy libgcc/ChangeLog: PR target/94891 * config/aarch64/aarch64-unwind.h (MD_POST_EXTRACT_ROOT_ADDR): Remove. (MD_POST_FROB_EH_HANDLER_ADDR): Remove. (MD_POST_EXTRACT_FRAME_ADDR): Rename to ... (MD_DEMANGLE_RETURN_ADDR): This. (aarch64_post_extract_frame_addr): Rename to ... (aarch64_demangle_return_addr): This. (aarch64_post_frob_eh_handler_addr): Remove. * unwind-dw2.c (uw_update_context): Demangle return address. (uw_frob_return_addr): Remove. (cherry picked from commit b097c7a27fb0796b2653a1d003cbf6b7a69d8961)
[Bug target/94891] aarch64: there is no way to strip PAC from a return address in c code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94891 --- Comment #17 from CVS Commits --- The releases/gcc-8 branch has been updated by Szabolcs Nagy : https://gcc.gnu.org/g:74bffa9a325f7360dc9d105c2fc5719fe45164d3 commit r8-10644-g74bffa9a325f7360dc9d105c2fc5719fe45164d3 Author: Szabolcs Nagy Date: Thu May 28 10:28:30 2020 +0100 doc: Clarify __builtin_return_address [PR94891] The expected semantics and valid usage of __builtin_return_address is not clear since it exposes implementation internals that are normally not meaningful to portable c code. This documentation change tries to clarify the semantics in case the return address is stored in a mangled form. This affects AArch64 when pointer authentication is used for the return address signing (i.e. -mbranch-protection=pac-ret). 2020-07-13 Szabolcs Nagy gcc/ChangeLog: PR target/94891 * doc/extend.texi: Update the text for __builtin_return_address. (cherry picked from commit 6a391e06f953c3390b14020d8cacb6d55f81b2b9)
[Bug libstdc++/97936] [11 Regression] 30_threads/latch/3.cc hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97936 --- Comment #7 from Jonathan Wakely --- This one was failing too: WARNING: 30_threads/semaphore/try_acquire_for.cc execution test program timed out. FAIL: 30_threads/semaphore/try_acquire_for.cc execution test I think that should be fixed by r11-5330.
[Bug bootstrap/97983] New: [11 Regression] Bootstrap failure on s390x-linux related to vec-perm-indices.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97983
Bug ID: 97983
Summary: [11 Regression] Bootstrap failure on s390x-linux
related to vec-perm-indices.c
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Non-profiled bootstrap on s390x fails when compiling vec-perm-indices.c.
Can be reproduced in a cross-compiler with
./cc1plus -quiet -nostdinc -mtune=z13 -march=zEC12 -m64 -O2 -fchecking=1
-fno-exceptions -fno-rtti vec-perm-indices.ii
../../gcc/vec-perm-indices.c: In member function ‘void
vec_perm_indices::new_vector(const vec_perm_builder&, unsigned int,
poly_uint64)’:
../../gcc/vec-perm-indices.c:78:1: error: insn 308 outside of basic blocks has
non-NULL bb field
78 | }
| ^
../../gcc/vec-perm-indices.c:78:1: error: verify_flow_info: Incorrect fallthru
6->7
../../gcc/vec-perm-indices.c:78:1: error: wrong insn in the fallthru edge
(insn 308 150 68 7 (set (reg:SI 1 %r1 [orig:157 i ] [157])
(reg:SI 1 %r1 [orig:157 i ] [157])) 1467 {*movsi_zarch}
(nil))
during RTL pass: reload
../../gcc/vec-perm-indices.c:78:1: internal compiler error: in
rtl_verify_fallthru, at cfgrtl.c:2978
0x141e2c9 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/rtl-error.c:108
0xe6637c rtl_verify_fallthru
../../gcc/cfgrtl.c:2978
0xe665f8 rtl_verify_flow_info
../../gcc/cfgrtl.c:3078
0xe4bf2e verify_flow_info()
../../gcc/cfghooks.c:267
0x1fe0b0d checking_verify_flow_info
../../gcc/cfghooks.h:212
0x1fe897f try_optimize_cfg
../../gcc/cfgcleanup.c:3009
0x1fe8de9 cleanup_cfg(int)
../../gcc/cfgcleanup.c:3174
0x120ebc4 do_reload
../../gcc/ira.c:5851
0x120ef38 execute
../../gcc/ira.c:5988
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug bootstrap/97983] [11 Regression] Bootstrap failure on s390x-linux related to vec-perm-indices.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97983 --- Comment #1 from Jakub Jelinek --- Created attachment 49623 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49623&action=edit vec-perm-indices.ii.xz The preprocessed file.
[Bug bootstrap/97983] [11 Regression] Bootstrap failure on s390x-linux related to vec-perm-indices.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97983 Jakub Jelinek changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org Target Milestone|--- |11.0 Priority|P3 |P1
[Bug tree-optimization/97579] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #9 from Richard Biener ---
mask__258.181_254 = vect_cst__77 != { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0 };
mask__581.199_1001 = VEC_COND_EXPR ;
so we're having a VEC_COND_EXPR with vector boolean type, sth we are not
prepared to handle (at least if it's not a classical vector mode one).
if (used_vec_cond_exprs >= 2
&& (get_vcond_mask_icode (mode, TYPE_MODE (op0_type))
!= CODE_FOR_nothing)
&& expand_vec_cmp_expr_p (op0a_type, op0_type, tcode))
{
/* Keep the SSA name and use vcond_mask. */
tcode = TREE_CODE (op0);
}
in the implicit else we assume vcond can handle this, but it will obviously
fail for a non-vector mode.
icode = get_vcond_icode (mode, cmp_op_mode, unsignedp);
where we have mode == HImode and cmp_op_mode V16SImode. I'm not sure aarch64
SVE or riscv will like VNBImode here.
Unless we want to disallow vector boolean typed VEC_COND_EXPRs alltogether
we have to lower them somewhere which probably is in ISEL. For the above
we'd produce
_75 = ~mask__258.181_254;
_897 = mask__649.185_117 & _75;
mask__581.199_1001 = _897;
[Bug tree-optimization/97984] New: [10/11 Regression] Worse code for -O3 than -O2 on aarch64 vector multiply-add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97984
Bug ID: 97984
Summary: [10/11 Regression] Worse code for -O3 than -O2 on
aarch64 vector multiply-add
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
The code:
void x (long * __restrict a, long * __restrict b)
{
a[0] *= b[0];
a[1] *= b[1];
a[0] += b[0];
a[1] += b[1];
}
at -O2 generates:
x:
ldp x4, x3, [x0]
ldp x2, x1, [x1]
maddx2, x2, x4, x2
maddx1, x1, x3, x1
stp x2, x1, [x0]
ret
whereas at -O3 it does:
x:
ldp x2, x3, [x0]
ldr x4, [x1]
ldr q1, [x1]
mul x2, x2, x4
ldr x4, [x1, 8]
fmovd0, x2
ins v0.d[1], x3
mul x1, x3, x4
ins v0.d[1], x1
add v0.2d, v0.2d, v1.2d
str q0, [x0]
ret
which is clearly inferior.
GCC 9 used to generate the good code for both -O2 and -O3
[Bug debug/97599] [8/9/10/11 Regression] missing unspecified_parameters DIE in DWARF for functions with variable arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97599 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:812258b07c1a80e8dc79a0beb3ec0e17be62f5e5 commit r10-9076-g812258b07c1a80e8dc79a0beb3ec0e17be62f5e5 Author: Jakub Jelinek Date: Sat Nov 14 09:14:19 2020 +0100 dwarf2: Emit DW_TAG_unspecified_parameters even in late DWARF [PR97599] Aldy's PR71855 fix avoided emitting multiple redundant DW_TAG_unspecified_parameters sub-DIEs of a single DIE by restricting it to early dwarf only. That unfortunately means if we need to emit another DIE for the function (whether it is for LTO, or e.g. because of IPA cloning), we don't emit DW_TAG_unspecified_parameters, it remains solely in the DW_AT_abstract_origin's referenced DIE. But DWARF consumers don't really use DW_TAG_unspecified_parameters from there, like we duplicate DW_TAG_formal_parameter sub-DIEs even in the clones because either they have some more specific location, or e.g. a function clone could have fewer or different argument types etc., they need to assume that originally stdarg function isn't later stdarg etc. Unfortunately, while for DW_TAG_formal_parameter sub-DIEs, we can use the hash tabs to look the PARM_DECLs if we already have the DIEs, for DW_TAG_unspecified_parameters we don't have an easy way to look it up. The following patch handles it by trying to figure out if we are creating a fresh new DIE (in that case we add DW_TAG_unspecified_parameters if it is stdarg), or if gen_subprogram_die is called again on an pre-existing DIE to fill in some further details (then it will not touch it). Except for lto, subr_die != old_die would be good enough, but unfortunately for LTO the new DIE that will refer to early dwarf created DIE is created on the fly during lookup_decl_die. So the patch tracks if the DIE has no children before any children are added to it. 2020-11-14 Jakub Jelinek PR debug/97599 * dwarf2out.c (gen_subprogram_die): Call gen_unspecified_parameters_die even if not early dwarf, but only if subr_die is a newly created DIE. (cherry picked from commit 2873c8af66e1248734bb638a49e6bc53f5e45382)
[Bug c/97958] ICE in build2, at tree.c:4868
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97958 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:1cd47144fd250f37206c8e2a0cc7d51c25ad368c commit r10-9078-g1cd47144fd250f37206c8e2a0cc7d51c25ad368c Author: Jakub Jelinek Date: Tue Nov 24 09:04:28 2020 +0100 openmp: Fix C ICE on OpenMP atomics c_parser_binary_expression was using build2 to create a temporary holder for binary expression that c_parser_atomic and c_finish_omp_atomic can then handle. The latter performs then all the needed checking. Unfortunately, build2 performs some checking too, e.g. PLUS_EXPR vs. POINTER_PLUS_EXPR or matching types of the arguments, nothing we can guarantee at the parsing time. So we need something like C++ build_min_nt*. This patch implements that inline. 2020-11-24 Jakub Jelinek PR c/97958 * c-parser.c (c_parser_binary_expression): For omp atomic binary expressions, use make_node instead of build2 to avoid checking build2 performs. * c-c++-common/gomp/pr97958.c: New test. (cherry picked from commit 2aaf44a90283156ec0e70ad4d9030f3ba5054c6f)
[Bug target/97528] [9/10 Regression] ICE in decompose_automod_address, at rtlanal.c:6298 (arm-linux-gnueabihf)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97528 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:05a3ab76e03ec6cff0bafb8495387b3a186785cc commit r10-9077-g05a3ab76e03ec6cff0bafb8495387b3a186785cc Author: Jakub Jelinek Date: Fri Nov 20 12:26:58 2020 +0100 arm: Fix up neon_vector_mem_operand [PR97528] The documentation for POST_MODIFY says: Currently, the compiler can only handle second operands of the form (plus (reg) (reg)) and (plus (reg) (const_int)), where the first operand of the PLUS has to be the same register as the first operand of the *_MODIFY. The following testcase ICEs, because combine just attempts to simplify things and ends up with (post_modify (reg1) (plus (mult (reg2) (const_int 4)) (reg1)) but the target predicates accept it, because they only verify that POST_MODIFY's second operand is PLUS and the second operand of the PLUS is a REG. The following patch fixes this by performing further verification that the POST_MODIFY is in the form it should be. 2020-11-20 Jakub Jelinek PR target/97528 * config/arm/arm.c (neon_vector_mem_operand): For POST_MODIFY, require first POST_MODIFY operand is a REG and is equal to the first operand of PLUS. * gcc.target/arm/pr97528.c: New test. (cherry picked from commit 410b8f6f41920dad200cd709f9f3de8b840a995c)
[Bug libstdc++/97936] [11 Regression] 30_threads/latch/3.cc hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97936 --- Comment #8 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a5ccfd04605d940daded7e95474389f1c7dfad61 commit r11-5331-ga5ccfd04605d940daded7e95474389f1c7dfad61 Author: Jonathan Wakely Date: Wed Nov 25 12:16:07 2020 + libstdc++: Fix silly typos [PR 97936] libstdc++-v3/ChangeLog: PR libstdc++/97936 * include/bits/atomic_wait.h (__platform_wait): Check errno, not just the value of EAGAIN. (__waiters::__waiters()): Fix name of data member.
[Bug rtl-optimization/97978] [11 Regression] ICE in lra_assign, at lra-assigns.c:1648 since r11-5066-gbe39636d9f68c437
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97978 --- Comment #2 from Roger Sayle --- The -fno-PIC isn't required, as -Os alone is sufficient to trigger this ICE. I'm not sure if unconditionally calling __builtin_unreachable qualifies as "valid-code" (or possibly an error condition) but lra_assign shouldn't ICE. Removing or commenting out the conditional call to __builtin_unreachable in bp resolves the issue. It appears that the undefined behaviour produced by reaching __builtin_unreachable, with the mixture of pseudos and hard registers resulting from my change, leaves the CFG/LRA pass in an unexpected state, that breaks a required invariant...
[Bug libstdc++/97985] New: Simplify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97985 Bug ID: 97985 Summary: Simplify Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- Most of the header is only used in libsupc++/guard.cc and so doesn't need to be in a public header. The __gnu_cxx::__mutex type is used in a few places, but they could probably use std::mutex instead. The __gnu_cxx::__recursive_mutex and __gnu_cxx::__cond types are not needed outside of libsupc++/guard.cc so should be removed from the public header. The exception types __concurrence_broadcast_error and __concurrence_wait_error are only needed by __cond. Having four exception types in that header increases the size of the library, due to the vtables and RTTI. We would probably just have one type that holds a const char* for the result of what(). Some of these things are mentioned in the docs, so we might want to deprecate them first, before removing them.
[Bug tree-optimization/97984] [10/11 Regression] Worse code for -O3 than -O2 on aarch64 vector multiply-add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97984 Richard Biener changed: What|Removed |Added Version|unknown |11.0 Ever confirmed|0 |1 Last reconfirmed||2020-11-25 Target Milestone|--- |10.3 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- We vectorize the add but not the multiplication. FMA discovery comes after vectorization so it can't inhibit the transform (and vectorizer costing cannot factor that in). Is there vector madd available? arm vectorizer costing could honor the fact that there's ldp/stp instructions and thus not artifically make a vector load cheaper than two adjacent scalar loads. That would only make the costings equal though. 0x3151930 *b_11(D) 1 times unaligned_load (misalign -1) costs 1 in body 0x3151930 _2 + _3 1 times vector_stmt costs 1 in body 0x3151930 1 times vec_construct costs 2 in prologue 0x3151930 _7 1 times unaligned_store (misalign -1) costs 1 in body 0x31569d0 _7 1 times scalar_store costs 1 in body 0x31569d0 _8 1 times scalar_store costs 1 in body 0x31569d0 _2 + _3 1 times scalar_stmt costs 1 in body 0x31569d0 _5 + _6 1 times scalar_stmt costs 1 in body 0x31569d0 *b_11(D) 1 times scalar_load costs 1 in body 0x31569d0 MEM[(long int *)b_11(D) + 8B] 1 times scalar_load costs 1 in body t.c:5:8: note: Cost model analysis: Vector inside of basic block cost: 3 Vector prologue cost: 2 Vector epilogue cost: 0 Scalar cost of basic block: 6 t.c:5:8: note: Basic block will be vectorized using SLP
[Bug target/91816] [8/9 Regression] Arm generates out of range conditional branches in Thumb2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91816 --- Comment #5 from CVS Commits --- The master branch has been updated by Stam Markianos-Wright : https://gcc.gnu.org/g:bc771e6c3a2b1fe74328639a00531fc0c3923e43 commit r11-5332-gbc771e6c3a2b1fe74328639a00531fc0c3923e43 Author: Stam Markianos-Wright Date: Wed Nov 25 12:50:06 2020 + arm: Add test that was missing from old commit [PR91816] A while back I submitted GCC10 commit: 44f77a6dea2f312ee1743f3dde465c1b8453ee13 for PR91816. Turns out I was an idiot and forgot to include the test in the actual git commit. Tested that the test still passes on a cross arm-none-eabi and also in a Cortex A-15 bootstrap with no regressions. gcc/testsuite/ChangeLog: PR target/91816 * gcc.target/arm/pr91816.c: New test.
[Bug target/91816] [8/9 Regression] Arm generates out of range conditional branches in Thumb2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91816 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Stam Markianos-Wright : https://gcc.gnu.org/g:8804b6ae3da91f3baa82da2fe28090025d5717d3 commit r10-9079-g8804b6ae3da91f3baa82da2fe28090025d5717d3 Author: Stam Markianos-Wright Date: Wed Nov 25 13:11:09 2020 + arm: Add test that was missing from old commit [PR91816] A while back I submitted GCC10 commit: 44f77a6dea2f312ee1743f3dde465c1b8453ee13 for PR91816. Turns out I was an idiot and forgot to include the test in the actual git commit. Tested that the test still passes on a cross arm-none-eabi and also in a Cortex A-15 bootstrap with no regressions. gcc/testsuite/ChangeLog: 2020-11-25 Stam Markianos-Wright PR target/91816 * gcc.target/arm/pr91816.c: New test.
[Bug tree-optimization/97579] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579 --- Comment #10 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:fddc7f0080f1f056c4d145451608ebd3e807422a commit r11-5364-gfddc7f0080f1f056c4d145451608ebd3e807422a Author: Richard Biener Date: Wed Nov 25 12:31:54 2020 +0100 middle-end/97579 - lower VECTOR_BOOLEAN_TYPE_P VEC_COND_EXPRs This makes sure to lower VECTOR_BOOLEAN_TYPE_P typed non-vector mode VEC_COND_EXPRs so we don't try to use vcond to expand those. That's required for x86 and gcn integer mode boolean vectors. 2020-11-25 Richard Biener PR middle-end/97579 * gimple-isel.cc (gimple_expand_vec_cond_expr): Lower VECTOR_BOOLEAN_TYPE_P, non-vector mode VEC_COND_EXPRs. * gcc.dg/pr97579.c: New testcase.
[Bug tree-optimization/97579] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Richard Biener --- Fixed.
[Bug target/95908] [AArch64] wrong code with ILP32 and -fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95908 --- Comment #1 from Richard Earnshaw --- I'm sure the code we generate doesn't match your expectations. What's more, I don't think it's really practical to meet them. To do so would require emitting a mask operation after practically every arithmetic operation done on pointers to ensure the value is kept within the valid range of the address space, since we have no idea how close an object might be to the end of that space. So my inclination is to resolve this a WONTFIX; but I'll leave it open for now so that others can comment.
[Bug rtl-optimization/90249] [9/10/11 Regression] Code size regression on thumb2 due to sub-optimal register allocation starting with r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90249 Stam Markianos-Wright changed: What|Removed |Added CC||stammark at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |stammark at gcc dot gnu.org --- Comment #12 from Stam Markianos-Wright --- Was reminded that this was still open after many months. Have fixed the commit and am in the process of backporting to gcc-8,9.
[Bug rtl-optimization/90249] [9/10/11 Regression] Code size regression on thumb2 due to sub-optimal register allocation starting with r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90249 Stam Markianos-Wright changed: What|Removed |Added Assignee|stammark at gcc dot gnu.org|unassigned at gcc dot gnu.org --- Comment #13 from Stam Markianos-Wright --- Was reminded that this was still open after many months. Have fixed the commit and am in the process of backporting to gcc-8,9.(In reply to Stam Markianos-Wright from comment #12) > Was reminded that this was still open after many months. Have fixed the > commit and am in the process of backporting to gcc-8,9. Excuse that, am an idiot and commented in entirely the wrong place!
[Bug rtl-optimization/90249] [9/10/11 Regression] Code size regression on thumb2 due to sub-optimal register allocation starting with r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90249 --- Comment #14 from Stam Markianos-Wright --- Was reminded that this was still open after many months. Have fixed the commit and am in the process of backporting to gcc-8,9.(In reply to Stam Markianos-Wright from comment #12) > Was reminded that this was still open after many months. Have fixed the > commit and am in the process of backporting to gcc-8,9. Excuse that, am an idiot and commented in entirely the wrong place!
[Bug rtl-optimization/95862] Failure to optimize usage of __builtin_mul_overflow to small __int128-based check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95862 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:049ce9d233e2d865dc81a5042b1c28ee21d1c9d8 commit r11-5366-g049ce9d233e2d865dc81a5042b1c28ee21d1c9d8 Author: Jakub Jelinek Date: Wed Nov 25 15:42:38 2020 +0100 middle-end: __builtin_mul_overflow expansion improvements [PR95862] The following patch adds some improvements for __builtin_mul_overflow expansion. One optimization is for the u1 * u2 -> sr case, as documented we normally do: u1 * u2 -> sr res = (S) (u1 * u2) ovf = res < 0 || main_ovf (true) where main_ovf (true) stands for jump on unsigned multiplication overflow. If we know that the most significant bits of both operands are clear (such as when they are zero extended from something smaller), we can emit better coe by handling it like s1 * s2 -> sr, i.e. just jump on overflow after signed multiplication. Another two cases are s1 * s2 -> ur or s1 * u2 -> ur, if we know the minimum precision needed to encode all values of both arguments summed together is smaller or equal to destination precision (such as when the two arguments are sign (or zero) extended from half precision types, we know the overflows happen only iff one argument is negative and the other argument is positive (not zero), because even if both have maximum possible values, the maximum is still representable (e.g. for char * char -> unsigned short 0x7f * 0x7f = 0x3f01 and for char * unsigned char -> unsigned short 0x7f * 0xffU = 0x7e81) and as the result is unsigned, all negative results do overflow, but are also representable if we consider the result signed - all of them have the MSB set. So, it is more efficient to just do the normal multiplication in that case and compare the result considered as signed value against 0, if it is smaller, overflow happened. And the get_min_precision change is to improve the char to short handling, we have there in the IL _2 = (int) arg_1(D); promotion from C promotions from char or unsigned char arg, and the caller adds a NOP_EXPR cast to short or unsigned short. get_min_precision punts on the narrowing cast though, it handled only widening casts, but we can handle narrowing casts fine too, by recursing on the narrowing cast operands and using it only if it has in the end smaller minimal precision, which would duplicate the sign bits (or zero bits) to both the bits above the narrowing conversion and also at least one below that. 2020-10-25 Jakub Jelinek PR rtl-optimization/95862 * internal-fn.c (get_min_precision): For narrowing conversion, recurse on the operand and if the operand precision is smaller than the current one, return that smaller precision. (expand_mul_overflow): For s1 * u2 -> ur and s1 * s2 -> ur cases if the sum of minimum precisions of both operands is smaller or equal to the result precision, just perform normal multiplication and set overflow to the sign bit of the multiplication result. For u1 * u2 -> sr if both arguments have the MSB known zero, use normal s1 * s2 -> sr expansion. * gcc.dg/builtin-artih-overflow-5.c: New test.
[Bug rtl-optimization/95862] Failure to optimize usage of __builtin_mul_overflow to small __int128-based check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95862 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Jakub Jelinek --- Fixed on the trunk.
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 95862, which changed state. Bug 95862 Summary: Failure to optimize usage of __builtin_mul_overflow to small __int128-based check https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95862 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c/97986] New: ICE in force_constant_size when applying va_arg to VLA type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97986
Bug ID: 97986
Summary: ICE in force_constant_size when applying va_arg to VLA
type
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pascal_cuoq at hotmail dot com
Target Milestone: ---
This bug seems most similar to (but still different from)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59711 (in which a comment says
that it appears to have been fixed in GCC 6).
In GCC 10.2 and some earlier versions, compiling the following program
(Compiler Explorer link: https://gcc.godbolt.org/z/11ob5j ):
#include
int sum(int n, ...)
{
va_list ap;
va_start(ap, n);
int *input = va_arg(ap, int[n]);
int rc = 0;
for (int i = 0; i < n; i++)
rc += input[i];
return rc;
}
Produces the following error message:
In file included from :1:
: In function 'sum':
:7:29: internal compiler error: in force_constant_size, at
gimplify.c:733
7 | int *input = va_arg(ap, int[n]);
| ^~~
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug inline-asm/97987] New: FAIL: gcc.c-torture/compile/asmgoto-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97987 Bug ID: 97987 Summary: FAIL: gcc.c-torture/compile/asmgoto-2.c Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: inline-asm Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa*-*-* Target: hppa*-*-* Build: hppa*-*-* Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdi r/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/asmgoto-2.c -fdiagnostics-plain-output-O0 -w -S -o asmgoto-2.s(timeout = 300) spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/obj dir/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/asmgoto-2.c -fdiagnostics-plain-output -O0 -w -S -o asmgoto-2.s /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/asmgoto-2.c: In funct ion 'foo': /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/asmgoto-2.c:8:3: erro r: the target does not support asm goto with outputs in 'asm' compiler exited with status 1 FAIL: gcc.c-torture/compile/asmgoto-2.c -O0 (test for excess errors) Excess errors: /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/asmgoto-2.c:8:3: error: the target does not support asm goto with outputs in 'asm' spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/obj dir/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/asmgoto-5.c -fdiagnostics-plain-output -O0 -w -S -o asmgoto-5.s /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/asmgoto-5.c: In funct ion 'foo': /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/asmgoto-5.c:43:3: err or: the target does not support asm goto with outputs in 'asm' compiler exited with status 1 FAIL: gcc.c-torture/compile/asmgoto-5.c -O0 (test for excess errors) Excess errors: /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/asmgoto-5.c:43:3: error: the target does not support asm goto with outputs in 'asm' Tests fail at all optimizations. First seen in 11.0.0 20201115 build.
[Bug target/94993] aarch64 incompatible with -mgeneral-regs-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94993 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-11-25 Ever confirmed|0 |1 --- Comment #1 from Richard Earnshaw --- Confirmed, but only happens for C++, I can't reproduce it with the C compiler.
[Bug libstdc++/93456] No overflow check in __atomic_futex_unsigned_base::_M_futex_wait_until
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93456 --- Comment #7 from Jonathan Wakely --- (In reply to CVS Commits from comment #3) > * testsuite/30_threads/future/members/93456.cc: ...here. This test is failing for powerpc-darwin9, probably because I added overflow checks for the futex version of __atomic_futex_unsigned_base but not the generic version that uses a condition variable.
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953
--- Comment #15 from Martin Liška ---
Created attachment 49624
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49624&action=edit
debugging patch
All right it will be for Richi. I suspect it's a do_hoist_insertion.
reduced test-case:
$ cat /tmp/bid.i
int __bid_ten2k64_res_0, __bid_ten2k64_ind;
void __bid_round64_2_18();
void __bid_ten2k64() {
for (; __bid_ten2k64_ind <= 9; __bid_ten2k64_ind++)
if (__bid_ten2k64_res_0)
break;
if (__bid_ten2k64_ind)
__bid_round64_2_18();
}
Steps to reproduce:
1) git co bd87cc14ebdb6789e067fb1828d5808407c308b3
2) patch -p1 < debug.patch
3) mkdir objdir
4) cd objdir
5) ../configure --disable-checking --disable-werror
--enable-languages=c,c++,fortran --disable-multilib
6) make -j16 (you can also use make -j16 'STAGE1_CFLAGS=-g -O2')
... then it build stage2 compiler and crashes in somewhere in libgcc (using the
compiler)
$ ./gcc/xgcc -Bgcc /tmp/bid.i -O2 -c -fverbose-asm
__bid_ten2k64_ind.2_11 = PHI <_3(13), __bid_ten2k64_ind.2_12(4)>
use->stmt: 0x77548400, use->stmt->code: 18
_3 = __bid_ten2k64_ind.2_11 + 1;
cand->incremented_at: 0x77544000, cand->incremented_at->code: 6
during GIMPLE pass: ivopts
/tmp/bid.i: In function ‘__bid_ten2k64’:
/tmp/bid.i:4:6: internal compiler error: XX, code==18
4 | void __bid_ten2k64() {
| ^
0x77695151 __libc_start_main
../csu/libc-start.c:314
0x5ffafd ???
../sysdeps/x86_64/start.S:120
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953
--- Comment #16 from Martin Liška ---
Then you will see the following diff in optimized dump:
--- good2020-11-25 16:27:16.795544128 +0100
+++ bad 2020-11-25 16:26:59.723620747 +0100
@@ -17022,7 +17022,6 @@
;; Function rewrite_use_nonlinear_expr
(_ZL26rewrite_use_nonlinear_exprP11ivopts_dataP6iv_useP7iv_cand,
funcdef_no=3488, decl_uid=138891, cgraph_uid=2628, symbol_order=2806)
-Removing basic block 55
Removing basic block 56
Removing basic block 57
Removing basic block 58
@@ -17049,6 +17048,10 @@
Removing basic block 79
Removing basic block 80
Removing basic block 81
+Removing basic block 82
+Removing basic block 83
+Removing basic block 84
+Removing basic block 85
__attribute__((noipa, noinline, noclone, no_icf))
rewrite_use_nonlinear_expr (struct ivopts_data * data, struct iv_use * use,
struct iv_cand * cand)
{
@@ -17182,6 +17185,9 @@
struct gimple * pretmp_236;
unsigned char _237;
struct gimple * _239;
+ unsigned char _265;
+ struct gimple * prephitmp_268;
+ unsigned char _269;
struct gimple * prephitmp_270;
struct gimple * pretmp_272;
struct gimple * _287;
@@ -17252,7 +17258,7 @@
if (_11 == _12)
goto ; [30.00%]
else
-goto ; [70.00%]
+goto ; [70.00%]
[local count: 109521665]:
_118 = MEM[(const struct gassign *)_12].D.92331.op[0];
@@ -17364,19 +17370,19 @@
[local count: 583887]:
pretmp_236 = use_88(D)->stmt;
- [local count: 972093934]:
- # prephitmp_15 = PHI
+ [local count: 716543374]:
+ # prephitmp_15 = PHI
_184 = MEM[(const struct gimple *)prephitmp_15].code;
if (_184 == 6)
-goto ; [44.98%]
+goto ; [25.49%]
else
-goto ; [55.02%]
+goto ; [74.51%]
- [local count: 972093934]:
+ [local count: 971122338]:
if (_184 == 18)
-goto ; [99.90%]
+goto ; [100.00%]
else
-goto ; [0.10%]
+goto ; [0.00%]
[local count: 534347641]:
_190 = MEM[(union tree_node * *)prephitmp_15 + 48B];
@@ -17431,17 +17437,19 @@
goto ; [100.00%]
[local count: 437211681]:
- pretmp_211 = MEM[(const struct gassign *)prephitmp_15].D.92331.op[0];
+ # prephitmp_268 = PHI
+ pretmp_211 = MEM[(const struct gassign *)prephitmp_268].D.92331.op[0];
[local count: 534347641]:
- # _287 = PHI
+ # _287 = PHI
# prephitmp_212 = PHI
bsi = gsi_for_stmt (_287);
pretmp_272 = use_88(D)->stmt;
goto ; [100.00%]
[local count: 534606]:
- retval.1249_113 = (int) _184;
+ # _265 = PHI <_184(29), _269(55)>
+ retval.1249_113 = (int) _265;
internal_error ("XX, code==%d\n", retval.1249_113);
[local count: 887017088]:
@@ -17607,6 +17615,13 @@
_18 ={v} MEM[(struct gimple * *)0B];
__builtin_trap ();
+ [local count: 20560]:
+ _269 = MEM[(const struct gimple *)_12].code;
+ if (_269 == 6)
+goto ; [99.62%]
+ else
+goto ; [0.38%]
+
}
[Bug tree-optimization/97979] [11 Regression]: Segmentation fault with "-O3 -fno-toplevel-reorder -fno-tree-ccp" since r11-5271-g4866b2f5db117f9e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97979 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 49625 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49625&action=edit gcc11-pr97979.patch The match.pd pattern was unprepared to handle int_const_binop giving up, which it now does for some of the UB shifts (and I think should even for shifts with positive shift amount but larger or equal to the bitsize). int_const_binop similarly gives up for division by zero etc.
[Bug c++/96555] "template argument involves template parameter(s)" with dot or arrow operator in partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96555
Eelis changed:
What|Removed |Added
CC||gcc-bugzilla at contacts dot
eelis
||.net
--- Comment #2 from Eelis ---
The following slightly simpler testcase is also accepted by clang and rejected
by gcc with the same "involves template parameter" error:
template
struct X;
template
struct X {};
[Bug c++/97988] New: [C++20] Forward-declared class type declared inside requires-expression gives weird inconsistencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97988
Bug ID: 97988
Summary: [C++20] Forward-declared class type declared inside
requires-expression gives weird inconsistencies
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/sxWY1f
template
concept C = requires (P ptr) { (struct D*)ptr; };
struct D {};
D d;
Clang accepts. GCC rejects; GCC's error messages imply that GCC is sometimes
treating `D` as a class template `template struct D` and sometimes
treating it as a normal class type, as if its internal representation is
inconsistent.
:6:3: error: class template argument deduction failed:
6 | D d;
| ^
:6:3: error: no matching function for call to 'D()'
:3:40: note: candidate: 'template D()-> D'
3 | concept C = requires (P ptr) { (struct D*)ptr; };
|^
:3:40: note: template argument deduction/substitution failed:
:6:3: note: couldn't deduce template parameter 'P'
6 | D d;
| ^
:3:40: note: candidate: 'template D(D)-> D'
3 | concept C = requires (P ptr) { (struct D*)ptr; };
|^
:3:40: note: template argument deduction/substitution failed:
:6:3: note: candidate expects 1 argument, 0 provided
6 | D d;
| ^
I can also make GCC segfault by trying to use `D` as an NTTP, but I think
that's essentially just a duplicate of #95159 #95291 #96123 #97749 etc., not
necessarily related to the rejects-invalid bug described here.
template
concept C = requires (P ptr) { (struct D*)ptr; };
struct D { constexpr D(); };
template struct S {};
S<1> s;
[Bug debug/97989] New: -g3 somehow breaks -E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989 Bug ID: 97989 Summary: -g3 somehow breaks -E Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: stsp at users dot sourceforge.net Target Milestone: --- $ gcc -E -Wp,-P -xc -
[Bug debug/97989] -g3 somehow breaks -E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- The two options together make no sense. -g3 asks for all macros to be recorded in the debug info and thus they need to be emitted, -P asks not to do that. So, it is all about which of the two options takes precedence.
[Bug rtl-optimization/95862] Failure to optimize usage of __builtin_mul_overflow to small __int128-based check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95862 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b13dacdfb315675803982ad5a3098f7b55e6357a commit r11-5369-gb13dacdfb315675803982ad5a3098f7b55e6357a Author: Jakub Jelinek Date: Wed Nov 25 17:25:36 2020 +0100 testsuite: Rename test to avoid typo in its name [PR95862] 2020-11-25 Jakub Jelinek PR rtl-optimization/95862 * gcc.dg/builtin-artih-overflow-5.c: Renamed to ... * gcc.dg/builtin-arith-overflow-5.c: ... this.
[Bug tree-optimization/97990] New: ICE: ‘verify_type’ failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97990 Bug ID: 97990 Summary: ICE: ‘verify_type’ failed Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: doko at debian dot org Target Milestone: --- Created attachment 49626 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49626&action=edit preprocessed source seen with the gcc-10 branch and the trunk on x86_64-linux-gnu,, -Wall is needed to trigger the ICE. compiler configured with --enable-checking=yes,extra,rtl $ g++ -Wall -O2 -flto -c lambda.ii :303:1: error: type variant with ‘TYPE_ALIAS_SET_KNOWN_P’ unit-size align:16 warn_if_not_align:0 symtab:0 alias-set 2 canonical-type 0x7f28b07af498 precision:16 min max > sizes-gimplified type_6 HI size unit-size align:16 warn_if_not_align:0 symtab:0 alias-set 2 canonical-type 0x7f28b0900c78 nunits:1> unit-size align:16 warn_if_not_align:0 symtab:0 alias-set 2 canonical-type 0x7f28b07af498 precision:16 min max > sizes-gimplified type_6 HI size unit-size align:16 warn_if_not_align:0 symtab:0 alias-set 2 canonical-type 0x7f28b0900c78 nunits:1> during IPA pass: *free_lang_data :303:1: internal compiler error: ‘verify_type’ failed 0x151a060 verify_type(tree_node const*) ../../src/gcc/tree.c:14727 0x151cf5b free_lang_data ../../src/gcc/tree.c:6357 0x151cf5b execute ../../src/gcc/tree.c:6402 Please submit a full bug report, with preprocessed source if appropriate.
[Bug c++/97976] Optimization relating to NULL pointer assumptions in gcc 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97976
Peter Bisroev changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #5 from Peter Bisroev ---
Thank you for your explanation Richard, it makes perfect sense to me now. GCC
is being insanely clever here!
However I still think there is something not 100% right. If I change
containsBackwards() function to look like this:
int containsBackwards(const uint8_t* p, uint8_t target)
{
for (;;)
{
if (*p == target)
{
return 1;
}
--p;
if (!p)
{
return 0;
}
}
}
I apologize in advance as I know the code is far from ideal and is definitely a
corner case, but unless I am mistaken there is no undefined behavior here
assuming p is always valid at the time of the call and it is just to illustrate
the example. So for the above gcc 10.1 generates the following:
containsBackwards(unsigned char const*, unsigned char):
mov eax, 1
ret
So my question is, is gcc allowed to assume that the target will always match?
Additionally, if I make this function a bit safer and unless I am mistaken
without any undefined behavior:
int containsBackwardsSafe(const uint8_t* p, uint8_t target)
{
if (!p)
{
return 0;
}
for (;;)
{
if (*p == target)
{
return 1;
}
--p;
if (!p)
{
return -1;
}
}
}
Then gcc 10.1 generates the following:
containsBackwardsSafe(unsigned char const*, unsigned char):
xor eax, eax
testrdi, rdi
setne al
ret
Which matches the generated output of the original function. However unless I
am mistaken the result here is supposed to be different to the original
function:
* If p == NULL, return 0.
* If target matched while p was valid, return 1.
* If target did not match while p was valid return -1.
You can see these above examples at Compiler Explorer here:
https://godbolt.org/z/ha1c1h
I apologize if there is something critical I am missing here so I hope I am not
wasting your time.
Thank you!
--peter
[Bug bootstrap/97983] [11 Regression] Bootstrap failure on s390x-linux related to vec-perm-indices.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97983 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2020-11-25 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Ah, the profiledbootstrap issue is just that I had the compiler configured --enable-checking=release. With normal bootstrap, stage2 is built with -fchecking=1 and that ICEs, while in profiledbootstrap stagetrain is not built with that and results with -da in 1 GB *.reload dump and this extremely huge stack frame for the function. I bet if the checking issue is fixed the non-checking problem will go away too.
[Bug debug/97989] -g3 somehow breaks -E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- -g3 enables -dD Kinda of documented by: Level 3 includes extra information, such as all the macro definitions present in the program. Some debuggers support macro expansion when you use -g3.
[Bug c/97991] New: ICE in c_parser_consume_token, at c/c-parser.c:850
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97991
Bug ID: 97991
Summary: ICE in c_parser_consume_token, at c/c-parser.c:850
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects versions down to at least r5 :
$ cat z1.c
#define foo _Pragma ("pack(bar)")
#pragma redefine_extname foo
$ gcc-11-20201122 -c z1.c
z1.c:2:9: internal compiler error: in c_parser_consume_token, at
c/c-parser.c:850
2 | #pragma redefine_extname foo
| ^~~~
0x666747 c_parser_consume_token(c_parser*)
../../gcc/c/c-parser.c:850
0x6687ea pragma_lex(tree_node**, unsigned int*)
../../gcc/c/c-parser.c:12555
0x6e4313 handle_pragma_redefine_extname
../../gcc/c-family/c-pragma.c:499
0x66e6bf c_parser_pragma
../../gcc/c/c-parser.c:12524
0x6909f3 c_parser_external_declaration
../../gcc/c/c-parser.c:1758
0x691569 c_parser_translation_unit
../../gcc/c/c-parser.c:1650
0x691569 c_parse_file()
../../gcc/c/c-parser.c:21882
0x6e0772 c_common_parse_file()
../../gcc/c-family/c-opts.c:1198
[Bug c/97991] ICE in c_parser_consume_token, at c/c-parser.c:850
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97991
G. Steinmetz changed:
What|Removed |Added
Target||x86_64-pc-linux-gnu
Keywords||ice-on-invalid-code
--- Comment #1 from G. Steinmetz ---
A special case, loosely related :
$ cat z2.c
#define foo _Pragma (" ")
#pragma redefine_extname foo
$ gcc-11-20201122 -c z2.c -Wall
z2.c:2:2: internal compiler error: unspellable token PRAGMA_EOL
2 | #pragma redefine_extname foo
| ^
0x6c46ba c_cpp_diagnostic(cpp_reader*, cpp_diagnostic_level,
cpp_warning_reason, rich_location*, char const*, __va_list_tag (*) [1])
../../gcc/c-family/c-common.c:6414
0x1522c92 cpp_diagnostic
../../libcpp/errors.c:75
0x1522e16 cpp_error(cpp_reader*, cpp_diagnostic_level, char const*, ...)
../../libcpp/errors.c:89
0x152c22d cpp_spell_token(cpp_reader*, cpp_token const*, unsigned char*, bool)
../../libcpp/lex.c:3541
0x152dac7 cpp_token_as_text(cpp_reader*, cpp_token const*)
../../libcpp/lex.c:3557
0x6d6022 cb_def_pragma
../../gcc/c-family/c-lex.c:255
0x151f880 do_pragma
../../libcpp/directives.c:1539
0x15224fd destringize_and_run
../../libcpp/directives.c:1885
0x15226cc _cpp_do__Pragma
../../libcpp/directives.c:1963
0x1536eb6 builtin_macro
../../libcpp/macro.c:744
0x15344b2 enter_macro_context
../../libcpp/macro.c:1562
0x153624d cpp_get_token_1
../../libcpp/macro.c:2925
0x6d757d c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int)
../../gcc/c-family/c-lex.c:470
0x664e4f c_lex_one_token
../../gcc/c/c-parser.c:279
0x668809 c_parser_peek_token(c_parser*)
../../gcc/c/c-parser.c:483
0x668809 pragma_lex(tree_node**, unsigned int*)
../../gcc/c/c-parser.c:12540
0x6e4313 handle_pragma_redefine_extname
../../gcc/c-family/c-pragma.c:499
0x66e6bf c_parser_pragma
../../gcc/c/c-parser.c:12524
0x6909f3 c_parser_external_declaration
../../gcc/c/c-parser.c:1758
0x691569 c_parser_translation_unit
../../gcc/c/c-parser.c:1650
[Bug c/97992] New: ICE in subst_asm_stack_regs, at reg-stack.c:2264
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97992
Bug ID: 97992
Summary: ICE in subst_asm_stack_regs, at reg-stack.c:2264
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects versions down to at least r5 :
$ cat z1.c
long double
f (long double x)
{
double r;
asm volatile ("fsqrt" : "=t"(r) : ""(x));
return f (x * x);
}
$ gcc-11-20201122 -c z1.c -O2
during RTL pass: stack
z1.c: In function 'f':
z1.c:7:1: internal compiler error: in subst_asm_stack_regs, at reg-stack.c:2264
7 | }
| ^
0xabde0e subst_asm_stack_regs
../../gcc/reg-stack.c:2264
0xabf8ad subst_stack_regs
../../gcc/reg-stack.c:2425
0xabfc27 convert_regs_1
../../gcc/reg-stack.c:3080
0xabfc27 convert_regs_2
../../gcc/reg-stack.c:3214
0xac0ddd convert_regs
../../gcc/reg-stack.c:3249
0xac0ddd reg_to_stack
../../gcc/reg-stack.c:3374
0xac0ddd rest_of_handle_stack_regs
../../gcc/reg-stack.c:3429
0xac0ddd execute
../../gcc/reg-stack.c:3460
[Bug debug/97989] -g3 somehow breaks -E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989 --- Comment #3 from Jakub Jelinek --- Plus the -P option is documented to inhibit only line markers, not are proprocessing directives like what -dD, -dM, -dN, -dI, -dU or -g3 emit.
[Bug c++/97993] New: [11 Regression] ICE tree check: expected tree_list, have error_mark in tsubst_copy_and_build, at cp/pt.c:19834
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97993 Bug ID: 97993 Summary: [11 Regression] ICE tree check: expected tree_list, have error_mark in tsubst_copy_and_build, at cp/pt.c:19834 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20200510 and 20200517 : $ cat z1.cc template T a; template auto foo (); struct S decltype (foo ); $ g++-11-20201122 -c z1.cc z1.cc:2:44: internal compiler error: tree check: expected tree_list, have error_mark in tsubst_copy_and_build, at cp/pt.c:19834 2 | template auto foo (); |^ 0x6520ba tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc/tree.c:9810 0x8915f1 tree_check(tree_node*, char const*, int, char const*, tree_code) ../../gcc/tree.h:3317 0x8915f1 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc/cp/pt.c:19834 0x893a4e tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc/cp/pt.c:16017 0x893a4e tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.c:16017 0x8a45e1 coerce_template_parms ../../gcc/cp/pt.c:8930 0x8ca363 resolve_nondeduced_context(tree_node*, int) ../../gcc/cp/pt.c:22410 0x905e8f finish_decltype_type(tree_node*, bool, int) ../../gcc/cp/semantics.c:10018 0x847461 cp_parser_decltype ../../gcc/cp/parser.c:15198 0x8441ab cp_parser_simple_type_specifier ../../gcc/cp/parser.c:18262 0x8320ed cp_parser_type_specifier ../../gcc/cp/parser.c:18038 0x832d86 cp_parser_decl_specifier_seq ../../gcc/cp/parser.c:14584 0x8339f1 cp_parser_simple_declaration ../../gcc/cp/parser.c:13841 0x861342 cp_parser_declaration ../../gcc/cp/parser.c:13659 0x861cf8 cp_parser_translation_unit ../../gcc/cp/parser.c:4806 0x861cf8 c_parse_file() ../../gcc/cp/parser.c:44613 0x9d63a2 c_common_parse_file() ../../gcc/c-family/c-opts.c:1198
[Bug fortran/97864] Homebrew Operator Overload ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97864 --- Comment #7 from Iain Sandoe --- (In reply to Brad Richardson from comment #6) > I recently updated to Big Sur, and have xcode version 12.2, but this > initially occurred on Catalina. I don't know exactly which version of xcode > was installed then. With master at r11-5267 https://gcc.gnu.org/g:6692c400f207c68fb11b44182ae127856e8b9ad3 Mon 23rd Nov 2020 I cannot reproduce this on x86_64 MacOS 10.12, 10.15 or 11.0. [I tried - no optimisation, -O2, -O -g ] Please could you check if the problem persists for you and, if so: * the command line used * any output from the ICE.
[Bug c++/97994] New: [11 Regression] ICE in nothrow_spec_p, at cp/except.c:1183
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97994
Bug ID: 97994
Summary: [11 Regression] ICE in nothrow_spec_p, at
cp/except.c:1183
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20200621 and 20200628 :
$ cat z1.cc
struct S;
template void foo () noexcept (T::v);
template
void bar (void (A...) noexcept)
{ bar (foo); }
$ g++-11-20200621 -c z1.cc
$
$ g++-11-20201122 -c z1.cc
z1.cc: In substitution of 'template void bar(void (*)(A ...)
noexcept) [with A = ]':
z1.cc:5:14: required from here
z1.cc:5:14: internal compiler error: in nothrow_spec_p, at cp/except.c:1183
5 | { bar (foo); }
| ^
0x6de2d7 nothrow_spec_p(tree_node const*)
../../gcc/cp/except.c:1183
0x770333 unify
../../gcc/cp/pt.c:23799
0x76f313 unify
../../gcc/cp/pt.c:23888
0x7707cc try_one_overload
../../gcc/cp/pt.c:22522
0x76e5f5 resolve_overloaded_unification
../../gcc/cp/pt.c:22286
0x76e5f5 unify_one_argument
../../gcc/cp/pt.c:21832
0x77b3b6 type_unification_real
../../gcc/cp/pt.c:21976
0x7840eb fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
../../gcc/cp/pt.c:21345
0x65315c add_template_candidate_real
../../gcc/cp/call.c:3431
0x6537ec add_template_candidate
../../gcc/cp/call.c:3519
0x6537ec add_candidates
../../gcc/cp/call.c:5929
0x657881 add_candidates
../../gcc/cp/call.c:4561
0x657881 perform_overload_resolution
../../gcc/cp/call.c:4561
0x65c372 build_new_function_call(tree_node*, vec**, int)
../../gcc/cp/call.c:4635
0x796810 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/cp/semantics.c:2703
0x73f005 cp_parser_postfix_expression
../../gcc/cp/parser.c:7556
0x7471b5 cp_parser_unary_expression
../../gcc/cp/parser.c:8659
0x7211ff cp_parser_cast_expression
../../gcc/cp/parser.c:9562
0x721a32 cp_parser_binary_expression
../../gcc/cp/parser.c:9664
0x7231c0 cp_parser_assignment_expression
../../gcc/cp/parser.c:9968
[Bug debug/97989] -g3 somehow breaks -E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989 --- Comment #4 from Stas Sergeev --- Jakub, people use "cc -E -Wp,-P $CFLAGS" as a generic preprocessor. $CFLAGS is needed to specify the includes, but all other options do never affect -E. But if CFLAGS contains -g3, you suddenly can't do that! > -g3 enables -dD Not letting people to use "cc -E -Wp,-P $CFLAGS" as a generic preprocessor, is a very bad idea. If -g3 enables -dD, then perhaps -P should disable it?
[Bug c++/97995] New: [11 Regression] ICE tree check: expected tree that contains 'typed' structure, have 'deferred_noexcept' in unify, at cp/pt.c:23473
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97995 Bug ID: 97995 Summary: [11 Regression] ICE tree check: expected tree that contains 'typed' structure, have 'deferred_noexcept' in unify, at cp/pt.c:23473 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20200621 and 20200628 : $ cat z1.cc struct S; template void foo () noexcept (T::v); template void bar (void (A...) noexcept (b)); static_assert (bar (foo); $ g++-11-20201122 -c z1.cc z1.cc: In substitution of 'template void bar(void (*)(A ...) noexcept (b)) [with A = ; int b = ]': z1.cc:5:27: required from here z1.cc:5:27: internal compiler error: tree check: expected tree that contains 'typed' structure, have 'deferred_noexcept' in unify, at cp/pt.c:23473 5 | static_assert (bar (foo); | ^ 0x6527ab tree_contains_struct_check_failed(tree_node const*, tree_node_structure_enum, char const*, int, char const*) ../../gcc/tree.c:9984 0x8a0193 contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) ../../gcc/tree.h:3431 0x8a0193 unify ../../gcc/cp/pt.c:23473 0x89eb1c unify ../../gcc/cp/pt.c:23796 0x89dcbe unify ../../gcc/cp/pt.c:23563 0x8a03cf try_one_overload ../../gcc/cp/pt.c:22522 0x89b45a resolve_overloaded_unification ../../gcc/cp/pt.c:22286 0x89b45a unify_one_argument ../../gcc/cp/pt.c:21832 0x8bb1b4 type_unification_real ../../gcc/cp/pt.c:21976 0x8d1300 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node* const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool, bool) ../../gcc/cp/pt.c:21345 0x6a1332 add_template_candidate_real ../../gcc/cp/call.c:3431 0x6a2014 add_template_candidate ../../gcc/cp/call.c:3519 0x6a2014 add_candidates ../../gcc/cp/call.c:5929 0x6a7e0b add_candidates ../../gcc/cp/call.c:4553 0x6a7e0b perform_overload_resolution ../../gcc/cp/call.c:4561 0x6afef2 build_new_function_call(tree_node*, vec**, int) ../../gcc/cp/call.c:4635 0x8fbdec finish_call_expr(tree_node*, vec**, bool, bool, int) ../../gcc/cp/semantics.c:2703 0x846165 cp_parser_postfix_expression ../../gcc/cp/parser.c:7556 0x850915 cp_parser_unary_expression ../../gcc/cp/parser.c:8659 0x820faf cp_parser_cast_expression ../../gcc/cp/parser.c:9562
[Bug c/97992] ICE in subst_asm_stack_regs, at reg-stack.c:2264
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97992 --- Comment #1 from Uroš Bizjak --- This is expected with invalid asm.
[Bug debug/97989] -g3 somehow breaks -E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989 --- Comment #5 from Jakub Jelinek --- Then they just make bad assumptions. You can do: cc -E -Wp,-P $CFLAGS -g0 instead if you are sure CFLAGS don't include the -d[DMNIU] options nor e.g. -fdirectives-only.
[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #4 from ktkachov at gcc dot gnu.org --- This seems to go into a bad loop somewhere in LRA.
[Bug debug/97599] [8/9 Regression] missing unspecified_parameters DIE in DWARF for functions with variable arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97599 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2020-11-25 Summary|[8/9/10/11 Regression] |[8/9 Regression] missing |missing |unspecified_parameters DIE |unspecified_parameters DIE |in DWARF for functions with |in DWARF for functions with |variable arguments |variable arguments | Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- Fixed for 10.3+ and 11.1+ so far.
[Bug debug/97989] -g3 somehow breaks -E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989 --- Comment #6 from Stas Sergeev --- (In reply to Jakub Jelinek from comment #5) > Then they just make bad assumptions. You can do: > cc -E -Wp,-P $CFLAGS -g0 > instead if you are sure CFLAGS don't include the -d[DMNIU] options nor e.g. > -fdirectives-only. $ gcc -g3 -E -Wp,-P -xc -g0 -
[Bug bootstrap/97983] [11 Regression] Bootstrap failure on s390x-linux related to vec-perm-indices.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97983 --- Comment #3 from Vladimir Makarov --- (In reply to Jakub Jelinek from comment #1) > Created attachment 49623 [details] > vec-perm-indices.ii.xz > > The preprocessed file. I've reproduced the problem. The emitted insn got wrong bb. The patch is on the way. I guess it will be ready today or at most tomorrow.
[Bug debug/97989] -g3 somehow breaks -E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989 --- Comment #7 from Jakub Jelinek --- Created attachment 49627 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49627&action=edit gcc11-pr97989.patch That can be handled by this patch. But we can't retroactively apply it to released versions (and it is as a behavior change inappropriate for release branches either). So you need to filter out -g3 out of the flags yourself then, like one needs to filter out the above mentioned -d* options anyway.
[Bug libstdc++/97935] Missing subsumption in iterator category detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97935 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:9d908b7fc475b351622fa5630d4874068c789d70 commit r11-5381-g9d908b7fc475b351622fa5630d4874068c789d70 Author: Jonathan Wakely Date: Wed Nov 25 17:18:44 2020 + libstdc++: Fix missing subsumption in std::iterator_traits [PR 97935] libstdc++-v3/ChangeLog: PR libstdc++/97935 * include/bits/iterator_concepts.h (__detail::__iter_without_category): New helper concept. (__iterator_traits::__cat): Use __detail::__iter_without_category. * testsuite/24_iterators/associated_types/iterator.traits.cc: New test.
[Bug debug/97989] -g3 somehow breaks -E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989 --- Comment #8 from Stas Sergeev --- Thanks, but what will this patch do? Will it allow the trailing -g0, or what? For example if you implement -d0 or alike to undo the effect of previously specified -dD, will this still break the release branches? I suppose not?
[Bug debug/97989] -g3 somehow breaks -E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989 --- Comment #9 from Jakub Jelinek --- It will allow -g0 at the end to override the earlier -g3 and not add -dD in that case.
[Bug debug/97989] -g3 somehow breaks -E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989 --- Comment #10 from Stas Sergeev --- Ah, cool, thanks. Should this be re-opened?
[Bug debug/97989] -g3 somehow breaks -E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2020-11-25 Resolution|INVALID |--- Ever confirmed|0 |1 Status|RESOLVED|REOPENED --- Comment #11 from Jakub Jelinek --- .
[Bug tree-optimization/97956] [11 Regression] ICE in build2, at tree.c:4872 since r11-2709-g866626efd749ed3e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97956 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:aec2d6849160f92cd45f97d6c3bdd8808ab01fa6 commit r11-5382-gaec2d6849160f92cd45f97d6c3bdd8808ab01fa6 Author: Martin Sebor Date: Wed Nov 25 11:00:10 2020 -0700 PR middle-end/97956 - ICE due to type mismatch in pointer_plus_expr during memchr folding gcc/ChangeLog: PR middle-end/97956 * gimple-fold.c (gimple_fold_builtin_memchr): Use sizetype for pointer offsets. gcc/testsuite/ChangeLog: PR middle-end/97956 * gcc.dg/memchr-3.c: New test.
[Bug tree-optimization/97956] [11 Regression] ICE in build2, at tree.c:4872 since r11-2709-g866626efd749ed3e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97956 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- Committed in r11-5382.
[Bug tree-optimization/94846] Failure to optimize jnc+inc into adc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94846
Uroš Bizjak changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2020-11-25
Status|UNCONFIRMED |NEW
CC||rguenth at gcc dot gnu.org
Component|rtl-optimization|tree-optimization
--- Comment #3 from Uroš Bizjak ---
This looks like a tree-optimization problem. A store to *p_5(D) could sink all
the way to bb5. RTL gets expanded from:
...
if (_10 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870912]:
*p_5(D) = _1;
goto ; [100.00%]
[local count: 536870913]:
_2 = _1 + 1;
*p_5(D) = _2;
[local count: 1073741824]:
# prephitmp_11 = PHI <_1(3), _2(4)>
return prephitmp_11;
ifcvt RTL pass (_.ce1) is unable to convert:
...
17: r86:SI=r89:SI
REG_DEAD r89:SI
18: flags:CCZ=cmp(r85:SI,0)
REG_DEAD r85:SI
19: pc={(flags:CCZ!=0)?L24:pc}
REG_DEAD flags:CCZ
REG_BR_PROB 536870916
20: NOTE_INSN_BASIC_BLOCK 5
21: [r87:DI]=r89:SI
REG_DEAD r87:DI
; pc falls through to BB 7
24: L24:
25: NOTE_INSN_BASIC_BLOCK 6
26: {r86:SI=r89:SI+0x1;clobber flags:CC;}
REG_UNUSED flags:CC
27: [r87:DI]=r86:SI
REG_DEAD r87:DI
32: L32:
35: NOTE_INSN_BASIC_BLOCK 7
...
IF-THEN-ELSE-JOIN block found, pass 2, test 2, then 5, else 6, join 7
===
In case p is not a pointer, RTL optimizers start with:
...
if (_8 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
p_5 = p_4 + 1;
[local count: 1073741824]:
# p_1 = PHI
return p_1;
and RTL ifcvt pass is able to convert this form to addcc:
IF-THEN-JOIN block found, pass 2, test 2, then 5, join 6
if-conversion succeeded through noce_try_addcc
[Bug debug/97989] -g3 somehow breaks -E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989 --- Comment #12 from Stas Sergeev --- Will your patch also fix this: $ cpp -g3 -P -xc -g0 -
