Hi! 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! 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! Segher
