https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97501
--- Comment #5 from Andrew Macleod <amacleod at redhat dot com> ---
Just to further annotate why this is the correct fix for posterity..
evrp/vrp calls adjust_range_with_scev:
/* Start with the input range... */
tree vrmin = vr->min ();
tree vrmax = vr->max ();
/* ...and narrow it down with what we got from SCEV. */
if (compare_values (min, vrmin) == 1)
vrmin = min;
if (compare_values (max, vrmax) == -1)
vrmax = max;
vr->update (vrmin, vrmax);
which adjusts an existing range. The gimple_range routine merely returns any
range SCEV finds.. which is similar to passing in [MIN, MAX] as the range to be
adjusted.
furthermore, when compare_values is called, if either operand overflows,
if (TREE_CODE (val1) == INTEGER_CST && TREE_CODE (val2) == INTEGER_CST)
{
/* We cannot compare overflowed values. */
if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
return -2;
it returns -2
Since EVRP will not change either end bound if -2 is returned, saturating the
end points on an overflow is tantamount to passing [MIN, MAX] as the range to
be adjusted.
So this should produce the same results for integers.
