Joseph Myers wrote: > On Mon, 20 Jan 2020, Ulrich Weigand wrote: > > > This has the effect that e.g. after > > > > -ffast-math -fno-finite-math-only > > > > the __FAST_MATH__ macro is no longer predefined, but after > > > > -ffast-math -fno-associative-math > > > > the __FAST_MATH__ macro still *is* predefined, even though both > > -ffinite-math-only and -fassociative-math are implied by -ffast-math. > > > > Is this deliberate? (If so, is it documented somewhere?) > > I'd expect both to cause it to be undefined. My guess would be that some > past patch, after fast_math_flags_set_p was added, added more flags to > -ffast-math but accidentally failed to update fast_math_flags_set_p; you'd > need to look at past patches adding flags to -ffast-math to confirm if > it's accidental.
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. For the other three flags, -fsignaling-nans, -frounding-math, and -fcx-limited-range, the story appears to be a bit different: from the very beginning, those were treated somewhat differently: these are only modified as a result of -ffast-math, not -fno-fast-math (like the other flags derived from -ffast-math), and they are not considered by fast_math_flags_set_p. (I'm not sure if there is any particular reason why these should be treated differently here, though.) 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. Do you think there is something that ought to be fixed here? Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
