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

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
> 
> --- Comment #35 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
> > > * Memory analysis. Again, the sign does not matter, but for instance,
> > > reading an object twice as a byte sequence while the object has not been
> > > changed by the code must give the same result. I doubt that this is affected
> > > by optimization.
> > 
> > Working with objects on byte level is often optimized too:
> 
> Indeed, there could be invalid optimization... But I would have thought that in
> such a case, the same kind of issue could also occur without -fno-signed-zeros.
> Indeed, if x == y, then this does not mean that x and y have the same memory
> representation. Where does -fno-signed-zeros introduce a difference?
> 
> Note: There's also the case of IEEE 754 decimal floating-point formats (such as
> _Decimal64), for instance, due to the "cohorts", where two identical values can
> have different memory representations. Is GCC always correct here?

We're actually careful about the sign of zero here when recording
requivalences for propagation.  I don't see anything preventing
equivalence based propagation for decimal floats though.
Also not sure if actual FP formats are required to be always
normalized ...