https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #17 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 21 Feb 2020, bugdal at aerifal dot cx wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806 > > --- Comment #10 from Rich Felker <bugdal at aerifal dot cx> --- > I don't think it's at all clear that -fno-signed-zeros is supposed to mean the > programmer is promising that their code has behavior independent of the sign > of > zeros, and that any construct which would be influenced by the sign of a zero > has undefined behavior. I've always read it as a license to optimize in ways > that disregard the sign of a zero or change the sign of a zero, but with > internal consistency of the program preserved. > > If -fno-signed-zeros is really supposed to be an option that vastly expands > the > scope of what's undefined behavior, rather than just removing part of Annex F > and allowing the unspecified quality of floating point results that C > otherwise > allows in the absence of Annex F, it really needs a much much bigger warning > in > its documentation! -fno-signed-zeros internally tells GCC that the hardwares FP format does not distinguish between -0.0 and 0.0 (not sure if that makes sense). There's always the question what these kind of options mean when GCC is present with a literal -0.0 (or Inf/NaN with -ffinite-math-only) or an explicit sign or finiteness check but we've historically erred on the "optimize" side here.
