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.
