> 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. > 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.
