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.