On Sat, Nov 21, 2020 at 01:57:32PM -0600, Segher Boessenkool wrote: > On Fri, Nov 20, 2020 at 09:33:48PM -0700, Jeff Law wrote: > > On 2/11/20 11:43 AM, Ulrich Weigand wrote: > > > 1. If a component flag of -ffast-math (or -funsafe-math-optimizations) > > > is explicitly set (or reset) on the command line, this should override > > > any implicit change due to -f(no-)fast-math, no matter in which order > > > the flags come on the command line. This change affects all flags. > > > > > > 2. Any component flag modified from its default by -ffast-math should > > > be reset to the default by -fno-fast-math. This was previously > > > not done for the following flags: > > > -fcx-limited-range > > > -fexcess-precision= > > > > > > 3. Once -ffinite-math-only is true, the -f(no-)signaling-nans flag has > > > no meaning (if we have no NaNs at all, it does not matter whether > > > there is a difference between quiet and signaling NaNs). Therefore, > > > it does not make sense for -ffast-math to imply -fno-signaling-nans. > > > This is also a documentation change. > > > > > > 4. -ffast-math is documented to imply -fno-rounding-math, however the > > > latter setting is the default anyway; therefore it does not make > > > sense to try to modify it from its default setting. > > > > > > 5. The __FAST_MATH__ preprocessor macro should be defined if and only > > > if all the component flags of -ffast-math are set to the value that > > > is documented as the effect of -ffast-math. The following flags > > > were currently *not* so tested: > > > -fcx-limited-range > > > -fassociative-math > > > -freciprocal-math > > > -frounding-math > > > (Note that we should still *test* for -fno-rounding-math here even > > > though it is not set as per 4. -ffast-math -frounding-math should > > > not set the __FAST_MATH__ macro.) > > > This is also a documentation change. > > > It appears this was dropped on the floor.? It looks reasonable to me.? > > Please retest and commit.? Thanks!
I've now retested on s390x-ibm-linux and committed to mainline. Thanks for the review! > It all makes sense, and is a nice improvement :-) But please mention it > in the release notes? No doubt people did use non-sensical flag > combinations, and they will be affected. Thanks! Here's a proposed patch to update the gcc-11 changes.hmtl. OK to commit? Bye, Ulrich diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html index 46a6a37..c0f896a 100644 --- a/htdocs/gcc-11/changes.html +++ b/htdocs/gcc-11/changes.html @@ -58,6 +58,29 @@ a work-in-progress.</p> is deprecated and will be removed in a future release. It should be possible to use <code>--enable-cheaders=c_global</code> (the default) with no change in behaviour. </li> + + <li>Some inconsistencies in handling combinations of <code>-ffast-math</code>, + <code>-fno-fast-math</code>, <code>-funsafe-math-optimizations</code>, + <code>-fno-unsafe-math-optimizations</code>, and their component flags + have been fixed. This might change the behavior of the compiler when + invoked with certain combinations of such command line options. + The behavior is now consistently: + <ul> + <li>If a component flag of <code>-ffast-math</code> or + <code>-funsafe-math-optimizations</code> is explicitly set or reset + on the command line, this will override any implicit change, no matter + in which order the flags come on the command line.</li> + <li>Any component flag (which is not explicity set or reset on the command + line) that was modified from its default by <code>-ffast-math</code> or + <code>-funsafe-math-optimizations</code> is always reset to its default + by a subsequent <code>-fno-fast-math</code> or + <code>-fno-unsafe-math-optimizations</code>.</li> + <li><code>-ffast-math</code> no longer implicitly changes + <code>-fsignaling-math</code>. + <li>The <code>__FAST_MATH__</code> preprocessor macro is set if and + only if all component flags of <code>-ffast-math</code> are set + to the value documented as the effect of <code>-ffast-math</code>.</li> + </ul></li> </ul> -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com