From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id 629193858409 for ; Fri, 21 Jul 2023 13:46:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 629193858409 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1689947160; bh=W5YT3OtxqsGjsdU79azj91hlmfdMIlLXMV0mHls+10o=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=csiNK0ck5DMcBXgLs8IcVGkPaIM92wiRRqYFrM9fKvcu4F9acSuyBEpWjh+0Nzq6H srSzY96SiWnslfD/hp1bemrdqn69BxE/bCF9wpavGWSE0DTjaCEVH4m2oXQKiJGZXO 6pRtfb4ioeWHqWtfgna2pepLd7uCRuzCQT9I1prA= Received: from localhost.localdomain (xry111.site [IPv6:2001:470:683e::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id E603D659A1; Fri, 21 Jul 2023 09:45:59 -0400 (EDT) Message-ID: <8c74d12dd1e152ffc2f06fe9bf95aa67bd1407c5.camel@xry111.site> Subject: Re: [PATCH] Reduce floating-point difficulties in timevar.cc From: Xi Ruoyao To: Matthew Malcomson , Richard Biener Cc: gcc-patches@gcc.gnu.org, richard.sandiford@arm.com Date: Fri, 21 Jul 2023 21:45:58 +0800 In-Reply-To: <62d34c82-b883-8497-1b6b-cc662d26b4c9@arm.com> References: <62d34c82-b883-8497-1b6b-cc662d26b4c9@arm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 MIME-Version: 1.0 X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,LIKELY_SPAM_FROM,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, 2023-07-21 at 14:11 +0100, Matthew Malcomson wrote: > My understanding is that this is not a hardware bug and that it's=20 > specified that rounding does not happen on the multiply "sub-part" in=20 > `FNMSUB`, but rounding happens on the `FMUL` that generates some input > to it. AFAIK the C standard does only say "A floating *expression* may be contracted". I.e: double r =3D a * b + c; may be compiled to use FMA because "a * b + c" is a floating point expression. But double t =3D a * b; double r =3D t + c; is not, because "a * b" and "t + c" are two separate floating point expressions. So a contraction across two functions is not allowed. We now have -ffp- contract=3Don (https://gcc.gnu.org/r14-2023) to only allow C-standard contractions. Perhaps -ffp-contract=3Don (not off) is enough to fix the issue (if you are building GCC 14 snapshot). The default is "fast" (if no -std=3D option is used), which allows some contractions disallowed by the standard. But GCC is in C++ and I'm not sure if the C++ standard has the same definition for allowed contractions as C. > I can look into `-ffp-contract=3Doff` as you both have recommended. > One question -- if we have concerns that the host compiler may not be=20 > able to handle `attribute((noinline))` would we also be concerned that > this flag may not be supported? Only use it in BOOT_CFLAGS, i. e. 'make BOOT_CFLAGS=3D"-O2 -g -ffp- contract=3Don"' (or "off" instead of "on"). In 3-stage bootstrapping it's only applied in stage 2 and 3, during which GCC is compiled by itself. > (Or is the severity of lack of support sufficiently different in the two= =20 > cases that this is fine -- i.e. not compile vs may trigger floating=20 > point rounding inaccuracies?) It's possible that the test itself is flaky. Can you provide some detail about how it fails? --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University