On Tue, 2006-02-21 at 15:40 -0500, Richard Kenner wrote:
> So in the case above, the set of permissible values is
> [1, 0x7fffffff] after the addition, right?
>
> Well, not quite. The addition isn't done in type X, but in type X'Base,
> which does not have the restricted TYPE_{MIN,MAX}_VALUES. But, as we've all
> said, there are conversions in there so VRP can use it's normal logic.
Umm, why bring up the basetype nonsense at all. The arithemtic
is done in whatever type is associated with the expression, not
the base type. Nothing else makes sense. ie, conversions are
explicit.
>
> If you have a different case:
>
> type X is range 0 .. 16#7fff_ffff#;
>
> Y, Z : X;
>
> Z : = Y + 1;
>
> you can then conclude that [1, 0x7fffffff] is the permissible values
> for Z. But what the last statement actually becomes (in pseudo-C) is:
>
> Z = (X) ((X'Base) Y + (X'Base) 1);
>
> So the above is not the range for the *addition* (which has the type
> unrestricted by the bounds), just for Z. The reason this distinction is
> relevant is that if checking is enabled, the conversion to X will involve
> a bounds check. VRP should be able to deduce that the bounds check can
> be replaced by "/= 0x80000000" and that is indeed a correct deduction.
You're just making things more complicated -- we don't have to
worry about base types, any base type stuff should be explicit,
I don't think there's any argument about that.
So, back to my example. If I have an object with a range
[0, 0x7fffffff] based on the type of the object and I add
one to that object, then I can safely conclude that the
result of the addition has the range [1, 0x7fffffff]. Right?
Jeff
