This is the mail archive of the 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: [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
> from using the flag.  However, if it can occur, it should probably be
> in the flag definition, as I don't think it is obvious (at least to me)
> 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
> 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
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.


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