https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65875
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #4)
> For h we get into the loop PHI handling code which drops to INF-1 if it
> iterates
> "too much". The rest probably ripples down from that.
>
> I can't see where that [1, 0x7ffffff] issue happens.
Current trunk, -O2 -fdump-tree-vrp-details on the testcase has in vrp1 dump:
<bb 2>:
g.0_9 = g;
if (g.0_9 < 0)
goto <bb 3>;
else
goto <bb 9>;
<bb 3>:
_12 = -g.0_9;
i_13 = (long int) _12;
goto <bb 9>;
and
Visiting statement:
_12 = -g.0_25;
Found new range for _12: [1, +INF(OVF)]
marking stmt to be not simulated again
Visiting statement:
i_13 = (long int) _12;
Found new range for i_13: [1, +INF(OVF)]
marking stmt to be not simulated again
The point was that the cast from 32-bit signed to 64-bit signed also should
imply that the value is not bigger than INT_MAX, and that is what we would do
if range for _12 was say [1, 0x7fffffff].
And for h, the point was that if only constants are assigned to the variable in
a loop, then no matter how many iterations the loop has, the resulting value
will only be one of the constants (thus smallest range covering those).
Or in this particular case, as the h = 1 assignments is only in endless loop,
we could have computed just [0, 0] (but that is probably too rare to care
about).
