This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH COMMITTED: Don't break tests for enum in range
> I *think* that for a case like this VRP will tend to draw the right
> conclusion: that valid should return false.
Because it is not smart enough for the time being?
> Here n_low == NULL and n_high == 1 in type E. high_positive is
> 0x7fffffff, also in type E (note this is out of range according to
> TYPE_MAX_VALUE, but not according to TYPE_PRECISION which is 32).
I think that this is the root cause.
> In merge_ranges, low0 is NULL, high0 is 1, low1 is 0, high1 is
> 0x7fffffff, in0_p is false, in1_p is true, lowequal is false,
> highequal is false, no_overlap is false, subset is false. We come to
> this code:
>
> low = range_successor (high0);
> high = high1;
> in_p = (low != 0);
>
> range_successor (high0) returns NULL. We wind up setting *plow to
> NULL, *phigh to 0x7fffffff, and *pin_p to 0. Since we have an
> unsigned type, this is the range [0x80000000, 0xffffffff]. This is
> meaningless. The range we actually want is [2, 0x7fffffff].
If high_positive is set to NULL (infinity), you end up with the case that
prompted me to write the patch
-[-, 1] , +[0, -]
which would give the correct -[-,-].
> Alternatively it would probably work to return an empty range, if we
> had a way to represent that.
We have, see above, you just have to force high to NULL too.
--
Eric Botcazou