From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76128 invoked by alias); 7 Feb 2020 16:47:40 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 76118 invoked by uid 89); 7 Feb 2020 16:47:39 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.7 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=interpretation, ulrich, tapping, Ulrich X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 07 Feb 2020 16:47:38 +0000 Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 017GdA1j124340 for ; Fri, 7 Feb 2020 11:47:36 -0500 Received: from e06smtp05.uk.ibm.com (e06smtp05.uk.ibm.com [195.75.94.101]) by mx0a-001b2d01.pphosted.com with ESMTP id 2xyhn5fsd9-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 07 Feb 2020 11:47:36 -0500 Received: from localhost by e06smtp05.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 7 Feb 2020 16:47:34 -0000 Received: from b06cxnps3074.portsmouth.uk.ibm.com (9.149.109.194) by e06smtp05.uk.ibm.com (192.168.101.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Fri, 7 Feb 2020 16:47:33 -0000 Received: from d06av24.portsmouth.uk.ibm.com (d06av24.portsmouth.uk.ibm.com [9.149.105.60]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 017GlW4w18088066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 7 Feb 2020 16:47:32 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8DD8A42042; Fri, 7 Feb 2020 16:47:32 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 76A8F42045; Fri, 7 Feb 2020 16:47:32 +0000 (GMT) Received: from oc3748833570.ibm.com (unknown [9.152.214.26]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Fri, 7 Feb 2020 16:47:32 +0000 (GMT) Received: by oc3748833570.ibm.com (Postfix, from userid 1000) id 24E0DD802A9; Fri, 7 Feb 2020 17:47:32 +0100 (CET) Subject: Re: [PATCH] Fix -ffast-math flags handling inconsistencies To: richard.guenther@gmail.com (Richard Biener) Date: Fri, 07 Feb 2020 16:47:00 -0000 From: "Ulrich Weigand" Cc: gcc-patches@gcc.gnu.org (GCC Patches), joseph@codesourcery.com (Joseph S. Myers) In-Reply-To: from "Richard Biener" at Feb 05, 2020 10:58:04 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit x-cbid: 20020716-0020-0000-0000-000003A80A06 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 20020716-0021-0000-0000-000021FFDE25 Message-Id: <20200207164732.24E0DD802A9@oc3748833570.ibm.com> X-SW-Source: 2020-02/txt/msg00451.txt.bz2 Richard Biener wrote: > On Fri, Jan 31, 2020 at 6:01 PM Ulrich Weigand wrote: > > The overall effect of this patch is that now all component flags of > > -ffast-math are treated exactly equivalently: > > * they are set (changed from their default) with -ffast-math > > * they are reset to their default with -fno-fast-math > > * __FAST_MATH__ is only defined if the value of the flag matches > > what -ffast-math would have set it to > > The last part is not obviously correct to me since it doesn't match > documentation which says > > @item -ffast-math > @opindex ffast-math > Sets the options @option{-fno-math-errno}, @option{-funsafe-math-optimizations}, > @option{-ffinite-math-only}, @option{-fno-rounding-math}, > @option{-fno-signaling-nans}, @option{-fcx-limited-range} and > @option{-fexcess-precision=fast}. > > This option causes the preprocessor macro @code{__FAST_MATH__} to be defined. > > to me this reads as -ffast-math -fexcess-precision=standard defines > __FAST_MATH__. > The only relevant part to define __FAST_MATH__ is specifying -ffast-math, other > options are not relevant (which of course is contradicted by > implementation - where > I didn't actually follow its history in that respect). So can you > adjust documentation > as to when exactly __FAST_MATH__ is defined? Agreed. This should probably be worded something along the lines of: "Whenever all of those options are set to these values as listed above, the preprocessor macro @code{__FAST_MATH__} will be defined." > > - if (!opts->frontend_set_flag_signaling_nans) > > - opts->x_flag_signaling_nans = 0; > > - if (!opts->frontend_set_flag_rounding_math) > > - opts->x_flag_rounding_math = 0; [...] > > + // -ffast-math should also reset -fsignaling-nans and -frounding-math, > > + // but since those are off by default, there's nothing to do for now. > ... > > but what happens to -fsignalling-nans -ffast-math then? Better leave those > in I'd say. Ah, it seems I was confused about the intended semantics here. I thought that a *more specific* option like -fsignalling-nans was always intended to override a more generic option like -ffast-math, no matter whether it comes before or after it on the command line. Is it instead the case that the intended behavior is the generic option overrides the specific option if the generic option comes later on the command line? In that case, I agree that those should be left in. However, then I think it would be good to add tests for !flag_signaling_nans / !flag_rounding_math to fast_math_flags_set_p, because with these options on, we aren't really in fast-math territory any more ... > Note frontends come into play with what is considered -ffast-math > and -fno-fast-math but below flags are tested irrespectively of that > interpretation. > > Note there's -fcx-fortran-rules similar to -fcx-limited-range but not tested > above. The canonical middle-end "flag" to look at is flag_complex_method. > Somehow -fcx-fortran-rules doesn't come into play at all above but it > affects -fcx-limited-range in another inconsistent way in that > -fcx-limited-range -fcx-fortran-rules and -fcx-fortran-rules -fcx-limited-range > behave the same (-fcx-fortran-rules takes precedence...). I guess > -fcomplex-method=ENUM should be exposed and -fcx-* made > appropriate aliases here. I agree it would probably be the best if to use a -fcomplex-method=... flag, handled analogously to -fexcess-precision in that it defaults to an explicit DEFAULT value; unless this is overridden by an explicit command line flag, the language front-end can then choose what DEFAULT means for this particular language. However, I'd prefer to not include that change into this patch as well :-) This patch only changes the behavior related to -fcx-limited-range in one very special case (-Ofast -fno-fast-math), where it makes it strictly better. It should not affect the (existing) interaction with -fcx-fortran-rules at all -- so anything to improve this can be done in a separate patch, I think. > You're tapping into a mine-field ;) That's for sure :-) Thanks, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com