Ada subtypes and base types (was: Bootstrap failure on trunk: x86_64-linux-gnu)

[Jeffrey A Law]

On Tue, 2006-02-21 at 13:31 -0500, Richard Kenner wrote:
>      Err, no they don't.  Clearly an object of the type can hold a value 
>      outside TYPE_MIN_VALUE/TYPE_MAX_VALUE at runtime.  That IMHO means
>      that TYPE_MIN_VALUE/TYPE_MAX_VALUE do not reflect reality.
> 
> What does "can" mean here?  If it means "is physically capable of", then
> TYPE_MIN_VALUE and TYPE_MAX_VALUE have no meaning an any context.
Can a conforming program set the object to a value outside of
TYPE_MIN_VALUE/TYPE_MAX_VALUE.  Clearly the answer for Ada today
is yes, and that is horribly bad as it means TYPE_MIN_VALUE and
TYPE_MAX_VALUE are effectively useless.


> I interpret "can" as meaning "is allowed to according to the semantics
> of the language", meaning that if the value is outside that range, it's
> an invalid (technicallly "erroneous" in Ada terminology).
According to a previous message from you, it's not invalid.  For
example, you can get such a value from an unchecked conversion and
you can use that value in an meaningful way (runtime bounds 
checking).


> No, I don't think the Ada code in question is bogus.  My understanding
> of this thread is that somebody (either the Ada front end, gimplification,
> or the optimizer) is breaking the type-correctness of the tree.
Type conversions aren't being lost.  The fundamental problem is 
with the setting of TYPE_MIN_VALUE/TYPE_MAX_VALUE.  Please read
the data in the PR.  I've detailed pretty well what's happening and
the fundamental problem is the bogus value for TYPE_MAX_VALUE.

> No, because in the absence of a 'Value, the unchecked conversion must
> *also* produce a value in the range to be non-erroneous.  The *only*
> case we need to worry about is an object that is *both* the target of
> an unchecked conversion *and* the operand of a 'Valid.  That applies
> to an exceedingly tiny number of objects and they should not drive the
> entire type system, as I said.  Instead, what we need to do is define
> some tree node (or flag) that tells VRP "don't deduce any value
> through this node".  That's enough to handle this rare case.
I disagree strongly -- the Ada front-end is lying to the rest of the
compiler about the range of types.  That's a problem that needs to
be fixed in the Ada front-end, not VRP.  VRP shouldn't need to know
about this kind of braindamange.


> 
>      No they are not.  The ADa front-end says that an object of a particular
>      type as a set of values [x .. y].  However, at runtime the object is
>      allowed to have values outside that range. 
> 
> Not for the normal meaning of "allowed".  With the single exception above,
> a program is erroneous if, at run time, the values are otuside that range.
But this exception is *VERY* important.  THe exception fundamentally
allows you to set the object to a value outside the range and the
exception then allows the program to detect such an assignment at
runtime.  That effectively makes TYPE_MIN_VALUE/TYPE_MAX_VALUE useless.

jeff