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 rguent...@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).
