This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix optimization regression in constant folder


> The point is that (X*c1)/c2 and X*(c1/c2) are _different_ for some values 
> of X,c1 and c2 (namely sometimes but not all the time when X*c1 
> overflows).  Assuming that the first value was the correct one (for 
> instance zero) we will have introduced a miscompilation.  We have two ways 
> for fixing this:
> 1) declare the precondition (the initial overflow) to be invalid.
> 2) don't do the transformation in flow
> 
> Solution (1) would require that overflow in sizetype is not ignored, but 
> undefined.  Then we couldn't have done the reassociation which created 
> this problem.  But that is something you explicitely didn't want.
> 
> Solution (2) would require removing the exception for sizetype, at which 
> point it again looks more like an unsigned wrapping type.

Again, you are trying to interpret the semantics of sizetypes in terms of
those more-properly used for user-defined types.  As you say, sizetypes
have the property that if the "complete" expression would overflow, the
program is illegal, so the above transformation is fine.  But for the
association operations, we want to act as if it wrapped.

But what's the problem here?  We have a flag, TYPE_IS_SIZETYPE.  We have
a transformation and we want to decide if it's safe for sizetypes.  So we
look at it and figure it out, knowing what we know about sizetypes.  If it's
safe, we say "|| TYPE_IS_SIZETYPE" and if not we say "&& !TYPE_IS_SIZETYPE".
It's as simple as that.  There's no reason why we have to try to invent
yet another flag that describes the semantics: we already have one that
does the job just fine!


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]