On Sun, 2006-02-19 at 20:15 +0100, Eric Botcazou wrote: > >"Now for the first "oddity". If we look at the underlying type > > for last we have a type "natural___XDLU_0__2147483647". What's > >interesting about it is that it has a 32bit type precision, but > > the min/max values only specify 31 bits. ie, the min/max values > > are 0, 0x7fffffff." > > That's an old problem, which has already been discussed IIRC: should > TYPE_MAX_VALUE/TYPE_MIN_VALUE be constrained by TYPE_PRECISION and > TYPE_UNSIGNED? My feeling? Absolutely, TYPE_MIN_VALUE and TYPE_MAX_VALUE should represent the set of values that an object of the type may hold. Any other definition effectively renders those values useless.
ie, if an object can have the values 0..128 at runtime, then TYPE_MIN_VALUE/TYPE_MAX_VALUE must cover that entire range. 0..128. If TYPE_MIN_VALUE/TYPE_MAX_VALUE only cover 0..127, then that's a bug. I suspect we get this behavior from the Ada front-end as a side effect of the language and possibly the need to do runtime bounds checking on object values. But that's no excuse for a front-end to lie about the bounds of an object. It'll be tedious, but I guess possible to have VRP look one level deeper into the type to get a max/min value. But that's really a bandaid IMHO. > > Then: > > "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." > > I think that one is new and again pertains to TYPE_MAX_VALUE/TYPE_MIN_VALUE. This is probably a secondary issue. We end up ping-ponging both on values for the range *and* on the type of the range. I suspect but can not verify yet that ping-ponging on the type of the range will result in infinite iteration as well. I'm willing to table this until we get the TYPE_MIN/TYPE_MAX stuff resolved at which point we can verify VRP's behavior when the types ping-pong. jeff
