[Bug target/49419] [4.6/4.7 regression] gcc -O2 miscompiles gp2c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49419 --- Comment #5 from Jakub Jelinek 2011-06-15 14:59:50 UTC --- Anyway, the bug is elsewhere, in particular I'd say the bug is that we use the normal SSA_NAME as init value of the second loop instead of the SSA_NAME initialized from ASSERT_EXPR for that. The interesting stmts are: # iD.1254_47 = PHI <[pr49419.c : 15:67] iD.1254_70(6), [pr49419.c : 15:67] iD.1254_69(8), 0(3), 0(21)> ... iD.1254_86 = ASSERT_EXPR ; ... iD.1254_85 = ASSERT_EXPR 0>; ... # iD.1254_50 = PHI <[pr49419.c : 19:60] iD.1254_40(18), iD.1254_85(12)> and the second loop sees i_85 as the initial value. Now, first the i_47 setter is walked, with just one of the edges with value 0 executable, so i_47 has [0, 0] range there. Then i_86 is walked, and as var's range is VR_RANGE, while limit range is VR_ANTI_RANGE, surprisingly symbolic range ~[nbmax_17(D), nbmax_17(D)] wins. I'd think [0, 0] would be much better to return, both because it is not symbolic, is quite narrow and is range instead of anti range. After a while, i_50 stmt is walked several times, including using adjust_range_with_scev, which uses i_47 instead of i_85 as init for some reason. At that point it sees it has [0, 0] range and so computes something from that. After a while, i_47 stmt is visited several times, last time resulting into [0, +INF(OVF)] range (see other comments that it ought to be improved, but uninteresting for this bug). So, the PHI setting i_47 is returning SSA_PROP_INTERESTING, which results in all succ edges of that bb to be marked for revisiting. We revisit i_86 stmt, but that again returns the same (uninteresting) ~[nbmax_17(D), nbmax_17(D)] range, which also means that it is SSA_PROP_NOT_INTERESTING. That bb contains just: [pr49419.c : 18:6] nbD.1255_24 = iD.1254_86 + 1; [pr49419.c : 19:3] if (iD.1254_86 > 0) after it, but as i_86's VR didn't change, no other VRs in that bb change either, which means none of the succ bb's of this bb are queued for revisiting. So, I think we should arrange for the actual current ASSERT_EXPR SSA_NAME to be used as init during scev if possible, instead of the original one, and furthermore I believe extract_range_from_assert_expr should do a better job.
[Bug target/49419] [4.6/4.7 regression] gcc -O2 miscompiles gp2c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49419
--- Comment #4 from Jakub Jelinek 2011-06-15
12:29:51 UTC ---
Perhaps even for:
void bar (void);
int test (int);
int fn (int x, int y)
{
int i;
for (i = 0; i < y && test (i); i++)
;
if (i == y)
return;
if (i == __INT_MAX__)
bar ();
}
we should be able to determine that bar can't be called. In the loop body
i is known to be i < y, after the loop i <= y but the i == y test rules out the
equality again, so we end up again with i < y which is certainly i <
__INT_MAX__.
[Bug target/49419] [4.6/4.7 regression] gcc -O2 miscompiles gp2c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49419
--- Comment #3 from Jakub Jelinek 2011-06-15
12:19:00 UTC ---
So, i_47 which is the i value on entry of the second loop is determined to be
[0, +INF(OVF)] and something goes wrong afterwards. The bug will be there, but
I should note that VRP should easily prove that i never overflows.
Simpler testcases for that:
void bar (void);
void foo (int x, int y)
{
if (x < y)
{
if (x == __INT_MAX__)
bar ();
}
}
void baz (int x, int y, int z)
{
if (x < y || x < z)
{
if (x == __INT_MAX__)
bar ();
}
}
Here IMNSHO vrp should optimize the call to bar away, as when x is smaller than
some variable of the same type, it can't be the maximum of that type, because
even if the other number is __INT_MAX__, x must be smaller than that.
[Bug target/49419] [4.6/4.7 regression] gcc -O2 miscompiles gp2c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49419 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek 2011-06-15 11:55:40 UTC --- Confirmed, seems VRP2 removes changes the for(x=n;i>0;stack[i]=tree[x].y,x=tree[x].x,i--); loop into endless loop. Looking into it.
[Bug target/49419] [4.6/4.7 regression] gcc -O2 miscompiles gp2c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49419 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson 2011-06-15 11:54:27 UTC --- Same breakage also seen on m68k-linux.
[Bug target/49419] [4.6/4.7 regression] gcc -O2 miscompiles gp2c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49419 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.6.1
