From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) by sourceware.org (Postfix) with ESMTPS id 36D983858D32 for ; Mon, 18 Sep 2023 10:37:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 36D983858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-2bffdf50212so18561141fa.1 for ; Mon, 18 Sep 2023 03:37:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695033475; x=1695638275; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=fcYi2m8L0zapXX44E0+qYl3DvR39/5+VbvlmAjjJ2is=; b=ZzEr3jUTflyHFv/QqaEIiqtEyv3sTgg6D9Tdt7Yunziivjh2l4Gvl6nEKt3+mvIp5P vZQFQv4OFnaQ+B8Sk0R3Do37dxWGKzGNRDOPwY5L3UOv5tDjuxqOfMoO64/5wVezowgk dm7hFIesArjOx0+iojEJubiP7cjNJrzgY/OAnUqMDp4TQKYXrb4VD/EY/rC90JI3AbMX P9/RXB4qBsbq+7U2fp0ijutUUOKc5/CCYGkgvhijPgjrSKLVnQtTlEjhIQ4i3zcCqGkK J18CkbDy6expxqVmrHXMnd756I/iUW3uKwxvQKJ2PXmghy/ryUZVg1gfjCtHZpaoSZFi FhtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695033475; x=1695638275; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fcYi2m8L0zapXX44E0+qYl3DvR39/5+VbvlmAjjJ2is=; b=d5bzkNM+531wiUfvNXx+EtiBQB79y3T5aJ7HGi/1YzBs756/DeKNA+oKMM9s3vsW0u D0NIdu287FZVkqxOsQRcJXQxofzOf5ir56shvB1ox48ZseQCOl5HwToPmWDxPvUR65gt PrVRxSucdD9UjtXPJae+B0/KzUlGq/t2xVmHxsoLackdtwIXol5O5nlOZJb+nNUJIACq tOh+q7hGDMMAYNgaxvDPe0fIO4ijTxINmjlA6z1gzRGCvGFkk4GBrZ3P3SKsou3eemZP 8srvkU93Cqu/cyVeRVUVpfuYkumYtBhlnSuMhTxHdcloPtKoD5YfzOElCHJBRFmmuTmU tAhQ== X-Gm-Message-State: AOJu0Yy5V5KtgBGI2VRjBjrz9UnMCKS6o2q2MRn/pbqlIIvz9NBn4r6f 7D1IAnftFUdOTZh+gvqfank6SM+5QXfh2QC6P6U= X-Google-Smtp-Source: AGHT+IEzPrVyuE4yGTOcz7omygFrZkTa+Cuw3LbKMGBsH+emGTF/eIBqWtQcYyjmBpEHuXT7QZZR/tKO0tUqMcaHjmA= X-Received: by 2002:a05:6512:604:b0:503:303:9e2d with SMTP id b4-20020a056512060400b0050303039e2dmr4304563lfe.5.1695033475313; Mon, 18 Sep 2023 03:37:55 -0700 (PDT) MIME-Version: 1.0 References: <87r0n01z18.fsf@oldenburg3.str.redhat.com> <21e46cef-1fbf-df87-608d-52b7f894dea7@ispras.ru> <877condc69.fsf@oldenburg.str.redhat.com> In-Reply-To: <877condc69.fsf@oldenburg.str.redhat.com> From: Richard Biener Date: Mon, 18 Sep 2023 12:37:43 +0200 Message-ID: Subject: Re: Concerns regarding the -ffp-contract=fast default To: Florian Weimer Cc: Alexander Monakov , gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPAM_BODY,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, Sep 18, 2023 at 12:10=E2=80=AFPM Florian Weimer wrote: > > * Richard Biener: > > >> > > GCC contraction behavior is rather inconsistent. It does not cont= ract x > >> > > + x - x without -ffast-math, for example, although I believe it wo= uld be > >> > > permissible under the rules that enable FMA contraction. This who= le > > > > Is that really just x + x - x? We currently gate simplifying x - x to = zero > > on no-signed-zeros and round-to-nearest and have no special > > handling for x + x - x. > > It's just an example I made up, and checked that GCC wouldn't optimize > it by default (without -ffast-math et al.). I believe the rule that GCC > invokes to introduce FMA under -ffp-contract=3Dstandard (and > -ffp-contract=3Dfast) would apply to these contractions as well. > > Or put differently, -ffp-contract=3D seems to be exclusively about FMA, > while the option name and description is more generic. > > x - x is different because replacing it with 0 doesn't seem to be a > valid contraction because it's incorrect for NaNs. x + x - x seems to > be different in this regard, but in our implementation, there might be a > quirk about sNaNs and qNaNs. > > >> The "correctness trumps performance" principle still applies, and > >> -ffp-contract=3Dfast (the current default outside of -std=3DcNN) is > >> known to cause correctness issues and violates the C language standard= . > >> And -ffast[-and-loose]-math for is not going away. > > > > I think that changing the default to =3Dstandard without -ffast-math is > > reasonable. IIRC the standard allows such default if it's indicated, > > so it doesn't require =3Doff anywhere. > > How much numerical code is compatible with that? For example, David > Goldberg's What Every Computer Scientist Should Know About > Floating-Point Arithmetic (revised) contains this sentence: > > | A language definition that does not require parentheses to be honored > | is useless for floating-point calculations. > > I suppose that applies to re-association not honoring parens. With C you either have no re-association (fine) or re-association but globally, at the expense of violating the standard. FP contraction is _not_ about honoring parens, the 'error' introduced by is subtle. Fortran for example allows re-association by default, but honors parens. GCC can do this just fine. > Few people have access to the IEEE 754 standard, and Goldberg's article > is therefore widely quoted as gospel. If I understand this correctly, > according to Goldberg, contractions make C =E2=80=9Cuseless=E2=80=9D. Bu= t I'm not a > floating point person, and I nowadays regret that I looked down upon the > numerical methods people at university. No, I don't think it says that. Fortran also allows contraction (but not across parens). Richard. > Thanks, > Florian >