On Fri, 23 Feb 2007, Richard Kenner wrote: > > 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! > > Yes, but why not do all arithmetic in the base type, just like Ada itself > does? Then you use 1 in that base type.
Sure - I wonder if there is a reliable way of testing whether we face a non-base type in the middle-end. I suppose TREE_TYPE (type) != NULL won't work in all cases... (?) > > 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. > > Not clear. There is the debug issue plus VRP can use the range information > for some things (we have to be very precise as to what). If we keep the model > of doing all arithmetic in the base type, there should be no problem. I agree. But appearantly fold does not care about base vs. non-base types and happily strips conversions between them, doing arithmetic in the non-base type. Now the question was whether we want to (try to) fix that for example by forcing gcc_assert (!TREE_TYPE (type)) on integer types in int_cst_binop and fold_binary and other places? Richard.
