[PATCH] Fix optimization regression in constant folder

[Michael Matz]

Hi,

On Thu, 11 Oct 2007, Ian Lance Taylor wrote:

> Michael Matz <matz@suse.de> writes:
> 
> > > One can argue about what those properties ought to be, but they clearly 
> > > have *some* properties!
> > 
> > Of course.  I think "unsigned, wrapping overflow" are these properties, 
> > hence no need for a special sizetypiness.
> 
> Look for the case
>       if ((TYPE_OVERFLOW_UNDEFINED (ctype)
> 	   || (TREE_CODE (ctype) == INTEGER_TYPE && TYPE_IS_SIZETYPE (ctype)))
> in fold-const.c.
> 
> That is an optimization that sizetypes should have but that unsigned
> wrapping types do not.

Hmm, so how do these transformation behave if presented with values (in 
sizetype) which _do_ overflow, e.g. from the reassociated example of Mark?
They will carry out the transformation and the resulting value then will 
be different?

E.g. one transformation it does is (X*c1)/c2 to X*(c1/c2) if c1%c2==0, for 
sizetypes (und OVERFLOW_UNDEFINED ones).

Suppose that X is the latter part of Marks reassociated expression, C-B, 
with B large, so that (C-B)*c1 would overflow.  Nevertheless the 
transformation would be done, resulting in a different outcome.  The 
reassoc was okay because this was in sizetype (or as I argue in any 
overflow wrapping unsigned type), but the fold-const transformation was 
invalid.  _Even_ with sizetype.  So, I'm not sure if that special-casing 
of sizetype in fold-const is even correct.  If you disagree, why?


Ciao,
Michael.