This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Stickiness of TYPE_MIN_VALUE/TYPE_MAX_VALUE
* Diego Novillo:
>> <http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gnat_ugn_unw/Validity-Checking.html>
>>
>> Current mainline does not optimize array range checks away (even with
>> -ftree-vrp), but I'm not sure if this is just a missed optimization
>> opportunity as far as the optimizers are concerned, or something which
>> is guaranteed to work in the future.
>>
> Missed on purpose because of the bootstrap bug I worked-around a
> few weeks ago. See the comment in tree-vrp.c:extract_range_from_assert
> regarding integral types with super-types.
Thanks, but this doesn't really answer my question. 8-) Do you
consider your patch as a temporary workaround, or should front ends
refrain from emitting TYPE_MIN_VALUE/TYPE_MAX_VALUE fields if they
cannot prove that no out-of-bounds values exist at run time?
> http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00127.html
>
> If this is not what's biting you, send me a test case?
This is PR21573, a miscompiled SWITCH_EXPR. TYPE_MIN_VALUE and
TYPE_MAX_VALUE are used to avoid some comparisons in the expand_case
machinery in stmt.c. It's not VRP-related, and it also fails on
GCC?4.0.