[RFC] Fix PR28684

[Revital1 Eres]

> 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