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

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

[Richard Kenner]

     Indeed.  Ada should in this case generate

       R = (T)( (basetype)100 + (basetype)X - (basetype)X )

     i.e. carry out all arithmetic explicitly in the basetype and only for
     stores and loads use the subtype.

That is indeed required by the language and what is normally generated.
It would be valuable to see exactly who generated the bogus operation.

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

[Richard Guenther]

On 2/20/06, Richard Kenner <kenner@vlsi1.ultra.nyu.edu> wrote:
>      Indeed.  Ada should in this case generate
>
>        R = (T)( (basetype)100 + (basetype)X - (basetype)X )
>
>      i.e. carry out all arithmetic explicitly in the basetype and only for
>      stores and loads use the subtype.
>
> That is indeed required by the language and what is normally generated.
> It would be valuable to see exactly who generated the bogus operation.
>

Indeed - I can very well imagine fold or ccp stripping off such type conversions
in some case, which would lead to wrong code by VRP.

Richard.

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

[Jeffrey A Law]

On Mon, 2006-02-20 at 23:00 +0100, Richard Guenther wrote:
> On 2/20/06, Richard Kenner <kenner@vlsi1.ultra.nyu.edu> wrote:
> >      Indeed.  Ada should in this case generate
> >
> >        R = (T)( (basetype)100 + (basetype)X - (basetype)X )
> >
> >      i.e. carry out all arithmetic explicitly in the basetype and only for
> >      stores and loads use the subtype.
> >
> > That is indeed required by the language and what is normally generated.
> > It would be valuable to see exactly who generated the bogus operation.
> >
> 
> Indeed - I can very well imagine fold or ccp stripping off such type conversions
> in some case, which would lead to wrong code by VRP.
Again, so can I, so it's a concern.  However, I'm pretty sure that's
not what's happening here.  If you disable the code to strip away
useless type conversions you still get the same problem.

jeff

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

[Duncan Sands]

Hi Laurent,

On Wednesday 22 February 2006 12:34, Laurent GUERBY wrote:
> On Wed, 2006-02-22 at 10:54 +0100, Richard Guenther wrote:
> > > > > >  type T1 is range 0 .. 127;
> > > > > >  -- Compiler will choose some type for T'Base, likely to be -128..127
> > > > > >  -- but could be Integer (implementation dependant)
> > > > > >  subtype T is T1 range 0 .. 100;
> > > > > >  R : T := 100+X-X;
> > > > > >  -- guaranteed work as long 100+X<=T'Base'Last and 100-X>=T'Base'First
> > 
> > Is the final "conversion" a checked conversion or an unchecked conversion?  I.e.
> > are we supposed to check for overflow using 'Valid on the final result?  Or will
> > the value be truncated or a runtime error raised?
> 
> In the full language we are supposed to check the range on the
> assignement and raise the predefined exception "CONSTRAINT_ERROR" if it
> fails (whatever the way in the generated code). However GNAT by default
> does not generate this kind of check, you need to add -gnato to the
> compile flags.

my understanding is that -gnato causes the compiler to insert checks that the
"100+X-X" computation does not overflow the base type.  The compiler always
inserts a check that the result is in the range of the target type T before
performing the assignment, regardless of whether -gnato is set or not.

Best wishes,

Duncan.

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

[Laurent GUERBY]

On Wed, 2006-02-22 at 10:54 +0100, Richard Guenther wrote:
> > > > >  type T1 is range 0 .. 127;
> > > > >  -- Compiler will choose some type for T'Base, likely to be -128..127
> > > > >  -- but could be Integer (implementation dependant)
> > > > >  subtype T is T1 range 0 .. 100;
> > > > >  R : T := 100+X-X;
> > > > >  -- guaranteed work as long 100+X<=T'Base'Last and 100-X>=T'Base'First
> 
> Is the final "conversion" a checked conversion or an unchecked conversion?  I.e.
> are we supposed to check for overflow using 'Valid on the final result?  Or will
> the value be truncated or a runtime error raised?

In the full language we are supposed to check the range on the
assignement and raise the predefined exception "CONSTRAINT_ERROR" if it
fails (whatever the way in the generated code). However GNAT by default
does not generate this kind of check, you need to add -gnato to the
compile flags.

Laurent

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

[Richard Guenther]

