https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 19 Feb 2020, vincent-gcc at vinc17 dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806 > > --- Comment #4 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> --- > (In reply to Richard Biener from comment #3) > > with -funsafe-math-optimizations you get the 1 + x != 1 -> x != 0 > > optimization which is unsafe because a rounding step is removed. > > But you asked for that. So no "wrong-code" here, just another case > > of "instabilities" or how you call that via conditional equivalence > > propagation. > > I disagree. -funsafe-math-optimizations just means that floating-point > expressions can be rearranged at the source level according to math rules > (valid in the real numbers), thus changing how rounding is done. >From below I implicitely assume you say that "1. + x != 1." -> "x != 0." isn't "rearranging at the source level". Note our documentation on -funsafe-math-optimizations is quite vague and I'd argue that "rearranging at the source level" is covered by -fassociative-math instead. It's not clear how to classify the above specific transform though. There's -ffp-contract which also enables removing of rounding steps. So the classification as "unsafe" is probably correct (and vague). Even only associating differently, like if you'd have 1 + x + x != 1 and re-arrange it as 1 + (x + x) != 1 may change the outcome of the comparison (and the outcome of a comparison is an integer). So my answer to you would be - if you don't like them, don't use any of the special math "optimization" flags.
