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 ...
