[Bug target/92388] New: ICE in insert_regs, at cse.c:1129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92388
Bug ID: 92388
Summary: ICE in insert_regs, at cse.c:1129
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: arm-linux-gnueabi
I see the following ICE:
$ arm-linux-gnueabi-gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/950612-1.c
-fno-dce -O3 -c
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/950612-1.c:17:1:
warning: return type defaults to ‘int’ [-Wimplicit-int]
17 | f (pc)
| ^
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/950612-1.c: In
function ‘f’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/950612-1.c:116:3:
warning: implicit declaration of function ‘printf’
[-Wimplicit-function-declaration]
116 | printf("shift = %d\n", shift);
| ^~
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/950612-1.c:116:3:
warning: incompatible implicit declaration of built-in function ‘printf’
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/950612-1.c:1:1:
note: include ‘’ or provide a declaration of ‘printf’
+++ |+#include
1 | typedef enum
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/950612-1.c:132:7:
warning: incompatible implicit declaration of built-in function ‘printf’
132 | printf("%08lx.%08lx\n", (long)(((unsigned long long) acc) >> 32)
, (long)(((unsigned long long) acc) & 0x));
| ^~
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/950612-1.c:132:7:
note: include ‘’ or provide a declaration of ‘printf’
during RTL pass: cse_local
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/950612-1.c:134:1:
internal compiler error: in insert_regs, at cse.c:1129
134 | }
| ^
0x5a4b07 insert_regs
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/cse.c:1129
0x10e97a8 cse_insn
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/cse.c:5956
0x10ebac4 cse_extended_basic_block
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/cse.c:6614
0x10ebac4 cse_main
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/cse.c:6793
0x10ec74d rest_of_handle_cse_after_global_opts
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/cse.c:7765
0x10ec74d execute
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/cse.c:7816
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug lto/92279] [10 Regression] ICE in error: non-trivial conversion in 'constructor' since r276416
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92279 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Martin Liška --- The issue is gone, so I'm closing that.
[Bug target/77918] S390: Floating point comparisons don't raise invalid for unordered operands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77918 --- Comment #16 from stli at linux dot ibm.com --- Just as information, this glibc commit will be first available with glibc 2.31 release: "S390: Fp comparison are now raising FE_INVALID with gcc 10." https://sourceware.org/git/?p=glibc.git;a=commit;h=64bca76f42a82e6a9ea2b0166deab7aa2b7efbea
[Bug sanitizer/90589] In Fedora 30 ps hangs using address sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90589 --- Comment #11 from mccannd at uk dot ibm.com --- I've just discovered that /usr/bin/free also exhibits the same symptoms.
[Bug debug/92387] New: gcc generates wrong debug information at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92387
Bug ID: 92387
Summary: gcc generates wrong debug information at -O1
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: qrzhang at gatech dot edu
Target Milestone: ---
It seems to be a recent regression. gcc-9 works fine.
The expected value of i should be 0 or opt-out. However, with "-O1", gdb
outputs "i=1".
$ gcc-trunk -v
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20191105 (experimental) [trunk revision 277821] (GCC)
#expected output
$ gcc-trunk -g abc.c
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x400540: file abc.c, line 12.
Breakpoint 1, main () at abc.c:12
12 if (d) printf("index = %d\n", i); // stop here.
$1 = 0
#wrong output at -O1
$ gcc-trunk -O1 -g abc.c
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x4004a1: file abc.c, line 12.
Breakpoint 1, main () at abc.c:12
12 if (d) printf("index = %d\n", i); // stop here.
$1 = 1
$ cat abc.c
static int a[6];
int b ;
static void c () {
b = 5 ^ a[b & 5];
}
int main () {
int i, d = 0;
c ();
i = 0;
for (; i < 8; i++) {
c ();
if (d) printf("index = %d\n", i); // stop here.
}
}
$ cat cmds
b abc.c:12
r
p i
kill
q
[Bug c++/91318] [C++][PATCH] warnings about unused internal macros with -Wunused-macros and #pragma GCC optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91318 --- Comment #4 from Eric Gallager --- (In reply to Piotr Henryk Dabrowski from comment #3) > Sent: > https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00325.html Sorry that it doesn't seem to have been reviewed yet; please ping it occasionally!
[Bug go/91992] gcc/testsuite/go/index0-out.x SEGV and spinlock during testsuite run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91992 --- Comment #5 from Martin Sebor --- I haven't had time to debug it but it would help if the test set up an alarm to avoid hanging the build. Otherwise I have no choice but to disable go in my builds.
[Bug c++/70141] [6 Regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141 --- Comment #25 from postmas...@trippelsdorf-de.bounceio.net --- Your email was bounced... - ... because something went wrong between you and your recipient. Ugh! What to do next? Well, your specific problem was a *5.1.2 * error. Which means you should: Check the "trippelsdorf.de" part of "mar...@trippelsdorf.de" for misspellings or missing letters. If you find an error, correct it in your contacts list or address book for next time. Or further: It is possible that the domain is temporarily inactive. If the spelling looks correct, contact your mail provider and if necessary, contact your recipient another way (e.g., phone or text message). Get more Bounce Intelligence ™ on 5.1.2 errors here![1] Thanks, have a lovely day. Yours truly, betterbounces.net[2] Rate this email: Helpful[3] :) or... Not Helpful[4] :( Advertisement | Prefer no ads?[5] YOU MIGHT LIKE [6] [7] [8] Learn more about RevenueStripe...[9] - © 2017 betterbounces.net, All rights reserved. Privacy[10] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] 1. https://www.betterbounces.net/email-error/5.1.2?utm_source=7o9_medium=direct_campaign=trippelsdorf.de_content=SeretV2 2. http://bit.ly/1AqkgOr 3. https://www.surveygizmo.com/s3/1609211/rtm01?tv=SeretV2=5.1.2=D0E7FBC4-1454-4536-8C67-0465C2FC34AC.1=7o9=Helpful 4. https://www.surveygizmo.com/s3/1609211/rtm01?tv=SeretV2=5.1.2=D0E7FBC4-1454-4536-8C67-0465C2FC34AC.1=7o9=Not%20helpful 5. https://betterbounces.net/b/Y1lM9w9S1KeLJcXVUarv1OJFNUggPr2joqvuXnfzPULQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsYz6BSAduUDUOX259ENsI7e3HBFe_L9qqkswLxxp.9W4Mz9nic1fEk3b_JEBlfwrWyjYIBRM6OLFt_OXq_MrKuT9FbPDZoBNzGNE4gztylPle8NHh464vf7titT91WI150sPs4r2y2APILF5Fb_KY7JnWSvrTPQ_RLqzm5WLiQf9amSPLQH7QgRJJZl0nTmCeqeWsyMBJiWfZrPx8SH4.8zu7_XLq5Vud3TorBoHSCE6wkb_Deg3l2j 6. http://stripe.rs-1117-a.com/stripe/redirect?cs_email=f34cde757c9729b925454a1cf67de4ac_sendid=1573006078190_esp=threatwave_offset=0_stripeid=2454 7. http://stripe.rs-1117-a.com/stripe/redirect?cs_email=f34cde757c9729b925454a1cf67de4ac_sendid=1573006078190_esp=threatwave_offset=1_stripeid=2454 8. http://stripe.rs-1117-a.com/stripe/redirect?cs_email=f34cde757c9729b925454a1cf67de4ac_sendid=1573006078190_esp=threatwave_offset=2_stripeid=2454 9. http://branding.rs-1117-a.com/?utm_source=contentstripe_medium=email_campaign=rs_2454_content=animatedlogo 10. https://www.betterbounces.net/privacy-policy
[Bug c++/70141] [6 Regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141 --- Comment #24 from Sori Lee --- I retract my last report. I mistakenly thought my example compiled on clang, but rightly it didn't there either -- the U in the partial specialisation is in a non-deduced context, and fails to be deduced as discussed in https://stackoverflow.com/a/35877464. Apologies.
[Bug c++/70141] [6 Regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141 --- Comment #22 from postmas...@trippelsdorf-de.bounceio.net --- Your email was bounced... - ... because something went wrong between you and your recipient. Ugh! What to do next? Well, your specific problem was a *5.1.2 * error. Which means you should: Check the "trippelsdorf.de" part of "mar...@trippelsdorf.de" for misspellings or missing letters. If you find an error, correct it in your contacts list or address book for next time. Or further: It is possible that the domain is temporarily inactive. If the spelling looks correct, contact your mail provider and if necessary, contact your recipient another way (e.g., phone or text message). Get more Bounce Intelligence ™ on 5.1.2 errors here![1] Thanks, have a lovely day. Yours truly, betterbounces.net[2] Rate this email: Helpful[3] :) or... Not Helpful[4] :( Advertisement | Prefer no ads?[5] YOU MIGHT LIKE [6] [7] [8] Learn more about RevenueStripe...[9] - © 2017 betterbounces.net, All rights reserved. Privacy[10] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] 1. https://www.betterbounces.net/email-error/5.1.2?utm_source=7o9_medium=direct_campaign=trippelsdorf.de_content=SeretV2 2. http://bit.ly/1AqkgOr 3. https://www.surveygizmo.com/s3/1609211/rtm01?tv=SeretV2=5.1.2=A52FF7B6-2F8C-4799-836F-C303696BACB8.1=7o9=Helpful 4. https://www.surveygizmo.com/s3/1609211/rtm01?tv=SeretV2=5.1.2=A52FF7B6-2F8C-4799-836F-C303696BACB8.1=7o9=Not%20helpful 5. https://betterbounces.net/b/Y1lM9w9S1KeLJcXVUarv1OJFNUggPr2joqvuXnfzPULQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsYz6BSAduUDUOX259ENsI7e3HBFe_L9qqkswLxxp.9W4Mz9nic1fEk3b_JEBlfwrWyjYIBRM6OLFt_OXq_MrKuT9FbPDZoBNzGNE4gztylPle8NHh464vf7titT91WI150sPs4r2y2APILF5Fb_KY7JnWSvrTPQ_RLqzm5WLiQf9amSPLQH7QgRQCakMchLIrk5JAE9E6MSpCwgFRAxbsS5IoGuHu8A6fkZbF1_zU3uRWbbYi8rqUNN 6. http://stripe.rs-1117-a.com/stripe/redirect?cs_email=f34cde757c9729b925454a1cf67de4ac_sendid=1573003918294_esp=threatwave_offset=0_stripeid=2454 7. http://stripe.rs-1117-a.com/stripe/redirect?cs_email=f34cde757c9729b925454a1cf67de4ac_sendid=1573003918294_esp=threatwave_offset=1_stripeid=2454 8. http://stripe.rs-1117-a.com/stripe/redirect?cs_email=f34cde757c9729b925454a1cf67de4ac_sendid=1573003918294_esp=threatwave_offset=2_stripeid=2454 9. http://branding.rs-1117-a.com/?utm_source=contentstripe_medium=email_campaign=rs_2454_content=animatedlogo 10. https://www.betterbounces.net/privacy-policy
[Bug c++/70141] [6 Regression] template parameter not deducible in partial specialization of template inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141
Sori Lee changed:
What|Removed |Added
CC||s.lee at dpmms dot cam.ac.uk
--- Comment #21 from Sori Lee ---
Gcc 9.2.0 refuses to compile the following partial specialisation.
template
struct a {
using type = int;
};
template
struct b;
template
struct b::type> {};
The error it gives reads:
test.cpp:10:8: error: template parameters not deducible in partial
specialization:
10 | struct b::type> {};
|^~
test.cpp:10:8: note: ‘U’
This looks similar to the problem previously discussed on this list, whence I
report it here.
[Bug tree-optimization/92373] [10 Regression] ICE in -Warray-bounds on access to member array in an initialized char buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92373 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Sebor --- Patch committed in r277871.
[Bug tree-optimization/92373] [10 Regression] ICE in -Warray-bounds on access to member array in an initialized char buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92373 --- Comment #2 from Martin Sebor --- Author: msebor Date: Wed Nov 6 01:25:09 2019 New Revision: 277871 URL: https://gcc.gnu.org/viewcvs?rev=277871=gcc=rev Log: PR tree-optimization/92373 - ICE in -Warray-bounds on access to member array in an initialized char buffer gcc/testsuite/ChangeLog: PR tree-optimization/92373 * gcc.dg/Warray-bounds-55.c: New test. * gcc.dg/Wzero-length-array-bounds-2.c: New test. gcc/ChangeLog: PR tree-optimization/92373 * tree.c (component_ref_size): Only consider initializers of objects of matching struct types. Return null for instances of interior zero-length arrays. Added: trunk/gcc/testsuite/gcc.dg/Warray-bounds-55.c trunk/gcc/testsuite/gcc.dg/Wzero-length-array-bounds-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c
[Bug rtl-optimization/92342] [10 Regression] a small missed transformation into x?b:0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92342 --- Comment #10 from Segher Boessenkool --- There are a gazillion ways to write this without if_then_else, none obviously better than any other, and it gets much worse if your b,c have special values. I don't think this optimisation should be done by combine at all. combine has some serious problems doing this. It is closely related to ifcvt, in some ways.
[Bug other/92090] [10 regression] ICE in gcc.dg/atomic/c11-atomic-exec-5.c starting with r276469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92090
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment #8 from Peter Bergner ---
Here's a smaller test case that fails the same way using -Os -mbig:
_Atomic int a;
_Atomic long double b, c;
int j;
void foo (void);
void bar (int, int, int, int);
void
bug (void)
{
b = 1;
int d, e, f, g;
while (a)
;
for (int h = 0; h < 1; h++) {
double i = b /= 3;
foo ();
if (i) {
if (i == 1)
d++;
e++;
b = 0;
} else {
if (i == 2)
f++;
g++;
b = 1;
}
}
bar (d, e, f, g);
c = 1;
for (int h; h; h++)
j = 0;
}
[Bug tree-optimization/92373] [10 Regression] ICE in -Warray-bounds on access to member array in an initialized char buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92373 Martin Sebor changed: What|Removed |Added Keywords||patch Summary|[10 Regression] ICE |[10 Regression] ICE in |get_initializer_for at |-Warray-bounds on access to |gcc/tree.c:13553 since |member array in an |r277728 |initialized char buffer --- Comment #1 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00354.html
[Bug tree-optimization/91825] [10 regression] Bogus -Wmaybe-uninitialized with r275744 breaks bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91825 --- Comment #8 from Jason Merrill --- Author: jason Date: Tue Nov 5 23:53:53 2019 New Revision: 277864 URL: https://gcc.gnu.org/viewcvs?rev=277864=gcc=rev Log: Fix conversions for built-in operator overloading candidates. While working on C++20 operator<=>, I noticed that build_new_op_1 was doing too much conversion when a built-in candidate was selected; the standard says it should only perform user-defined conversions, and then leave the normal operator semantics to handle any standard conversions. This is important for operator<=> because a comparison of two different unscoped enums is ill-formed; if we promote the enums to int here, cp_build_binary_op never gets to see the original operand types, so we can't give the error. I'm also disabling -Wmaybe-uninitialized for expmed.c to avoid the bootstrap failure from the last time I applied this patch. * call.c (build_new_op_1): Don't apply any standard conversions to the operands of a built-in operator. Don't suppress conversions in cp_build_unary_op. * typeck.c (cp_build_unary_op): Do integral promotions for enums. PR tree-optimization/91825 * expmed.c: Reduce -Wmaybe-uninitialized to warning. Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/typeck.c trunk/gcc/expmed.c
[Bug middle-end/92263] [10 Regression] ICE in commit_one_edge_insertion, at cfgrtl.c:2087 since r270758
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92263 Jim Wilson changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #9 from Jim Wilson --- Fixed on mainline. Do you need a backport to the gcc-9 branch?
[Bug middle-end/92263] [10 Regression] ICE in commit_one_edge_insertion, at cfgrtl.c:2087 since r270758
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92263 --- Comment #8 from Jim Wilson --- Author: wilson Date: Tue Nov 5 22:34:40 2019 New Revision: 277861 URL: https://gcc.gnu.org/viewcvs?rev=277861=gcc=rev Log: Allow libcalls for complex memcpy when optimizing for size. The RISC-V backend wants to use a libcall when optimizing for size if more than 6 instructions are needed. Emit_move_complex asks for no libcalls. This case requires 8 insns for rv64 and 16 insns for rv32, so we get fallback code that emits a loop. Commit_one_edge_insertion doesn't allow code inserted for a phi node on an edge to end with a branch, and so this triggers an assertion. This problem goes away if we allow libcalls when optimizing for size, which gives the code the RISC-V backend wants, and avoids triggering the assert. gcc/ PR middle-end/92263 * expr.c (emit_move_complex): Only use BLOCK_OP_NO_LIBCALL when optimize_insn_for_speed_p is true. gcc/testsuite/ PR middle-end/92263 * gcc.dg/pr92263.c: New. Added: trunk/gcc/testsuite/gcc.dg/pr92263.c Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog
[Bug gcov-profile/92382] variable double-definition in routine replace_filename_variables of libgcc/libgcov-driver-system.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92382 --- Comment #7 from qinzhao at gcc dot gnu.org --- I have just created a bug to record the debugging issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92386 (In reply to Jakub Jelinek from comment #6) > Feel free to open an issue against GDB or GCC< wherever the debug info issue > is e.g. for the #c4 testcase. Because certainly I see 0 as the value of v > even when it should be 1 or 2.
[Bug debug/92386] New: gdb issue with variable-shadowing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92386
Bug ID: 92386
Summary: gdb issue with variable-shadowing
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
gdb cannot print the correct value of variables if it's shadowed.
please see the following small testing case for an example:
1 #include
2 int
3 main ()
4 {
5 volatile int v = 0;
6 int i;
7 for (i=0; i < 3; i++)
8 {
9v++;
10v++;
11printf("i = %d outer v 1 is %d\n",i, v);
12volatile int v = 4;
13v++;
14printf("i = %d inner v is %d\n",i, v);
15 }
16 printf("outer v 2 is %d\n", v);
17 }
built it with the latest gcc10 and execute it, no problem:
[qinzhao@localhost ~]$ gcc t.c
[qinzhao@localhost ~]$ ./a.out
i = 0 outer v 1 is 2
i = 0 inner v is 5
i = 1 outer v 1 is 4
i = 1 inner v is 5
i = 2 outer v 1 is 6
i = 2 inner v is 5
outer v 2 is 6
However, when use gdb to check the value of variable v, we will see that at
line 9, 10, the value of "v" is incorrect:
(gdb) run
Starting program: /home/qinzhao/a.out
Breakpoint 1, main () at t.c:9
9 v++;
Missing separate debuginfos, use: debuginfo-install
glibc-2.17-222.ora28641867.1.el7.x86_64
(gdb) print v
$1 = 32767
(gdb) n
10 v++;
(gdb) print v
$2 = 32767
(gdb) n
11 printf("i = %d outer v 1 is %d\n",i, v);
(gdb) n
i = 0 outer v 1 is 2
12 volatile int v = 4;
(gdb) n
13 v++;
(gdb) print v
$3 = 4
(gdb) n
14 printf("i = %d inner v is %d\n",i, v);
(gdb) print v
$4 = 5
(gdb) n
i = 0 inner v is 5
7for (i=0; i < 3; i++)
(gdb) n
Breakpoint 1, main () at t.c:9
9 v++;
(gdb) print v
$5 = 5
(gdb) n
10 v++;
(gdb) print v
$6 = 5
[Bug c++/92385] extremely long and memory intensive compilation for brace construction of array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92385 --- Comment #3 from Carl --- Original "good.cpp" and "bad.cpp" sources now attached.
[Bug rtl-optimization/92342] [10 Regression] a small missed transformation into x?b:0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92342 --- Comment #9 from Richard Earnshaw --- (In reply to Segher Boessenkool from comment #7) > I think the IF_THEN_ELSE version should be canonical, and it should be > formed in simplify_rtx, not at random spots in combine. Why? The and/ior variants are more likely to lead to a useful split if combining 3 insns and it doesn't match.
[Bug c++/92385] extremely long and memory intensive compilation for brace construction of array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92385
--- Comment #2 from Carl ---
Created attachment 47181
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47181=edit
source that does not exhibit bad compilation performance
Note the constructor initializes the member with parens: "item_array() : a()
{}"
[Bug c++/92385] extremely long and memory intensive compilation for brace construction of array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92385
--- Comment #1 from Carl ---
Created attachment 47179
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47179=edit
original source file with bad compilation performance
Note the brace member initialization in the constructor: "item_array() : a{}
{}"
[Bug c++/92365] [10 Regression] ice unexpected expression ‘int16_t()’ of kind cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92365 --- Comment #4 from Bernd Edlinger --- Created attachment 47180 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47180=edit possible fix This seems to fix the issue, although a fix in cxx_eval_constant_expression might be preferrable.
[Bug c++/92385] New: extremely long and memory intensive compilation for brace construction of array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92385
Bug ID: 92385
Summary: extremely long and memory intensive compilation for
brace construction of array member
Product: gcc
Version: 7.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: edquist at cs dot wisc.edu
Target Milestone: ---
Created attachment 47178
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47178=edit
preprocessed source that exhibits bad compilation performance
Greetings!
I stumbled upon strange compiler-performance behavior when initializing an
array member of non-POD type in a struct constructor with the (C++11)
brace-initialization syntax, rather than with parens.
For example, if you have the following types:
struct item {
int i;
item();
};
struct item_array {
item a[SIZE];
item_array();
};
I am referring to defining the item_array constructor as:
item_array::item_array() : a{} {}
Instead of:
item_array::item_array() : a() {}
In the case with the brace initializer, especially if SIZE is non-trivial (eg,
100s of thousands), the compiler takes an inordinately long time and much
memory to compile a trivial piece of code, where with the parens instead it
compiles instantly and with very little memory used.
I've boiled it down to a very simple program, which does not #include any
headers. The (not attached) source file "good.cpp" uses the parens, and
compiles instantly, where the (not attached) "bad.cpp", which differs only in
that it uses brace initialization rather than parens, takes 58 seconds to
compile, with the max resident set size of g++ at nearly 3GB. (This is with
SIZE=512*1024)
(I guess I can only attach a single file, and that is supposed to be the
preprocessed "bad.ii", so that's the one attached.)
If I increase the array length from 512k to 1024k (which has 4MB total size,
with sizeof (int) == 4), then g++ runs furiously for some time and eventually
crashes.
Again, with parens instead of braces, the problem goes away. But I have no
idea why this would be, as I thought the behavior would be equivalent.
Is this (kind of terrible) performance/behavior expected?
Thanks!
Carl
Bug report details:
Compile with:
g++ -O3 -Wall -std=c++11 bad.cpp -o bad
I've also tried compiling with and without the options mentioned on the
"Reporting Bugs" page (-Wall -Wextra -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations -fsanitize=undefined) as well as with and
without optimization (-O3), none of which cause the bad compilation performance
to go away.
When it does compile though, it compiles without any output, even with "-Wall
-Wextra".
If I collect the "time" and rusage data from the above compilation step, I get:
rtime: 58.421
utime: 57.607
stime: 0.798
maxrss: 2925112k
Compared to compiling "good.cpp" (which only changes "a{}" to "a()"), I get:
rtime: 0.076
utime: 0.047
stime: 0.007
maxrss: 23120k
I've also compiled with "-save-temps" and am attaching the requested (*.i*)
preprocessed file, which is "bad.ii".
Version detail:
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.4.0-1ubuntu1~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1)
[Bug tree-optimization/92373] [10 Regression] ICE get_initializer_for at gcc/tree.c:13553 since r277728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92373 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 92363, which changed state. Bug 92363 Summary: wrong subscript value printed when indexing into an empty array https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92363 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug middle-end/92363] wrong subscript value printed when indexing into an empty array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92363 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Target Milestone|--- |10.0 Known to fail||7.3.0, 8.3.0, 9.2.0 --- Comment #1 from Martin Sebor --- Fixed for GCC 10 via r277851.
[Bug middle-end/92384] [8/9/10 Regression] Empty class instances have different equal testing result among GCC versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92384 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Component|c++ |middle-end --- Comment #3 from Jason Merrill --- assign_parms should probably give empty parms locations independent of the parameter passing area.
[Bug c++/92384] [8/9/10 Regression] Empty class instances have different equal testing result among GCC versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92384
--- Comment #2 from Jonathan Wakely ---
Reduced:
class Empty {};
bool is_same(Empty a, Empty b)
{
__builtin_printf("%p\n%p\n", , );
void* v[] = { , };
return v[0] == v[1];
}
int main() {
Empty a, b;
if (is_same(a, b))
__builtin_abort();
}
0x7ffc7b54ad20
0x7ffc7b54ad20
Aborted (core dumped)
[Bug c++/92384] [8/9/10 Regression] Empty class instances have different equal testing result among GCC versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92384 Jonathan Wakely changed: What|Removed |Added Keywords||ABI Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-05 Known to work||7.4.0 Summary|Empty class instances have |[8/9/10 Regression] Empty |different equal testing |class instances have |result among GCC versions |different equal testing ||result among GCC versions Ever confirmed|0 |1 Known to fail||10.0, 8.3.0, 9.2.0 --- Comment #1 from Jonathan Wakely --- This started with the -fabi-version=12 introduced in GCC 8
[Bug c++/92338] double/float thought (ambiguous) candidate for C-array index. (Non numeric types aren't.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92338 --- Comment #10 from Jonathan Wakely --- Can you please stop changing the status to FIXED. That means a bug in GCC was fixed. Since nothing in GCC changed, nothing has been fixed. I think all compilers are trying to convert the object to std::ptrdiff_t, which is long or long long depending on the platform.
[Bug tree-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283 --- Comment #7 from Martin Liška --- @Richi: May I please remind you this issue? Is the debugging patching helping to isolate the issue?
[Bug c++/92384] New: Empty class instances have different equal testing result among GCC versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92384
Bug ID: 92384
Summary: Empty class instances have different equal testing
result among GCC versions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: michael.hliao at gmail dot com
Target Milestone: ---
Created attachment 47177
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47177=edit
sources and compilation script
Instances of an empty class should be regarded as different objects. Equal
testing should return false. However, equal testing through a function has
different results from gcc-7 to gcc-9.
The test code
```
#include
class Empty {};
bool is_same(Empty a, Empty b);
int main() {
Empty a, b;
if ( == )
std::cout << "SAME EMPTY\n";
else
std::cout << "DIFF EMTPY\n";
if (is_same(a, b))
std::cout << "SAME EMPTY\n";
else
std::cout << "DIFF EMTPY\n";
}
```
equal-test| gcc-7 | gcc-8 | gcc-9
--+---+---+--
inline| DIFF | DIFF | DIFF
function | DIFF | SAME | SAME
find the source and compilation scripts in the attachment.
[Bug target/92379] rs6000.c:5598:13: runtime error: shift exponent 64 is too large for 64-bit type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92379 --- Comment #3 from Segher Boessenkool --- Sure. But it still is harmless, and a special build config. Which isn't to say it shouldn't be fixed. But it isn't very high on the list, that's all.
[Bug c/92380] Bogus -Warray-bounds warning with structures, one of which has a flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92380
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #1 from Martin Sebor ---
The warning was introduced in r275981 which was an enhancement to detect more
instances of inadvertent accesses past the end of struct members. It might be
possible to relax the warning to handle some of these cases but I'm not
convinced it's a good idea or worth the trouble for code that does these sorts
of type-punning tricks.
I suggest to rewrite the code in a more straightforward way and without the
casts, e.g., like so:
char *t1 (outer_struct *p, char str[240])
{
char *q = (char*)p + sizeof *p - (sizeof(inner_large_struct) -
sizeof(inner_small_struct)) + offsetof (flexarr_struct, s);
__builtin_strcpy (q, str);
return q;
}
When starting with a pointer to the the enclosing object GCC treats as valid
accesses to the whole object if it's known (or to the largest array of such
objects when it isn't). Otherwise, only accesses to the same member are
considered valid when using a pointer derived from the address of that member.
[Bug gcov-profile/92382] variable double-definition in routine replace_filename_variables of libgcc/libgcov-driver-system.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92382 --- Comment #6 from Jakub Jelinek --- Feel free to open an issue against GDB or GCC< wherever the debug info issue is e.g. for the #c4 testcase. Because certainly I see 0 as the value of v even when it should be 1 or 2.
[Bug target/92379] rs6000.c:5598:13: runtime error: shift exponent 64 is too large for 64-bit type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92379 --- Comment #2 from Martin Liška --- (In reply to Segher Boessenkool from comment #1) > That's when building the compiler with -O0 only. I also see it when doing a normal bootstrap with --with-build-config=bootstrap-asan. Which should use -O2 -fsanitize=undefined in stage2 and stage3.
[Bug gcov-profile/92382] variable double-definition in routine replace_filename_variables of libgcc/libgcov-driver-system.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92382 --- Comment #5 from qinzhao at gcc dot gnu.org --- Okay, I see. thank you for explanation. I will close this one as not a bug. (In reply to Jakub Jelinek from comment #4)
[Bug target/92379] rs6000.c:5598:13: runtime error: shift exponent 64 is too large for 64-bit type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92379 Segher Boessenkool changed: What|Removed |Added Priority|P3 |P5 --- Comment #1 from Segher Boessenkool --- That's when building the compiler with -O0 only.
[Bug c++/92338] double/float thought (ambiguous) candidate for C-array index. (Non numeric types aren't.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92338 Andreas Schwab changed: What|Removed |Added Resolution|FIXED |INVALID
[Bug c++/92367] spurious -Wunused-but-set-parameter warning with constexpr if in a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92367 --- Comment #2 from Born Togo <60rntogo at gmail dot com> --- That's perfect. For what it's worth, I did try searching for this bug report first, but somehow didn't find it. Sorry for littering.
[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886 --- Comment #5 from Segher Boessenkool --- So: -- LLVM should support "wa", since that is *the* constraint for VSX registers. -- musl should use the "wa" constraint in its inline asm. -- If after those two you still want "ws" (for compiling legacy code, say), I can add that back to GCC 10 (it will do just the same as "wa"). Is that a plan?
[Bug gcov-profile/92382] variable double-definition in routine replace_filename_variables of libgcc/libgcov-driver-system.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92382
--- Comment #4 from Jakub Jelinek ---
This boils down to
int
main ()
{
volatile int v = 0;
{
v++;
v++;
volatile int v = 4;
v++;
}
}
>From what I see, this is handled correctly in the generated code, so it is just
the debugging issue.
[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886 --- Comment #4 from Segher Boessenkool --- Yes, you should use "wa". Making our constraint (and output modifier) doc more useful is on my list for GCC 10.
[Bug c++/92338] double/float thought (ambiguous) candidate for C-array index. (Non numeric types aren't.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92338 Mick P. changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #9 from Mick P. --- I began to wonder if MSVC was just treating int as the right match in 32-bit mode. I did tests, with my open VS2015, in 32-bit mode, that compiled all signed integer types, but refused to accept unsigned types (or float or double.) It does accept unsigned variables, but not conversion operators. The https://godbolt.org/z/Q54kFs link does the same in 32-bit (x86) mode. It only accepts long long int in x64 mode. It seems pretty arbitrary honestly. I'm sure compilers can do better. The MS compiler's error code is: no global [] operator accepts the class type... paraphrasing. Converting to arbitrary int family types is lazy in both cases. The semantics for a C-array are to search for any int type. That's how it should be implemented. If it's supposed to mimic overloaded operator[] then it should convert double/float to a signed int type, including pointer indexing. (I thought MSVC's case was more sensible than it actually is. The x64 behavior is actually pretty weird. A workaround is conversion via template, but it makes for a much more unwieldy interface, if feasible. My use-case is a GUI framework, so that the elements are data oriented. They are represented graphically, but are also fields that easily convert to a string, int, or double. The boolean type converts to bool, but the other elements are implicit-conversion to bool only. It's clean that way. But it will have to convert to any integer type if it's going to be used an index.)
[Bug gcov-profile/92382] variable double-definition in routine replace_filename_variables of libgcc/libgcov-driver-system.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92382 --- Comment #3 from Jakub Jelinek --- Most likely just GDB doesn't handle it correctly, or a bug in what we emit as debug info for it (for -O0 it wouldn't surprise me, as we don't really track the scope of the variable).
[Bug c++/92375] Warn on suspicious taking of function address instead of calling a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92375 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (In reply to Richard Biener from comment #1) > Sounds useful. +1, I think I've done this before...
[Bug gcov-profile/92382] variable double-definition in routine replace_filename_variables of libgcc/libgcov-driver-system.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92382 --- Comment #2 from qinzhao at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #1) > Why is this a major issue? Just variable shadowing, so something that with > -Wshadow* compiler will warn, but nothing more, the code is well defined, > isn't it? when you print the value of "buffer" inside gdb at line 161, it's NULL, not a buffer with size 16. As a result, the sprint (buffer, "%d", get pic ()) at line 161 will write the processID to a NULL buffer, is this correct?
[Bug target/91289] powerpc-eabi: Usage of -fstack-limit-symbol leads to internal compiler error during RTL pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #18 from Segher Boessenkool --- Fixed on trunk, 9, 8. Closing.
[Bug target/91289] powerpc-eabi: Usage of -fstack-limit-symbol leads to internal compiler error during RTL pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289 --- Comment #17 from Segher Boessenkool --- Author: segher Date: Tue Nov 5 17:20:00 2019 New Revision: 277856 URL: https://gcc.gnu.org/viewcvs?rev=277856=gcc=rev Log: backport for PR91289 Backport from trunk 2019-10-26 Segher Boessenkool PR target/91289 * config/rs6000/rs6000.c (rs6000_emit_allocate_stack): Don't add an immediate to r0; use r11 instead. Save and restore r11 to r0 around this. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/rs6000/rs6000.c
[Bug target/91289] powerpc-eabi: Usage of -fstack-limit-symbol leads to internal compiler error during RTL pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289 --- Comment #16 from Segher Boessenkool --- Author: segher Date: Tue Nov 5 17:17:03 2019 New Revision: 277855 URL: https://gcc.gnu.org/viewcvs?rev=277855=gcc=rev Log: backport for PR91289 Backport from trunk 2019-10-26 Segher Boessenkool PR target/91289 * config/rs6000/rs6000.c (rs6000_emit_allocate_stack): Don't add an immediate to r0; use r11 instead. Save and restore r11 to r0 around this. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/config/rs6000/rs6000.c
[Bug gcov-profile/92382] variable double-definition in routine replace_filename_variables of libgcc/libgcov-driver-system.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92382 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Why is this a major issue? Just variable shadowing, so something that with -Wshadow* compiler will warn, but nothing more, the code is well defined, isn't it?
[Bug tree-optimization/82608] missing -Warray-bounds on an out-of-bounds VLA index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82608 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-05 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Martin Sebor --- A partial fix (https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00179.html) committed in r277854. Out-of-bounds indices into VLAs with Non-constant sizes are not handled yet.
[Bug middle-end/92333] missing variable name referencing VLA in warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92333 Martin Sebor changed: What|Removed |Added Keywords||patch Status|ASSIGNED|RESOLVED Known to work||10.0 Resolution|--- |FIXED Target Milestone|--- |10.0 Known to fail||7.3.0, 8.3.0, 9.2.0 --- Comment #3 from Martin Sebor --- Patch (https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00179.html) committed in r277854.
[Bug middle-end/92333] missing variable name referencing VLA in warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92333 --- Comment #2 from Martin Sebor --- Author: msebor Date: Tue Nov 5 17:05:33 2019 New Revision: 277854 URL: https://gcc.gnu.org/viewcvs?rev=277854=gcc=rev Log: PR middle-end/92333 - missing variable name referencing VLA in warnings PR middle-end/82608 - missing -Warray-bounds on an out-of-bounds VLA index gcc/testsuite/ChangeLog: PR middle-end/92333 PR middle-end/82608 * gcc.dg/Warray-bounds-51.c: New test. gcc/ChangeLog: PR middle-end/92333 PR middle-end/82608 * tree-vrp.c (vrp_prop::check_array_ref): Handle VLAs with constant size. * tree-ssa-ccp.c (fold_builtin_alloca_with_align): Use a meaninful name and location for a temporary variable. Added: trunk/gcc/testsuite/gcc.dg/Warray-bounds-51.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c trunk/gcc/tree-vrp.c
[Bug tree-optimization/82608] missing -Warray-bounds on an out-of-bounds VLA index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82608 --- Comment #2 from Martin Sebor --- Author: msebor Date: Tue Nov 5 17:05:33 2019 New Revision: 277854 URL: https://gcc.gnu.org/viewcvs?rev=277854=gcc=rev Log: PR middle-end/92333 - missing variable name referencing VLA in warnings PR middle-end/82608 - missing -Warray-bounds on an out-of-bounds VLA index gcc/testsuite/ChangeLog: PR middle-end/92333 PR middle-end/82608 * gcc.dg/Warray-bounds-51.c: New test. gcc/ChangeLog: PR middle-end/92333 PR middle-end/82608 * tree-vrp.c (vrp_prop::check_array_ref): Handle VLAs with constant size. * tree-ssa-ccp.c (fold_builtin_alloca_with_align): Use a meaninful name and location for a temporary variable. Added: trunk/gcc/testsuite/gcc.dg/Warray-bounds-51.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c trunk/gcc/tree-vrp.c
[Bug c++/92370] [10 Regression] ICE in cp_lexer_consume_token, at cp/parser.c:1118
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92370 --- Comment #3 from Nathan Sidwell --- Author: nathan Date: Tue Nov 5 16:59:41 2019 New Revision: 277853 URL: https://gcc.gnu.org/viewcvs?rev=277853=gcc=rev Log: [PR c++/92370] ICE with VC marker https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00323.html cp/ PR c++/92370 * parser.c (cp_parser_error_1): Check EOF and UNKNOWN_LOCATION when skipping over version control marker. testsuite/ PR c++/92370 * g++.dg/pr92370.C: New. Added: trunk/gcc/testsuite/g++.dg/pr92370.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/92370] [10 Regression] ICE in cp_lexer_consume_token, at cp/parser.c:1118
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92370 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Nathan Sidwell --- Fixed r277853.
[Bug c/92383] New: ICE: in refs_may_alias_p_1, at tree-ssa-alias.c:1519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92383
Bug ID: 92383
Summary: ICE: in refs_may_alias_p_1, at tree-ssa-alias.c:1519
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mpoulhies at kalray dot eu
Target Milestone: ---
Giving this to all GCC on godbolt.org (9.2 to 4.1.2) :
#include
int main (int argc, char **argv) {
struct S {
char toto[argc];
};
int f (struct S arg) {
strcpy(arg.toto, argv[0]);
return arg.toto[10];
}
struct S bob;
strcpy(bob.toto, "coucoucoucou");
return f(bob);
}
Raises an ICE (the line corresponds to the 9.2
during GIMPLE pass: dse
: In function 'main':
:15:1: internal compiler error: in refs_may_alias_p_1, at
tree-ssa-alias.c:1519
15 | }
| ^
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 82612, which changed state. Bug 82612 Summary: missing -Warray-bounds on a non-zero offset from the address of a non-array object https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82612 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/82612] missing -Warray-bounds on a non-zero offset from the address of a non-array object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82612 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Sebor --- With r277851 check in, the PARM_DECL case is detected as well.
[Bug target/92361] [8/9 Regression] failing fortran libcgns test on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92361 Thomas Koenig changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #7 from Thomas Koenig --- Closing then. I cannot test this myself at the moment, but you can try running your code through current trunk to see what errors you get. And thanks for reporting this, even if this turned out to be invalid.
[Bug gcov-profile/92382] New: variable double-definition in routine replace_filename_variables of libgcc/libgcov-driver-system.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92382
Bug ID: 92382
Summary: variable double-definition in routine
replace_filename_variables of
libgcc/libgcov-driver-system.c
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
In the routine replace_filename_variables of libgcc/libgcov-driver-system.c:
145 static char *
146 replace_filename_variables (char *filename)
147 {
148 char buffer[16];
149 char empty[] = "";
150 for (char *p = filename; *p != '\0'; p++)
151 {
152 unsigned length = strlen (filename);
153 if (*p == '%' && *(p + 1) != '\0')
154 {
155 unsigned start = p - filename;
156 p++;
157 char *replacement = NULL;
158 switch (*p)
159 {
160 case 'p':
161 sprintf (buffer, "%d", getpid ());
162 replacement = buffer;
163 p++;
164 break;
165 case 'q':
166 if (*(p + 1) == '{')
167 {
168 p += 2;
169 char *e = strchr (p, '}');
170 if (e)
171 {
172 *e = '\0';
173 replacement = getenv (p);
174 if (replacement == NULL)
175 replacement = empty;
176 p = e + 1;
177 }
178 else
179 return filename;
180 }
181 break;
182 default:
183 return filename;
184 }
185
186 /* Concat beginning of the path, replacement and
187 ending of the path. */
188 unsigned end = length - (p - filename);
189 unsigned repl_length = replacement != NULL ? strlen (replacement)
: 0;
190
191 char *buffer = (char *)xmalloc (start + end + repl_length + 1);
192 char *buffer_ptr = buffer;
193 buffer_ptr = (char *)memcpy (buffer_ptr, filename, start);
194 buffer_ptr += start;
195 if (replacement != NULL)
196 buffer_ptr = (char *)memcpy (buffer_ptr, replacement,
repl_length);
197 buffer_ptr += repl_length;
198 buffer_ptr = (char *)memcpy (buffer_ptr, p, end);
199 buffer_ptr += end;
200 *buffer_ptr = '\0';
201
202 free (filename);
203 filename = buffer;
204 p = buffer + start + repl_length;
205 }
206 }
207
208 return filename;
209 }
The major issue in the above code is: the "buffer" is redefined:
At line 148, "buffer" is defined outside the loop, the intend usage of this
"buffer" is at line 161 and 162 to hold the process id string for the
replacement of "%p";
However, At line 191, inside this same loop, "buffer" is defined again and
initialized to hold the new name of the whole filename, and the lifetime of
this "buffer" will overwrite the other "buffer" defined outside of the loop.
the fix to this problem is to rename the second "buffer" of line 183 to
another different name.
[Bug tree-optimization/92341] missing -Warray-bounds indexing past the end of a compound literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92341 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||10.0 Resolution|--- |FIXED Target Milestone|--- |10.0 Known to fail||7.3.0, 8.3.0, 9.2.0 --- Comment #5 from Martin Sebor --- Fixed in r277851.
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 92341, which changed state. Bug 92341 Summary: missing -Warray-bounds indexing past the end of a compound literal https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92341 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/82612] missing -Warray-bounds on a non-zero offset from the address of a non-array object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82612 --- Comment #4 from Martin Sebor --- Author: msebor Date: Tue Nov 5 16:20:44 2019 New Revision: 277851 URL: https://gcc.gnu.org/viewcvs?rev=277851=gcc=rev Log: PR middle-end/92341 - missing -Warray-bounds indexing past the end of a compound literal PR middle-end/82612 - missing -Warray-bounds on a non-zero offset from the address of a non-array object gcc/testsuite/ChangeLog: PR middle-end/92341 PR middle-end/82612 * g++.dg/warn/Warray-bounds-4.C: Adjust text of expected warning. * gcc.dg/Warray-bounds-53.c: New test. * gcc.dg/Warray-bounds-54.c: New test. gcc/ChangeLog: PR middle-end/92341 PR middle-end/82612 * tree-sra.c (get_access_for_expr): Fail for out-of-bounds offsets. * tree-vrp.c (vrp_prop::check_array_ref): Correct index and text of message printed in a warning for empty arrays. (vrp_prop::check_mem_ref): Also handle function parameters and empty arrays. Added: trunk/gcc/testsuite/gcc.dg/Warray-bounds-53.c trunk/gcc/testsuite/gcc.dg/Warray-bounds-54.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/warn/Warray-bounds-4.C trunk/gcc/tree-sra.c trunk/gcc/tree-vrp.c
[Bug tree-optimization/92341] missing -Warray-bounds indexing past the end of a compound literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92341 --- Comment #4 from Martin Sebor --- Author: msebor Date: Tue Nov 5 16:20:44 2019 New Revision: 277851 URL: https://gcc.gnu.org/viewcvs?rev=277851=gcc=rev Log: PR middle-end/92341 - missing -Warray-bounds indexing past the end of a compound literal PR middle-end/82612 - missing -Warray-bounds on a non-zero offset from the address of a non-array object gcc/testsuite/ChangeLog: PR middle-end/92341 PR middle-end/82612 * g++.dg/warn/Warray-bounds-4.C: Adjust text of expected warning. * gcc.dg/Warray-bounds-53.c: New test. * gcc.dg/Warray-bounds-54.c: New test. gcc/ChangeLog: PR middle-end/92341 PR middle-end/82612 * tree-sra.c (get_access_for_expr): Fail for out-of-bounds offsets. * tree-vrp.c (vrp_prop::check_array_ref): Correct index and text of message printed in a warning for empty arrays. (vrp_prop::check_mem_ref): Also handle function parameters and empty arrays. Added: trunk/gcc/testsuite/gcc.dg/Warray-bounds-53.c trunk/gcc/testsuite/gcc.dg/Warray-bounds-54.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/warn/Warray-bounds-4.C trunk/gcc/tree-sra.c trunk/gcc/tree-vrp.c
[Bug tree-optimization/86611] missing -Warray-bounds on a large negative index into a string in lp64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86611 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-05 Ever confirmed|0 |1 Known to fail||10.0, 7.3.0, 8.3.0, 9.2.0 --- Comment #5 from Martin Sebor --- -Warray-bounds never caught these bugs.
[Bug tree-optimization/92371] [10 Regression] ICE in info_for_reduction, at tree-vect-loop.c:4106
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92371 --- Comment #4 from Richard Biener --- Author: rguenth Date: Tue Nov 5 16:12:07 2019 New Revision: 277850 URL: https://gcc.gnu.org/viewcvs?rev=277850=gcc=rev Log: 2019-11-05 Richard Biener PR tree-optimization/92371 * tree-vect-loop.c (vectorizable_reduction): Set STMT_VINFO_REDUC_DEF on the original stmt of live stmts in the chain. (vectorizable_live_operation): Look at the original stmt when checking STMT_VINFO_REDUC_DEF. * gcc.dg/torture/pr92371.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr92371.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/92371] [10 Regression] ICE in info_for_reduction, at tree-vect-loop.c:4106
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92371 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug middle-end/92381] missing -Warray-bounds on negative index with very large magnitude
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92381 Martin Sebor changed: What|Removed |Added Keywords||diagnostic See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=86611 Blocks||56456 --- Comment #1 from Martin Sebor --- See also pr86611 for a similar test case with apparently yet another root cause. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 [Bug 56456] [meta-bug] bogus/missing -Warray-bounds
[Bug middle-end/92381] New: missing -Warray-bounds on negative index with very large magnitude
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92381
Bug ID: 92381
Summary: missing -Warray-bounds on negative index with very
large magnitude
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
More extensive testing of the fix for pr92341 reveals that yet another
optimization gets in the way of diagnosing negative out-of-bounds indices with
a very large magnitude:
$ cat b.c && gcc -O2 -S -Wall -fdump-tree-ccp1-details=/dev/stdout b.c
int f (void)
{
int *p = (int[]){ 1 };
__PTRDIFF_TYPE__ i = -__PTRDIFF_MAX__ - 1;
return p[i]; // missing warning
}
;; Function f (f, funcdef_no=0, decl_uid=1930, cgraph_uid=1, symbol_order=0)
Adding destination of edge (0 -> 2) to worklist
Simulating block 2
Visiting statement:
p_6 =
which is likely CONSTANT
Lattice value changed to CONSTANT Adding SSA edges to worklist.
marking stmt to be not simulated again
Visiting statement:
i_7 = -9223372036854775808;
which is likely CONSTANT
Lattice value changed to CONSTANT -9223372036854775808. Adding SSA edges to
worklist.
marking stmt to be not simulated again
Visiting statement:
i.0_1 = (long unsigned int) i_7;
which is likely CONSTANT
Match-and-simplified (long unsigned int) i_7 to 9223372036854775808
Lattice value changed to CONSTANT 9223372036854775808. Adding SSA edges to
worklist.
marking stmt to be not simulated again
Visiting statement:
_2 = i.0_1 * 4;
which is likely CONSTANT
Match-and-simplified i.0_1 * 4 to 0
Lattice value changed to CONSTANT 0. Adding SSA edges to worklist.
marking stmt to be not simulated again
Visiting statement:
_3 = p_6 + _2;
which is likely CONSTANT
Match-and-simplified p_6 + _2 to
Lattice value changed to CONSTANT Adding SSA edges to worklist.
marking stmt to be not simulated again
Visiting statement:
_8 = *_3;
which is likely CONSTANT
Lattice value changed to VARYING. Adding SSA edges to worklist.
Visiting statement:
return _8;
No interesting values produced. Marked VARYING.
Substituting values and folding statements
Folding statement: D.1933[0] = 1;
Not folded
Folding statement: _8 = *_3;
Folded into: _8 = MEM[(int *)];
Folding statement: D.1933 ={v} {CLOBBER};
Not folded
Folding statement: return _8;
Not folded
Removing dead stmt _3 = p_6 + _2;
Removing dead stmt _2 = i.0_1 * 4;
Removing dead stmt i.0_1 = (long unsigned int) i_7;
Removing dead stmt i_7 = -9223372036854775808;
Removing dead stmt p_6 =
No longer having address taken: D.1933
f ()
{
long int i;
int D.1933[1];
int * p;
int _8;
:
D.1933[0] = 1;
_8 = MEM[(int *)];
D.1933 ={v} {CLOBBER};
return _8;
}
[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886 Rich Felker changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #3 from Rich Felker --- The affected code is in musl and I'd like to get this resolved. Are there different constraints we should be using instead here, or is this a bug that will be fixed on the GCC side?
[Bug rtl-optimization/87047] [7/8/9 Regression] performance regression because of if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87047 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #17 from Jeffrey A. Law --- I'd be hesitant to backport performance work to the branch. But the release managers have the final say.
[Bug c++/92374] Unable to link relocatable object when GCC is configured with "--disable-comdat"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92374 --- Comment #2 from Andrew Pinski --- Why are you configuring GCC with disable-comdat in the first place on an elf target?
[Bug c/92380] New: Bogus -Warray-bounds warning with structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92380
Bug ID: 92380
Summary: Bogus -Warray-bounds warning with structures
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
Created attachment 47176
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47176=edit
testcase
This code:
typedef struct {
char cs[256];
} inner_small_struct;
typedef struct {
char cl[512];
} inner_large_struct;
typedef union {
inner_large_struct large;
inner_small_struct small;
} inner_union;
typedef struct {
int y;
inner_union inner;
} outer_struct;
typedef struct {
int x;
char s[];
} flexarr_struct;
char *t1(outer_struct *p, char str[240])
{
flexarr_struct *l = (flexarr_struct *) ((char *) p + sizeof(*p) -
(sizeof(inner_large_struct) - sizeof(inner_small_struct)));
__builtin_strcpy(l->s, str);
return l->s;
}
warns with trunk@277817 like that:
> gcc-trunk -c -O2 -W -Wall -Warray-bounds=1 testcase.c
testcase.c: In function 't1':
testcase.c:28:2: warning: '__builtin_strcpy' offset 264 from the object at 'p'
is out of the bounds of referenced subobject 's' with type 'char[0]' at offset
264 [\-Warray-bounds=\]
28 | __builtin_strcpy(l->s, str);
| ^~~
testcase.c:22:7: note: subobject 's' declared here
22 | char s[];
| ^
Since gcc already knows about 'p' and the offset, it should also consider
sizeof(*p) when deciding to warn. Otherwise it's unfortunate that a flexible
array (compared to a size 1 array s[1]) suppresses UBSAN warnings, but
-Warray-bounds now warns.
[Bug middle-end/92378] missing -Warray-bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92378
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||msebor at gcc dot gnu.org
Component|c |middle-end
Resolution|--- |DUPLICATE
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Target Milestone|--- |10.0
--- Comment #1 from Martin Sebor ---
The cause of the missing -Warray-bounds warning is that the SRA pass
substitutes an uninitialized scalar variable for a[3]. I'm not sure why
-Wuninitialized doesn't point to the variable, but the fix for pr92341 I'm
about to commit corrects this as well and has GCC output the following:
pr92378.c: In function ‘main’:
pr92378.c:5:5: warning: array subscript 3 is above array bounds of ‘int[1]’
[-Warray-bounds]
5 | printf("%d", a[3]);
| ^~
pr92378.c:4:9: note: while referencing ‘a’
4 | int a[1]={0};
| ^
In GCC, -Warray-bounds only runs with optimization so the bug isn't detected
otherwise even in simple cases. In a future release (maybe GCC 11) we'd like
to change it so the simple cases can be diagnosed even without optimization.
*** This bug has been marked as a duplicate of bug 92341 ***
[Bug tree-optimization/92341] missing -Warray-bounds indexing past the end of a compound literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92341 Martin Sebor changed: What|Removed |Added CC||tangyixuan at mail dot dlut.edu.cn --- Comment #3 from Martin Sebor --- *** Bug 92378 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 92378, which changed state. Bug 92378 Summary: missing -Warray-bounds warning https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92378 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug target/92361] [8/9 Regression] failing fortran libcgns test on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92361 --- Comment #6 from Steve Kargl --- On Tue, Nov 05, 2019 at 10:17:50AM +, gilles.filippini at free dot fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92361 > > --- Comment #5 from Gilles Filippini --- > Created attachment 47175 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47175=edit > Tentative self-contained test case for PR92361 > > Here is a tentative self-contained test case, made after the original > cgread_f03 test from libcgns. Thanks for the testcase. This confirms Thomas speculation that you are calling a vararg C function from Fortran. That is not supported by the Fortran standard nor by gfortran as an extension. The subroutine calls in the Fortran code looks as if the subroutine uses optional arguments, but that then would require an explicit interface for the subroutine. Your code does not have an explicit interface. In other words, this PR should be closed as INVALID.
[Bug fortran/92277] [10 Regression] ICE with assumed rank in gfc_conv_gfc_desc_to_cfi_desc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92277 --- Comment #6 from Tobias Burnus --- (In reply to Tobias Burnus from comment #4) > The test case was also added to the GCC 9 branch - where it passes without > requiring a compiler patch. Spoke to early - it was needed for arm and aarch64 as PR 92208 comment 8 showed. Hence, the compiler part of the patch is now also in GCC 9.
[Bug c++/92365] [10 Regression] ice unexpected expression ‘int16_t()’ of kind cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92365 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- potential_constant_expression_1 handles CAST_EXPR (and *_CAST_EXPR), but cxx_evaluate_constant_expression doesn't. This is on a CAST_EXPR which has NULL first operand created by can_convert: /* implicit_conversion only considers user-defined conversions if it has an expression for the call argument list. */ if (CLASS_TYPE_P (from) || CLASS_TYPE_P (to)) arg = build1 (CAST_EXPR, from, NULL_TREE); In particular, NULL_TREE is considered to be a potential constant expression and we fall through into: return (RECUR (TREE_OPERAND (t, 0), !TYPE_REF_P (TREE_TYPE (t; in the CAST_EXPR: handling in potential_constant_expression_1, so return true.
[Bug middle-end/92377] [7/8 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92377 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Richard Biener --- Thus duplicate. *** This bug has been marked as a duplicate of bug 89280 ***
[Bug tree-optimization/89280] [7/8 Regression] ICE: Segmentation fault (in is_gimple_reg_type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89280 Richard Biener changed: What|Removed |Added CC||anbu1024.me at gmail dot com --- Comment #13 from Richard Biener --- *** Bug 92377 has been marked as a duplicate of this bug. ***
[Bug libstdc++/92376] [9/10 Regression] bootstrap fails with --disable-hosted-libstdcxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92376 --- Comment #1 from Jonathan Wakely --- After fixing that, there's still a problem, as isn't installed for freestanding: In file included from /home/jwakely/gcc/freestanding/include/c++/10.0.0/version:35, from :1: /home/jwakely/gcc/freestanding/include/c++/10.0.0/powerpc64le-unknown-linux-gnu/bits/c++config.h:679:10: fatal error: pstl/pstl_config.h: No such file or directory 679 | #include | ^~~~ compilation terminated. The install-freestanding-headers target could create that as an empty file.
[Bug fortran/92277] [10 Regression] ICE with assumed rank in gfc_conv_gfc_desc_to_cfi_desc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92277 --- Comment #5 from Tobias Burnus --- Author: burnus Date: Tue Nov 5 14:28:07 2019 New Revision: 277840 URL: https://gcc.gnu.org/viewcvs?rev=277840=gcc=rev Log: PR 92208 + PR 92277 – GCC 9 follow-up fix PR fortran/92208 Backport from mainline 2019-10-31 Tobias Burnus PR fortran/92277 * trans-expr.c (gfc_conv_gfc_desc_to_cfi_desc): Fix DECL_ARTIFICIAL checking. Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/trans-expr.c
[Bug fortran/92208] [9/10 Regression] internal compile error, character array of dynamic length returned from function and passed to subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92208 --- Comment #10 from Tobias Burnus --- Author: burnus Date: Tue Nov 5 14:28:07 2019 New Revision: 277840 URL: https://gcc.gnu.org/viewcvs?rev=277840=gcc=rev Log: PR 92208 + PR 92277 – GCC 9 follow-up fix PR fortran/92208 Backport from mainline 2019-10-31 Tobias Burnus PR fortran/92277 * trans-expr.c (gfc_conv_gfc_desc_to_cfi_desc): Fix DECL_ARTIFICIAL checking. Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/trans-expr.c
[Bug c++/88075] [feature-request] allow "concept" instead of "concept bool" with -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88075 --- Comment #6 from Hannes Hauswedell --- (In reply to Jason Merrill from comment #5) > Author: jason > Date: Tue Nov 5 11:46:54 2019 > New Revision: 277825 > > URL: https://gcc.gnu.org/viewcvs?rev=277825=gcc=rev > Log: > PR c++/88075 - Don't require 'bool' in a concept definition. > > * parser.c (cp_parser_decl_specifier_seq): Support C++20 > concept-definition syntax without 'bool'. > > Added: > branches/gcc-8-branch/gcc/testsuite/g++.dg/concepts/no-bool1.C > Modified: > branches/gcc-8-branch/gcc/cp/ChangeLog > branches/gcc-8-branch/gcc/cp/parser.c Thanks a lot for this change! Does this work with -fconcepts and if yes can we also get it for GCC7? Thanks a lot!
[Bug fortran/92208] [9/10 Regression] internal compile error, character array of dynamic length returned from function and passed to subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92208 --- Comment #9 from Christophe Lyon --- (In reply to Tobias Burnus from comment #8) > (In reply to Christophe Lyon from comment #7) > > On gcc-9, the patch introduced regressions, seen on arm and aarch64: > > On trunk, the following was needed (PR92277, r277661) – but I it did > not trigger on the branch with x86_64. Seemingly, for arm and aarch64 > it does trigger. > > Can you try the following patch? (Re-diffed for GCC 9): > I confirm this patch fixes the problem. Thanks
[Bug middle-end/92377] [7/8 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92377 --- Comment #3 from Martin Liška --- ... and it started with r235817.
[Bug middle-end/92377] [7/8 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92377 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | --- Comment #2 from Martin Liška --- Fixed on trunk with r269243.
[Bug libstdc++/92376] [9/10 Regression] bootstrap fails with --disable-hosted-libstdcxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92376 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.3
[Bug middle-end/92377] [7/8 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92377 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||6.5.0, 9.1.0 Keywords||needs-bisection Last reconfirmed||2019-11-05 Component|c |middle-end CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |7.5 Known to fail||7.1.0, 8.3.1 --- Comment #1 from Richard Biener --- Confirmed. Was probably fixed by CFG cleanup refactoring. Martin?
[Bug target/92379] rs6000.c:5598:13: runtime error: shift exponent 64 is too large for 64-bit type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92379 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-05 CC||segher at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/92379] New: rs6000.c:5598:13: runtime error: shift exponent 64 is too large for 64-bit type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92379 Bug ID: 92379 Summary: rs6000.c:5598:13: runtime error: shift exponent 64 is too large for 64-bit type 'long int' Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Host: powerpc64-unknown-linux-gnu Target: powerpc64-unknown-linux-gnu Build: powerpc64-unknown-linux-gnu Using latest GCC master I see following UBSAN error: $ export UBSAN_OPTIONS="print_stacktrace=1" $ make all-host -k CFLAGS="-O0 -g -fsanitize=undefined -ldl" CXXFLAGS="-O0 -g -fsanitize=undefined" LDFLAGS="-fsanitize=undefined -ldl" $ ./xgcc -B./ -B/home/marxin/bin/gcc/powerpc64le-unknown-linux-gnu/bin/ -isystem /home/marxin/bin/gcc/powerpc64le-unknown-linux-gnu/include -isystem /home/marxin/bin/gcc/powerpc64le-unknown-linux-gnu/sys-include -L/home/marxin/Programming/gcc/objdir/gcc/../ld -xc -nostdinc /dev/null -S -o /dev/null -fself-test=../../gcc/testsuite/selftests ../../gcc/config/rs6000/rs6000.c:5598:13: runtime error: shift exponent 64 is too large for 64-bit type 'long int' #0 0x13299f48 in num_insns_constant_multi ../../gcc/config/rs6000/rs6000.c:5598 #1 0x1329bc44 in num_insns_constant(rtx_def*, machine_mode) ../../gcc/config/rs6000/rs6000.c:5686 #2 0x132ce1d4 in rs6000_emit_move(rtx_def*, rtx_def*, machine_mode) ../../gcc/config/rs6000/rs6000.c:9889 #3 0x13c07e6c in gen_movdi(rtx_def*, rtx_def*) ../../gcc/config/rs6000/rs6000.md:7171 #4 0x110da4d4 in insn_gen_fn::operator()(rtx_def*, rtx_def*) const ../../gcc/recog.h:318 #5 0x1106eaac in emit_move_insn_1(rtx_def*, rtx_def*) ../../gcc/expr.c:3727 #6 0x11070318 in emit_move_insn(rtx_def*, rtx_def*) ../../gcc/expr.c:3823 #7 0x1104078c in convert_move(rtx_def*, rtx_def*, int) ../../gcc/expr.c:247 #8 0x11082cc0 in store_expr(tree_node*, rtx_def*, int, bool, bool) ../../gcc/expr.c:5656 #9 0x1107fa40 in expand_assignment(tree_node*, tree_node*, bool) ../../gcc/expr.c:5482 #10 0x10a6cea4 in expand_gimple_stmt_1 ../../gcc/cfgexpand.c:3777 #11 0x10a6d934 in expand_gimple_stmt ../../gcc/cfgexpand.c:3875 #12 0x10a86d94 in expand_gimple_basic_block ../../gcc/cfgexpand.c:5914 #13 0x10a8d504 in execute ../../gcc/cfgexpand.c:6554 #14 0x144d2b5c in test_expansion_to_rtl ../../gcc/function-tests.c:609 #15 0x144d3818 in selftest::function_tests_c_tests() ../../gcc/function-tests.c:691 #16 0x149690bc in selftest::run_tests() ../../gcc/selftest-run-tests.c:102 #17 0x123602c8 in toplev::run_self_tests() ../../gcc/toplev.c:2240 #18 0x12360924 in toplev::main(int, char**) ../../gcc/toplev.c:2318 #19 0x14ad4d8c in main ../../gcc/main.c:39 #20 0x3fff8fbd50fc in generic_start_main.isra.0 (/lib64/libc.so.6+0x250fc)
[Bug target/92280] [10 regression] gcc.target/i386/pr83008.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92280 --- Comment #9 from Richard Biener --- Author: rguenth Date: Tue Nov 5 13:29:52 2019 New Revision: 277832 URL: https://gcc.gnu.org/viewcvs?rev=277832=gcc=rev Log: 2019-11-05 Richard Biener PR tree-optimization/92280 * match.pd (BIT_FIELD_REF of CTOR): Unless the original CTOR had a single use do not create a new CTOR. * tree-ssa-forwprop.c (simplify_bitfield_ref): Do not re-fold BIT_FIELD_REF of a CTOR via GENERIC. Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/tree-ssa-forwprop.c
[Bug target/92280] [10 regression] gcc.target/i386/pr83008.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92280 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener --- Fixed.
