https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90806
Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC| |ebotcazou at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
Last reconfirmed| |2020-12-14
--- Comment #8 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
We have been seeing it for a few days now, along with Warray-bounds-30.c. What
has changed in our setup is only the base compiler. The reduction of
Warray-bounds-30.c shows that for:
#define DIFF_MAX __PTRDIFF_MAX__
#define DIFF_MIN (-DIFF_MAX - 1)
#define MIN DIFF_MIN
void sink (int, ...);
#define T(...) sink (0, __VA_ARGS__)
void test_local_char_array (void)
{
char ar3[3] = { 1, 2, 3 };
char *p = ar3;
T (p[MIN]); /* { dg-warning "subscript -\[0-9\]+ is outside array
bounds of .char\\\[3]." } */
T (p[-1]); /* { dg-warning "subscript -1 is outside array bounds of
.char\\\[3]." } */
T (&p[MIN]); /* { dg-warning "subscript -\[0-9\]+ is \(below|outside\)
array bounds of .char\\\[3]." } */
T (&p[-1]); /* { dg-warning "subscript -1 is \(below|outside\) array
bounds of .char\\\[3]." } */
}
compiled at -O2, the FRE1 pass behaves differently:
@@ -15,11 +15,11 @@
Value numbering store ar3 to "\x01\x02\x03"
Setting value number of .MEM_10 to .MEM_10 (changed)
Value numbering stmt = _2 = MEM[(char *)&ar3 + -9223372036854775808B];
-Setting value number of _2 to _2 (changed)
-Making available beyond BB2 _2 for value _2
+Setting value number of _2 to 1 (changed)
Value numbering stmt = _3 = (int) _2;
-Setting value number of _3 to _3 (changed)
-Making available beyond BB2 _3 for value _3
+Match-and-simplified (int) _2 to 1
+RHS (int) _2 simplified to 1
+Setting value number of _3 to 1 (changed)
Value numbering stmt = sink (0, _3);
Setting value number of .MEM_12 to .MEM_12 (changed)
Value numbering stmt = _5 = MEM[(char *)&ar3 + -1B];
@@ -39,21 +39,21 @@
Value numbering stmt = return;
marking outgoing edge 2 -> 1 executable
RPO iteration over 1 blocks visited 1 blocks in total discovering 1 executable
blocks iterating 1.0 times, a block was visited max. 1 times
-RPO tracked 4 values available at 4 locations and 10 lattice elements
+RPO tracked 2 values available at 2 locations and 10 lattice elements
+Replaced MEM[(char *)&ar3 + -9223372036854775808B] with 1 in all uses of _2 =
MEM[(char *)&ar3 + -9223372036854775808B];
+Replaced (int) _2 with 1 in all uses of _3 = (int) _2;
+Removing dead stmt _3 = (int) _2;
+Removing dead stmt _2 = MEM[(char *)&ar3 + -9223372036854775808B];
test_local_char_array ()
{
char * p;
char ar3[3];
- char _2;
- int _3;
char _5;
int _6;
<bb 2> :
ar3 = "\x01\x02\x03";
- _2 = MEM[(char *)&ar3 + -9223372036854775808B];
- _3 = (int) _2;
- sink (0, _3);
+ sink (0, 1);
_5 = MEM[(char *)&ar3 + -1B];
_6 = (int) _5;
sink (0, _6);
Richard, can you imagine what could be the cause of this? Didn't you fix
something similar relatively recently, e.g. an expression with side effects
that would depend on the order the C++ compiler chooses for them or something
along this line?