On 2/21/06, Jeffrey A Law <law@redhat.com> wrote:
> On Mon, 2006-02-20 at 22:00 +0100, Richard Guenther wrote:
> > On 2/20/06, Jeffrey A Law <law@redhat.com> wrote:
> > > On Sun, 2006-02-19 at 20:43 +0100, Laurent GUERBY wrote:
> > > > On Sun, 2006-02-19 at 14:23 -0500, Richard Kenner wrote:
> > > > >     "Second, for a given integer type (such as
> > > > >     natural___XDLU_0_2147483647), the type for the nodes in TYPE_MIN_VALUE
> > > > >     and TYPE_MAX_VALUE really should be a natural___XDLU_0_2147483647.
> > > > >     ie, the type of an integer constant should be the same as the type of
> > > > >     its min/max values."
> > > > >
> > > > > No, the type of the bounds of a subtype should be the *base type*.  That's
> > > > > how the tree has always looked, as far back as  I can remember.
> > > >
> > > > This is because intermediate computations can produce results
> > > > outside the subtype range but within the base type range (RM 3.5(6)),
> > > > right?
> > > >
> > > >  type T1 is range 0 .. 127;
> > > >  -- Compiler will choose some type for T'Base, likely to be -128..127
> > > >  -- but could be Integer (implementation dependant)
> > > >  subtype T is T1 range 0 .. 100;
> > > >  R : T := 100+X-X;
> > > >  -- guaranteed work as long 100+X<=T'Base'Last and 100-X>=T'Base'First

Is the final "conversion" a checked conversion or an unchecked conversion?  I.e.
are we supposed to check for overflow using 'Valid on the final result?  Or will
the value be truncated or a runtime error raised?

Richard.

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

[Richard Guenther]

On 2/21/06, Richard Kenner <kenner@vlsi1.ultra.nyu.edu> wrote:
>      But if the values in there do not reflect the reality of what values
>      are valid for the type, then I don't see how they can be generally
>      useful -- that's my point.  We have two fields that are inaccurate,
>      apparently on purpose, and as a result they are basically unusable.
>
> No, they *do* reflect the "reality of what values are valid for the type".
> The only glitch, which is not what we're talking about here, is that you have
> to have a way to implement the language-defined test to see if the value is
> valid or not.  However, the need to implement that relative-uncommon test
> should't drive the basic methodology used to represent types.

As you mention in another post an invalid value can only occour (as in, being
not undefined behavior) with an unchecked conversion.  The Ada frontend
has to make sure then that for

  BaseType i;
  SubType x = <unchecked>(SubType)i;
// now the value stored in x may exceed its range
  if (Valid (x))
   ...

that for the Valid (x) test, a VIEW_CONVERT_EXPR is used to do the comparison(s)
in the BaseType again.  And using the VIEW_CONVERT_EXPR to tell the compiler
it cannot look through the cast and infer range information from the type of x.

Richard.

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

[Richard Kenner]

     In this specific case it is a user variable.  However, we should
     probably clarify the compiler-temporary case as well as VRP really
     does not and should not care if an object is a user variable or
     a compiler generated temporary.

Right.  The only distinction is that if it's a user variable then it's
a "bogus" program while if it's a compiler-generated temporary, it's either
bogus *or* a bug in the definition of that temporary in the compiler.

     So, if we have an object with the range based on its type of [0,
     0x7fffffff] and we add 1 to that object, the resulting range should be
     [1, 0x7fffffff].  ie, 0x80000000 is not a valid value for the type.
     Right?

Correct.

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

[Jeffrey A Law]

On Tue, 2006-02-21 at 14:14 -0500, Richard Kenner wrote:
>      OK.  So if a program sets an object to a value outside 
>      TYPE_MIN_VALUE/TYPE_MAX_VALUE, then that program is
>      invalid for the purposes of this discussion?
> 
> Correct.  Of course, it has to be the *program* that's doing the set
> (meaning setting a user-defined variable).  If the compiler is messing
> up (either front- or middle-end), then this discussion becomes quite
> relevant.
In this specific case it is a user variable.  However, we should
probably clarify the compiler-temporary case as well as VRP really
does not and should not care if an object is a user variable or
a compiler generated temporary.

So, if we have an object with the range based on its type of
[0, 0x7fffffff] and we add 1 to that object, the resulting range
should be [1, 0x7fffffff].   ie, 0x80000000 is not a valid value
for the type.  Right?


jeff

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

[Richard Kenner]

     OK.  So if a program sets an object to a value outside 
     TYPE_MIN_VALUE/TYPE_MAX_VALUE, then that program is
     invalid for the purposes of this discussion?

Correct.  Of course, it has to be the *program* that's doing the set
(meaning setting a user-defined variable).  If the compiler is messing
up (either front- or middle-end), then this discussion becomes quite
relevant.

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

[Jeffrey A Law]

On Tue, 2006-02-21 at 13:57 -0500, Richard Kenner wrote:
>      Can a conforming program set the object to a value outside of
>      TYPE_MIN_VALUE/TYPE_MAX_VALUE.
> 
> Let's forget about the obscure unchecked conversion -> 'Valid case
> because we're going to handle that in whatever way we need to.
> 
> So the answer is "no".
OK.  So if a program sets an object to a value outside 
TYPE_MIN_VALUE/TYPE_MAX_VALUE, then that program is
invalid for the purposes of this discussion?

Jeff

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

[Richard Kenner]

     Can a conforming program set the object to a value outside of
     TYPE_MIN_VALUE/TYPE_MAX_VALUE.

Let's forget about the obscure unchecked conversion -> 'Valid case
because we're going to handle that in whatever way we need to.

So the answer is "no".

Re: 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

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

[Richard Kenner]

     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.

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

     Having a consistent TYPE_MIN_VALUE and TYPE_MAX_VALUE in no way
     prohibits you from implementing these tests.  

Of course it doesn't!  I was agreeing with you.  I was also separating
the issue of those tests from the issue at hand.

     OK, so then we can claim the Ada code in question in bogus?  Or at
     least put the burden of proving the code is correct back in your
     court?  I've clearly showed that VRP is "miscompiling" the code
     because of the bogus values for TYPE_MAX_VALUE.  But if you claim that
     having a value outside TYPE_MAX_VALUE is invalid according to the
     language, then the source code must be incorrect.

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.

    Which implies that TYPE_MIN_VALUE/TYPE_MAX_VALUE need to reflect the
    set of values which can be placed into the object by way of an
    unchecked conversion.  

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.

     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.

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

[Jeffrey A Law]

On Tue, 2006-02-21 at 12:46 -0500, Richard Kenner wrote:
>      But if the values in there do not reflect the reality of what values
>      are valid for the type, then I don't see how they can be generally
>      useful -- that's my point.  We have two fields that are inaccurate,
>      apparently on purpose, and as a result they are basically unusable.
> 
> No, they *do* reflect the "reality of what values are valid for the type".
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.


> The only glitch, which is not what we're talking about here, is that you have
> to have a way to implement the language-defined test to see if the value is
> valid or not.  However, the need to implement that relative-uncommon test
> should't drive the basic methodology used to represent types.
Having a consistent TYPE_MIN_VALUE and TYPE_MAX_VALUE in no way
prohibits you from implementing these tests.  As I've told you before,
if you've got a case where the tests are being incorrectly removed
or casts are being incorrectly removed I'll happily investigate.

But I'll repeat again, a consistent TYPE_MIN_VALUE/TYPE_MAX_VALUE in no
way changes your ability to emit those tests in the Ada front-end.


> With checking enabled, "normal" Ada usage should not be able to generate an
> invalid value, so the assumption by VRP that the values are in the valid
> range is a correct one (of course, you do have to be able to generate those
> checks!).  With checking disabled, an Ada program is erroneous if it
> generates a value outside that range, so again VRP can assume the values are
> in the specififed range.
OK, so then we can claim the Ada code in question in bogus?  Or at least
put the burden of proving the code is correct back in your court?  I've
clearly showed that VRP is "miscompiling" the code because of the
bogus values for TYPE_MAX_VALUE.  But if you claim that having a value 
outside TYPE_MAX_VALUE is invalid according to the language, then the
source code must be incorrect.

