This is the mail archive of the
`gcc@gcc.gnu.org`
mailing list for the GCC project.

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |

Other format: | [Raw text] |

*From*: "Ulrich Weigand" <uweigand at de dot ibm dot com>*To*: joseph at codesourcery dot com (Joseph Myers)*Cc*: gcc at gcc dot gnu dot org*Date*: Mon, 27 Jan 2020 19:26:12 +0100 (CET)*Subject*: Re: fast_math_flags_set_p vs. set_fast_math_flags inconsistency?

Joseph Myers wrote: > 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. OK, agreed. > > 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. I see. I guess that makes me wonder what -fno-fast-math *ever* does (except canceling a -ffast-math earlier on the command line). Looking at the current code, -fno-fast-math (just like -ffast-math) only ever sets flags whose default is not overridden on the command line, but then it always sets them to their default value! Am I missing something here? If that's the intent, it might be cleaner to write set_fast_math_flags as just one big if (set) { } > 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. OK. > > 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. This also makes sense if we consider the semantics of -fno-fast-math to just leave all component flags at their default, as above ... (As an aside, the current code is even more confusing as it has a dead condition: if (set) { if (opts->frontend_set_flag_excess_precision == EXCESS_PRECISION_DEFAULT) opts->x_flag_excess_precision = set ? EXCESS_PRECISION_FAST : EXCESS_PRECISION_DEFAULT; The second test of "set" must always be true here, so this will never actually actively set the flag to EXCESS_PRECISION_DEFAULT.) Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com

**Follow-Ups**:**Re: fast_math_flags_set_p vs. set_fast_math_flags inconsistency?***From:*Joseph Myers

**References**:**Re: fast_math_flags_set_p vs. set_fast_math_flags inconsistency?***From:*Joseph Myers

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |