https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84891
--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 19 Mar 2018, no...@turm-lahnstein.de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84891 > > --- Comment #4 from ead <no...@turm-lahnstein.de> --- > From my naive point of view: > > - The c++ standard doesn't define how complex-number-multiplication should > work, it is implementation defined/gcc-specific (I'm not a standard-scholar, > so > might be very wrong about it). > > - One can deduce from the results in the IEEE 754 mode, how this > multiplication (implementation-defined and gcc-specific) is implemented. > > - One's expectation with -fno-signed-zeros is that only transformations > which honor infs/nans can be performed by the optimizer. Clearly, we cannot > refer to the standard to see, what the result with -fno-signed-zeros should > be, > because -fno-signed-zeros is not covered by standard, but is a gcc-specific > option. > > So in this case, the effect of -fno-signed-zeros is not covered by the > description in the man-pages (at least as I understand that): > > > > -fno-signed-zeros > > 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. > > The default is -fsigned-zeros. The implementation might choose to make complex multiplication with NaN have either the real or imag part NaN and not exactly specify which one. I previously said in this bug that the way tree-complex.c guards against signed-zeros is awkward and overly pessimistic.