> 
> There's only one exception here.  It's valid to do a "unchecked conversion"
> from arbitrary data into a value of a subtype with a restricted range.  You
> are then allowed to test (using 'Valid) whether or not the value is in range.
> But any use of an out-of-range value (other than 'Valid) is also erroneous.
Which implies that TYPE_MIN_VALUE/TYPE_MAX_VALUE need to reflect the set
of values which can be placed into the object by way of an unchecked
conversion.  ANything else is simply lying to the language independent
parts of the compiler.

> 
> So the Ada rules and what VRP are assuming are precisely consistent.
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.  That is _not_ consistent.


> improperly.  These simply have to be found and fixed.  I found one quite a
> while ago (when folding ranges) and I'm sure there are more (somebody
> speculated that perhaps fold is removing conversions that are, in fact,
> needed).
I'm open to this possiblity as well, but this is completely and totally
disjoint from the inconsistent TYPE_MIN_VALUE/TYPE_MAX_VALUE presented
by the Ada front-end.

jeff

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

[Richard Kenner]

     But if the values in there do not reflect the reality of what values
     are valid for the type, then I don't see how they can be generally
     useful -- that's my point.  We have two fields that are inaccurate,
     apparently on purpose, and as a result they are basically unusable.

No, they *do* reflect the "reality of what values are valid for the type".
The only glitch, which is not what we're talking about here, is that you have
to have a way to implement the language-defined test to see if the value is
valid or not.  However, the need to implement that relative-uncommon test
should't drive the basic methodology used to represent types.

With checking enabled, "normal" Ada usage should not be able to generate an
invalid value, so the assumption by VRP that the values are in the valid
range is a correct one (of course, you do have to be able to generate those
checks!).  With checking disabled, an Ada program is erroneous if it
generates a value outside that range, so again VRP can assume the values are
in the specififed range.

There's only one exception here.  It's valid to do a "unchecked conversion"
from arbitrary data into a value of a subtype with a restricted range.  You
are then allowed to test (using 'Valid) whether or not the value is in range.
But any use of an out-of-range value (other than 'Valid) is also erroneous.

So the Ada rules and what VRP are assuming are precisely consistent.  We
unfortunately have bugs in two areas.  The first are not having a good way of
making sure the validity check isn't suppressed and the second is that there
apparently places where trees are being generated that do operations
improperly.  These simply have to be found and fixed.  I found one quite a
while ago (when folding ranges) and I'm sure there are more (somebody
speculated that perhaps fold is removing conversions that are, in fact,
needed).

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

[Jeffrey A Law]

On Mon, 2006-02-20 at 22:00 +0100, Richard Guenther wrote:
> On 2/20/06, Jeffrey A Law <law@redhat.com> wrote:
> > On Sun, 2006-02-19 at 20:43 +0100, Laurent GUERBY wrote:
> > > On Sun, 2006-02-19 at 14:23 -0500, Richard Kenner wrote:
> > > >     "Second, for a given integer type (such as
> > > >     natural___XDLU_0_2147483647), the type for the nodes in TYPE_MIN_VALUE
> > > >     and TYPE_MAX_VALUE really should be a natural___XDLU_0_2147483647.
> > > >     ie, the type of an integer constant should be the same as the type of
> > > >     its min/max values."
> > > >
> > > > No, the type of the bounds of a subtype should be the *base type*.  That's
> > > > how the tree has always looked, as far back as  I can remember.
> > >
> > > This is because intermediate computations can produce results
> > > outside the subtype range but within the base type range (RM 3.5(6)),
> > > right?
> > >
> > >  type T1 is range 0 .. 127;
> > >  -- Compiler will choose some type for T'Base, likely to be -128..127
> > >  -- but could be Integer (implementation dependant)
> > >  subtype T is T1 range 0 .. 100;
> > >  R : T := 100+X-X;
> > >  -- guaranteed work as long 100+X<=T'Base'Last and 100-X>=T'Base'First
> > Which leaves us with a very fundamental issue.  Namely that we can not
> > use TYPE_MIN_VALUE or TYPE_MAX_VALUE for ranges.  That's lame,
> > incredibly lame.  This nonsense really should be isolated within the
> > Ada front-end.
> 
> Indeed.  Ada should in this case generate
> 
>   R = (T)( (basetype)100 + (basetype)X - (basetype)X )
> 
> i.e. carry out all arithmetic explicitly in the basetype and only for stores
> and loads use the subtype.
I'd tend to agree, furthermore, if a pass starts wiping out those
type conversions, then we've got a bug.  I could believe that
such bugs exist as those conversions might be seen as useless
(particularly if the basetype and the real type differ only in
their TYPE_MIN_VALUE/TYPE_MAX_VALUE -- ie, they have the same
signedness and precision).  That case ought to be easy enough to
detect though.

Jeff

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

[Jeffrey A Law]

On Mon, 2006-02-20 at 16:49 -0500, Richard Kenner wrote:
>      Which leaves us with a very fundamental issue.  Namely that we can not
>      use TYPE_MIN_VALUE or TYPE_MAX_VALUE for ranges.  
> 
> The point is that it *is* supposed to be usable in general.  If it can't
> be used in a specific case, let's address that specific case and understand
> what needs fixing.  The intent is for it to be useful and usable information..
But if the values in there do not reflect the reality of what values
are valid for the type, then I don't see how they can be generally
useful -- that's my point.  We have two fields that are inaccurate,
apparently on purpose, and as a result they are basically unusable.

Jeff

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

[Richard Kenner]

     Which leaves us with a very fundamental issue.  Namely that we can not
     use TYPE_MIN_VALUE or TYPE_MAX_VALUE for ranges.  

The point is that it *is* supposed to be usable in general.  If it can't
be used in a specific case, let's address that specific case and understand
what needs fixing.  The intent is for it to be useful and usable information..

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

[Richard Guenther]

On 2/20/06, Jeffrey A Law <law@redhat.com> wrote:
> On Sun, 2006-02-19 at 20:43 +0100, Laurent GUERBY wrote:
> > On Sun, 2006-02-19 at 14:23 -0500, Richard Kenner wrote:
> > >     "Second, for a given integer type (such as
> > >     natural___XDLU_0_2147483647), the type for the nodes in TYPE_MIN_VALUE
> > >     and TYPE_MAX_VALUE really should be a natural___XDLU_0_2147483647.
> > >     ie, the type of an integer constant should be the same as the type of
> > >     its min/max values."
> > >
> > > No, the type of the bounds of a subtype should be the *base type*.  That's
> > > how the tree has always looked, as far back as  I can remember.
> >
> > This is because intermediate computations can produce results
> > outside the subtype range but within the base type range (RM 3.5(6)),
> > right?
> >
> >  type T1 is range 0 .. 127;
> >  -- Compiler will choose some type for T'Base, likely to be -128..127
> >  -- but could be Integer (implementation dependant)
> >  subtype T is T1 range 0 .. 100;
> >  R : T := 100+X-X;
> >  -- guaranteed work as long 100+X<=T'Base'Last and 100-X>=T'Base'First
> Which leaves us with a very fundamental issue.  Namely that we can not
> use TYPE_MIN_VALUE or TYPE_MAX_VALUE for ranges.  That's lame,
> incredibly lame.  This nonsense really should be isolated within the
> Ada front-end.

