[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense

[rguenther at suse dot de]

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.