This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Fix PR28684
- From: Revital1 Eres <ERES at il dot ibm dot com>
- To: Clint Whaley <whaley at cs dot utsa dot edu>, roger at eyesopen dot com, rguenther at suse dot de
- Cc: Ayal Zaks <ZAKS at il dot ibm dot com>, Dorit Nuzman <DORIT at il dot ibm dot com>, gcc-patches at gcc dot gnu dot org, whaley at cs dot utsa dot edu
- Date: Thu, 16 Nov 2006 15:25:52 +0200
- Subject: Re: [RFC] Fix PR28684
> It doesn't seem obvious to me why reordering the operations messes up the
> sign on zero (AFAIK that's not order based?), can you clarify? As to if
> it's OK, like the guys who care about order, I think the times you need
> positive/negative zero differentiation are very rare, so it won't keep
people
> from using the flag. However, if it can occur, it should probably be
mentioned
> in the flag definition, as I don't think it is obvious (at least to me)
why
> it would happen from the present description. Probably it would be more
> obvious if I understood the details of the gcc optimization phases, but
> I doubt your average user (even the numerically aware ones) will know
this
> info either . . .
Hmmm, I'm not sure this is a good example; Richard - maybe
you have better example that demonstrate this; anyway,
considering the transformation which handle
(A1 * C1) - (A2 * C2) with A1, A2 or C1, C2 being the
same or one. (taken from fold-const.c)
Where C1 = C2 = -1 and A1 = A2
Than (A1 * C1) - (A2 * C2) = +0.0
and (A1 - A2) * C1 = -0.0
Which is like -(X-Y) -> Y-X , right?
The patch in http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00843.html
list transformations which are currently under -unasfe-flag-optimizations
and adequate for the new definition. It seems that signed zero is the only
violation of IEEE we have and should mention in the definition.
Thanks,
Revital