This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Fold and integer types with sub-ranges
On Fri, 23 Feb 2007, Duncan Sands wrote:
> > Currently for example in fold_sign_changed_comparison we produce
> > integer constants that are not inside the range of its type values
> > denoted by [TYPE_MIN_VALUE (t), TYPE_MAX_VALUE (t)]. For example
> > consider a type with range [10, 20] and the comparison created by
> > the Ada frontend:
> >
> > if ((signed char)t == -128)
> >
> > t being of that type [10, 20] with TYPE_PRECISION 8, like the constant
> > -128. So fold_sign_changed_comparison comes along and decides to strip
> > the conversion and convert the constant to type T which looks like
> ...
> > What do we want to do about that? Do we want to do anything about it?
> > If we don't want to do anything about it, why care about an exact
> > TREE_TYPE of integer constants if the only thing that matters is
> > signedness and type precision?
>
> I don't think gcc should be converting anything to a type like t's unless
> it can prove that the thing it's converting is in the range of t's type. So
> it presumably should try to prove: (1) that -128 is not in the range of
> t's type; if it's not, then fold the comparison to false; otherwise (2) try
> to prove that -128 is in the range of t's type; if so, convert it. Otherwise
> do nothing.
>
> That said, this whole thing is a can of worms. Suppose the compiler wants to
> calculate t+1. Of course you do something like this:
>
> int_const_binop (PLUS_EXPR, t, build_int_cst (TREE_TYPE (t), 1), 0);
>
> But if 1 is not in the type of t, you just created an invalid value!
Eeek ;) True. Another reason to not force us creating 1s and 0s in
such cases but allow simply
int_const_binop_int (PLUS_EXPR, t, 1)
of course while int_const_binop will truncate the result to its
TYPE_PRECISION one still needs to make sure the result fits in t.
That is, all the fancy TREE_OVERFLOW stuff only cares about
TYPE_PRECISION and never about the types 'true' range via min/max value.
> Personally I think the right thing to do is to eliminate these types
> altogether somewhere early on, replacing them with their base types
> (which don't have funky ranges), inserting appropriate ASSERT_EXPRs
> instead. Probably types like t should never be seen outside the Ada
> f-e at all.
Heh - nice long-term goal ;) Might raise the usual
wont-work-for-proper-debug-info complaint though.
Richard.