On Tue, 21 Jan 2020, Ulrich Weigand wrote: > It looks like there's multiple cases here. For the two flags > -fassociative-math and -freciprocal-math, it seems to have happened just as > you describe: they were created (split out of -funsafe-math-optimizations) > in commit a1a826110720eda37c73f829daa4ee243ee953f5, which however did not > update fast_math_flags_set_p.
So that's a bug. > For the other three flags, -fsignaling-nans, -frounding-math, and > -fcx-limited-range, the story appears to be a bit different: from the The first two of those are disabled by default as well as disabled by -ffast-math, so it seems right that -fno-fast-math does nothing with them and that they aren't checked by fast_math_flags_set_p. The last one is disabled by default but enabled by -ffast-math. So it would seem appropriate to handle it like other such options, disable it with -fno-fast-math, and check it in fast_math_flags_set_p. > Finally, there is one "mixed" flag, -fexcess-precision, which is handled > like the above three in that its default is only modified as a result of > -ffast-math, not -fno-fast-math; but nevertheless this flag *is* checked > in fast_math_flags_set_p. That one's trickier because the default depends on whether a C standards conformance mode is specified. -- Joseph S. Myers jos...@codesourcery.com