[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 #38 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 4 Mar 2020, vincent-gcc at vinc17 dot net wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
> 
> --- Comment #37 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
> (In reply to rguenther@suse.de from comment #36)
> > We're actually careful about the sign of zero here when recording
> > requivalences for propagation.
> 
> But shouldn't the use of -fno-signed-zeros imply that the sign of zero never
> matches (i.e. the actual sign is unknown, because unsafe optimizations could
> have modified it in an inconsistent way)?

There's no rigorous definition of what -fno-signed-zeros implies and I
fear we'll not arrive at something consistent.  We err on the side
of enabling optimizations that look useful even if those might
result in conflicting such "definitions".  -fno-signed-zeros to
a simple minded person means all zeros have positive sign.  That's
how we treat -ffinite-math-only as well - there doesn't exist
any NaN so isnan() is always false (even if that's not exactly useful
for some people).