From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109317 invoked by alias); 27 Jan 2020 18:26:21 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 109306 invoked by uid 89); 27 Jan 2020 18:26:21 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=nevertheless, H*x:version, H*UA:version, canceling X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 27 Jan 2020 18:26:20 +0000 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00RIFYdD067746 for ; Mon, 27 Jan 2020 13:26:18 -0500 Received: from e06smtp02.uk.ibm.com (e06smtp02.uk.ibm.com [195.75.94.98]) by mx0a-001b2d01.pphosted.com with ESMTP id 2xrk2ee97t-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 27 Jan 2020 13:26:18 -0500 Received: from localhost by e06smtp02.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 27 Jan 2020 18:26:16 -0000 Received: from b06cxnps4076.portsmouth.uk.ibm.com (9.149.109.198) by e06smtp02.uk.ibm.com (192.168.101.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Mon, 27 Jan 2020 18:26:14 -0000 Received: from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com [9.149.105.61]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 00RIQDHu52887610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 27 Jan 2020 18:26:13 GMT Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F1EF811C04A; Mon, 27 Jan 2020 18:26:12 +0000 (GMT) Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E8EC511C052; Mon, 27 Jan 2020 18:26:12 +0000 (GMT) Received: from oc3748833570.ibm.com (unknown [9.145.2.110]) by d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTP; Mon, 27 Jan 2020 18:26:12 +0000 (GMT) Received: by oc3748833570.ibm.com (Postfix, from userid 1000) id 63BE1D803D2; Mon, 27 Jan 2020 19:26:12 +0100 (CET) Subject: Re: fast_math_flags_set_p vs. set_fast_math_flags inconsistency? To: joseph@codesourcery.com (Joseph Myers) Date: Tue, 28 Jan 2020 15:55:00 -0000 From: "Ulrich Weigand" Cc: gcc@gcc.gnu.org In-Reply-To: from "Joseph Myers" at Jan 21, 2020 04:58:40 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit x-cbid: 20012718-0008-0000-0000-0000034D2FBC X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 20012718-0009-0000-0000-00004A6DA655 Message-Id: <20200127182612.63BE1D803D2@oc3748833570.ibm.com> X-SW-Source: 2020-01/txt/msg00476.txt.bz2 Joseph Myers wrote: > On Tue, 21 Jan 2020, Ulrich Weigand wrote: > > > 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. > > So that's a bug. OK, agreed. > > For the other three flags, -fsignaling-nans, -frounding-math, and > > -fcx-limited-range, the story appears to be a bit different: from the > > The first two of those are disabled by default as well as disabled by > -ffast-math, so it seems right that -fno-fast-math does nothing with them > and that they aren't checked by fast_math_flags_set_p. I see. I guess that makes me wonder what -fno-fast-math *ever* does (except canceling a -ffast-math earlier on the command line). Looking at the current code, -fno-fast-math (just like -ffast-math) only ever sets flags whose default is not overridden on the command line, but then it always sets them to their default value! Am I missing something here? If that's the intent, it might be cleaner to write set_fast_math_flags as just one big if (set) { } > The last one is disabled by default but enabled by -ffast-math. So it > would seem appropriate to handle it like other such options, disable it > with -fno-fast-math, and check it in fast_math_flags_set_p. OK. > > 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. > > That one's trickier because the default depends on whether a C standards > conformance mode is specified. This also makes sense if we consider the semantics of -fno-fast-math to just leave all component flags at their default, as above ... (As an aside, the current code is even more confusing as it has a dead condition: if (set) { if (opts->frontend_set_flag_excess_precision == EXCESS_PRECISION_DEFAULT) opts->x_flag_excess_precision = set ? EXCESS_PRECISION_FAST : EXCESS_PRECISION_DEFAULT; The second test of "set" must always be true here, so this will never actually actively set the flag to EXCESS_PRECISION_DEFAULT.) Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com