public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ulrich Weigand <uweigand@de.ibm.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: law@redhat.com, gcc-patches@gcc.gnu.org, joseph@codesourcery.com,
	richard.guenther@gmail.com
Subject: [wwwdocs] Re: [PATCH v2] Fix -ffast-math flags handling inconsistencies
Date: Tue, 24 Nov 2020 11:55:23 +0100	[thread overview]
Message-ID: <20201124105523.GA14751@oc3748833570.ibm.com> (raw)
In-Reply-To: <20201121195732.GF2672@gate.crashing.org>

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.Weigand@de.ibm.com

  reply	other threads:[~2020-11-24 10:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-11 18:43 Ulrich Weigand
2020-02-11 23:56 ` Segher Boessenkool
2020-11-21  4:33 ` Jeff Law
2020-11-21 19:57   ` Segher Boessenkool
2020-11-24 10:55     ` Ulrich Weigand [this message]
2020-11-24 17:19       ` [wwwdocs] " Segher Boessenkool
2020-11-24 18:42   ` Ulrich Weigand
2020-11-24 23:23     ` Segher Boessenkool
2020-11-25 13:12     ` Christophe Lyon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201124105523.GA14751@oc3748833570.ibm.com \
    --to=uweigand@de.ibm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=joseph@codesourcery.com \
    --cc=law@redhat.com \
    --cc=richard.guenther@gmail.com \
    --cc=segher@kernel.crashing.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).