> Anyway, hopefully Eric and Jeff can work together in identifying the
> proper fix.
Jeff already did a thorough analysis of the problem (thanks!) and came to the
following double conclusion. Quoting him:
"First, the inconsistency between the type's precision in its min/max
values needs to be fixed. Most likely this is an Ada FE problem."
more precisely:
"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?
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.
Clearly Ada stretches a lot more VRP than C-based languages because of its
subtypes with non-canonical bounds. However, there always should be the base
type at hand when things go awry; for example in int_fits_type_p
/* If we haven't been able to decide at this point, there nothing more we
can check ourselves here. Look at the base type if we have one and it
has the same precision. */
if (TREE_CODE (type) == INTEGER_TYPE
&& TREE_TYPE (type) != 0
&& TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (type)))
return int_fits_type_p (c, TREE_TYPE (type));
Richard, what do you think?
--
Eric Botcazou
