On 2/24/06, Jeffrey A Law <[EMAIL PROTECTED]> 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.
