On Mon, 2006-02-20 at 22:00 +0100, Richard Guenther wrote: > On 2/20/06, Jeffrey A Law <[EMAIL PROTECTED]> 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
