Re: Ada subtypes and base types

["Richard Guenther" <richard dot guenther at gmail dot com>]

On 2/24/06, Jeffrey A Law <law@redhat.com> wrote:
> On Wed, 2006-02-22 at 13:25 -0500, Richard Kenner wrote:
> >      When I speak about doing arithmetic in a type, I'm referring to the
> >      type of the expression & its input operands in a gimplified
> >      expression.  At that point I do not care about base types or anything
> >      like that.  All that should matter is TREE_TYPE (expr), nothing more,
> >      nothing less.  How the inputs are converted or how the output is later
> >      converted is not a concern -- all that matters is TREE_TYPE (expr) in
> >      a gimplified tree.
> >
> >      Can we agree on that?
> >
> > Yes.
> >
> > The base type reference is that I'm *also* saying "If you see an arithmetic
> > node where TREE_TYPE is *not* a base type, there's a bug someplace that
> > has to be fixed". (Well, with the exception of such things as sizetypes
> > or subtypes that don't actually change anything.)
> Just to make sure I've dotted the i's and crossed the t's, this
> is not what's happening when we hang in VRP when compiling a-textio.
>
> We convert the incoming object from natural___XDLU_0___2147483647
> into its base type, perform the addition in the base type, then
> convert back to XDLU_0_2147483647.

Which is exactly what I would expect, i.e. fine.  So VRP can assume for

 (XDLU..) ( (base) a + (base) b )

that a and b have values in the range of natural ___XDLU_0___2147483647,
the sum is in range of the base type and this result get's truncated again to
___XDLU_0___2147483647.

Which is my understanding of Ada semantics.  There is nothing in Ada semantics
as far as I understand that requires possible overflow to be preserved
until after
the cast to (XDLU..) for checking with 'Valid - if there is, Ada needs to use an
explicit unchecked conversion which again has to be implemented using a
VIEW_CONVERT_EXPR.

Any other semantics don't make sense, so the middle-end ought to use these
semantics and bugs in the middle-end and the Ada frontend uncovered by it
fixed.  Better soon than later.

Richard.