Re: Fold and integer types with sub-ranges

[Richard Guenther <rguenther at suse dot de>]

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.