Indeed.  Ada should in this case generate

  R = (T)( (basetype)100 + (basetype)X - (basetype)X )

i.e. carry out all arithmetic explicitly in the basetype and only for stores
and loads use the subtype.

Otherwise we might as well get rid of TYPE_MIN_VALUE and
TYPE_MAX_VALUE (for Ada).

Richard.

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

[Jeffrey A Law]

On Sun, 2006-02-19 at 20:43 +0100, Laurent GUERBY wrote:
> On Sun, 2006-02-19 at 14:23 -0500, Richard Kenner wrote:
> >     "Second, for a given integer type (such as
> >     natural___XDLU_0_2147483647), the type for the nodes in TYPE_MIN_VALUE
> >     and TYPE_MAX_VALUE really should be a natural___XDLU_0_2147483647.
> >     ie, the type of an integer constant should be the same as the type of
> >     its min/max values."
> > 
> > No, the type of the bounds of a subtype should be the *base type*.  That's
> > how the tree has always looked, as far back as  I can remember.
> 
> This is because intermediate computations can produce results
> outside the subtype range but within the base type range (RM 3.5(6)),
> right?
> 
>  type T1 is range 0 .. 127; 
>  -- Compiler will choose some type for T'Base, likely to be -128..127 
>  -- but could be Integer (implementation dependant)
>  subtype T is T1 range 0 .. 100; 
>  R : T := 100+X-X; 
>  -- guaranteed work as long 100+X<=T'Base'Last and 100-X>=T'Base'First
Which leaves us with a very fundamental issue.  Namely that we can not
use TYPE_MIN_VALUE or TYPE_MAX_VALUE for ranges.  That's lame,
incredibly lame.  This nonsense really should be isolated within the
Ada front-end.

In the mean time, what is the safe way to determine the full set of
values any particular object may have, taking into consideration this
Ada braindamage?

jeff

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

[Richard Kenner]

    > No, the type of the bounds of a subtype should be the *base type*. 
    > That's how the tree has always looked, as far back as  I can remember.

    This is because intermediate computations can produce results
    outside the subtype range but within the base type range (RM 3.5(6)),
    right?

No.  I'm pretty sure that convention predates the Ada front end by over a
decade ...

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

[Laurent GUERBY]

On Sun, 2006-02-19 at 14:23 -0500, Richard Kenner wrote:
>     "Second, for a given integer type (such as
>     natural___XDLU_0_2147483647), the type for the nodes in TYPE_MIN_VALUE
>     and TYPE_MAX_VALUE really should be a natural___XDLU_0_2147483647.
>     ie, the type of an integer constant should be the same as the type of
>     its min/max values."
> 
> No, the type of the bounds of a subtype should be the *base type*.  That's
> how the tree has always looked, as far back as  I can remember.

This is because intermediate computations can produce results
outside the subtype range but within the base type range (RM 3.5(6)),
right?

 type T1 is range 0 .. 127; 
 -- Compiler will choose some type for T'Base, likely to be -128..127 
 -- but could be Integer (implementation dependant)
 subtype T is T1 range 0 .. 100; 
 R : T := 100+X-X; 
 -- guaranteed work as long 100+X<=T'Base'Last and 100-X>=T'Base'First

Laurent