[Bug tree-optimization/84050] [6/7/8 Regression] missing -Warray-bounds accessing a struct array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84050 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Target Milestone|6.5 |9.0
[Bug tree-optimization/84050] [6/7/8 Regression] missing -Warray-bounds accessing a struct array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84050 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-26 CC||aldyh at gcc dot gnu.org, ||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=84047 Ever confirmed|0 |1 --- Comment #2 from Aldy Hernandez --- Confirmed. FWIW, my patch for 84047 does not fix this PR, as VRP never sees the problematic instruction and is not able to warn. This is because ccp2 has removed the instruction. Before ccp2 we had: fstatic_array () { static struct A a = {.a={1, 2, 3}}; int _2; [local count: 1073741825]: _2 = a.a[7]; return _2; } After ccp2 we have: fstatic_array () { static struct A a = {.a={1, 2, 3}}; [local count: 1073741825]: return 0; } I'm not a language lawyer, so I don't know what the semantics of undefined behavior is. Is returning 0 even the correct thing to do? Though perhaps, as Jakub mentions in pr84047, maybe we should move this GCC 9?
[Bug tree-optimization/84050] [6/7/8 Regression] missing -Warray-bounds accessing a struct array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84050 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.5
[Bug tree-optimization/84050] [6/7/8 Regression] missing -Warray-bounds accessing a struct array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84050 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Known to work||4.5.4 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=83776 Summary|missing -Warray-bounds |[6/7/8 Regression] missing |accessing a struct array|-Warray-bounds accessing a |member |struct array member Known to fail||4.6.4, 4.7.4, 4.8.4, 4.9.4, ||5.5.0, 6.4.0, 7.2.0, 8.0 --- Comment #1 from Martin Sebor --- Same as in bug 83776, bisection points to r164688 committed into GCC 4.6 as the root cause of the regression: r164688 | hubicka | 2010-09-28 12:28:39 -0400 (Tue, 28 Sep 2010) | 5 lines * tree-ssa-ccp.c (fold_ctor_reference): New function. (fold_const_aggregate_ref): Use it. * fold-const.c (canonicalize_constructor_val): Check that we don't fold into external static.