Stickiness of TYPE_MIN_VALUE/TYPE_MAX_VALUE

Stickiness of TYPE_MIN_VALUE/TYPE_MAX_VALUE

[Florian Weimer]

How sticky are TYPE_MIN_VALUE and TYPE_MAX_VALUE?  Is it possible to
get rid of their effect using a NOP_EXPR, CONVERT_EXPR or
VIEW_CONVERT_EXPR?

If this is impossible, the Ada front end should probably stop setting
these fields because it assumes that it can use values outside that
range:

<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.

Re: Stickiness of TYPE_MIN_VALUE/TYPE_MAX_VALUE

[Diego Novillo]

On Mon, May 30, 2005 at 09:59:12PM +0200, Florian Weimer wrote:
> How sticky are TYPE_MIN_VALUE and TYPE_MAX_VALUE?  Is it possible to
> get rid of their effect using a NOP_EXPR, CONVERT_EXPR or
> VIEW_CONVERT_EXPR?
> 
> If this is impossible, the Ada front end should probably stop setting
> these fields because it assumes that it can use values outside that
> range:
> 
> <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.

http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00127.html

If this is not what's biting you, send me a test case?  I've got
some local VRP changes that address a few of the limitations of
the existing implementation.


Diego.

Re: Stickiness of TYPE_MIN_VALUE/TYPE_MAX_VALUE

[Florian Weimer]

* 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.

Re: Stickiness of TYPE_MIN_VALUE/TYPE_MAX_VALUE

[Richard Kenner]

    This is correct. Note that this is only valid for objects, in
    expressions intermediate values may lay outside the range of the type.

The question was about expressions, not objects, and I disagree with you:
intermediate values may not lay outside the range of the type.  Gimplification
changes expressions to objects, so if what you claim were true, you
could never use the type range values to deduce anything.

Re: Stickiness of TYPE_MIN_VALUE/TYPE_MAX_VALUE

[Geert Bosch]

On May 30, 2005, at 16:50, Florian Weimer wrote:

> I'll try to phrase it differently: If you access an object whose bit
> pattern does not represent a value in the range given by
> TYPE_MIN_VALUE .. TYPE_MAX_VALUE of the corresponding type, does this
> result in erroneous execution/undefined behavior?  If not, what is the
> exact behavior WRT to out-of-bounds values?
>

This is correct. Note that this is only valid for objects,
in expressions intermediate values may lay outside the range
of the type.

Re: Stickiness of TYPE_MIN_VALUE/TYPE_MAX_VALUE

[Richard Kenner]

    I'll try to phrase it differently: If you access an object whose bit
    pattern does not represent a value in the range given by
    TYPE_MIN_VALUE .. TYPE_MAX_VALUE of the corresponding type, does this
    result in erroneous execution/undefined behavior?  

My feeling is yes, it does.

Re: Stickiness of TYPE_MIN_VALUE/TYPE_MAX_VALUE

[Florian Weimer]

* Richard Kenner:

>     How sticky are TYPE_MIN_VALUE and TYPE_MAX_VALUE?  Is it possible to
>     get rid of their effect using a NOP_EXPR, CONVERT_EXPR or
>     VIEW_CONVERT_EXPR?
>
> I don't really understand either question.  Also, as to the second,
> keep in mind their role in array indexes.

I'll try to phrase it differently: If you access an object whose bit
pattern does not represent a value in the range given by
TYPE_MIN_VALUE .. TYPE_MAX_VALUE of the corresponding type, does this
result in erroneous execution/undefined behavior?  If not, what is the
exact behavior WRT to out-of-bounds values?

>     If this is impossible, the Ada front end should probably stop setting
>     these fields because it assumes that it can use values outside that
>     range:
>
>     http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gnat_ugn_unw/Validity-Checking.html
>
> I don't understand what that chapter has to do with your statement.

These checks are implemented using the 'Valid attribute (see
Checks.Ensure_Valid and Checks.Insert_Valid_Check).

Re: Stickiness of TYPE_MIN_VALUE/TYPE_MAX_VALUE

[Richard Kenner]

    How sticky are TYPE_MIN_VALUE and TYPE_MAX_VALUE?  Is it possible to
    get rid of their effect using a NOP_EXPR, CONVERT_EXPR or
    VIEW_CONVERT_EXPR?

I don't really understand either question.  Also, as to the second,
keep in mind their role in array indexes.

    If this is impossible, the Ada front end should probably stop setting
    these fields because it assumes that it can use values outside that
    range:

    http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gnat_ugn_unw/Validity-Checking.html

I don't understand what that chapter has to do with your statement.

There is an outstanding PR where Ada is using the wrong type to store
intermediate values.

A much trickier question comes up in the handling of the 'Valid attribute
because the purpose of that attribute is precisely to determine whether
a value is within the bounds of its type. But that can only be used in
very specific circumstances and should not dictate the way the type
system is used.