https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88152

--- Comment #5 from Matthias Kretz <kretz at kde dot org> ---
> -fno-signed-zeros isn't a guarantee the operand will not be -0.0 and having
> x < 0.0 behave differently based on whether x is -0.0 or 0.0 (with
> -fno-signed-zeros quite randomly) is IMHO very bad.

I agree this isn't obviously correct. But I stared long and hard at the manpage
before writing that comment. From the manpage:
> Allow optimizations for floating-point arithmetic that ignore the signedness
> of zero. IEEE arithmetic specifies the behavior of distinct +0.0 and -0.0
> values, which then prohibits simplification of expressions such as x+0.0 or
> 0.0*x (even with -ffinite-math-only).  This option implies that the sign of a
> zero result isn't significant.

1. The movmsk(x<0) => movmsk(x) transformation is an "optimization for
floating-point arithmetic that ignores the signedness of zero" - except that
it's not really an arithmetic operation. But then again -ffinite-math-only
turns isnan(x) into false ("Allow optimizations for floating-point arithmetic
that assume that arguments and results are not NaNs")

2. I based my argument mostly on this part, though: "This option implies that
the sign of a zero result isn't significant". I interpret it as "if the result
of f() is zero, it's sign is not significant in the expression f()<0".
Consequently, we can assume the sign to be positive.

Feel free to disagree. I just wanted to explain how I read the GCC
documentation on -fno-signed-zeros. If that's not the intended reading, I'd be
happy to help clarify the documentation.

Reply via email to