From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lxmtout4.gsi.de (lxmtout4.gsi.de [140.181.3.147]) by sourceware.org (Postfix) with ESMTPS id 6C2433858D35; Mon, 25 May 2020 08:06:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6C2433858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gsi.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=M.Kretz@gsi.de Received: from localhost (localhost [127.0.0.1]) by lxmtout4.gsi.de (Postfix) with ESMTP id C1681207C2E6; Mon, 25 May 2020 10:06:49 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lxmtout4.gsi.de Received: from lxmtout4.gsi.de ([127.0.0.1]) by localhost (lxmtout4.gsi.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cWF2FkObde6f; Mon, 25 May 2020 10:06:49 +0200 (CEST) Received: from srvex3.campus.gsi.de (srvex3.campus.gsi.de [10.10.4.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by lxmtout4.gsi.de (Postfix) with ESMTPS id 5863B207C2E2; Mon, 25 May 2020 10:06:49 +0200 (CEST) Received: from excalibur.localnet (140.181.3.12) by srvex3.campus.gsi.de (10.10.4.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1847.3; Mon, 25 May 2020 10:06:49 +0200 From: Matthias Kretz To: Jonathan Wakely CC: , Subject: Re: [PATCH] Let numeric_limits::is_iec559 reflect -ffast-math Date: Mon, 25 May 2020 10:06:48 +0200 Message-ID: <1703012.vAW0rqQIy0@excalibur> Organization: GSI Helmholtzzentrum =?UTF-8?B?ZsO8cg==?= Schwerionenforschung In-Reply-To: <20200522163942.GO2678@redhat.com> References: <2471679.QqfNXX16uU@excalibur> <4545252.oCjhQSYjh5@excalibur> <20200522163942.GO2678@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Originating-IP: [140.181.3.12] X-ClientProxiedBy: SRVEX2.campus.gsi.de (10.10.4.15) To srvex3.campus.gsi.de (10.10.4.16) X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00, BODY_8BITS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, SPF_PASS, TXREP, T_SPF_HELO_PERMERROR autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2020 08:06:55 -0000 On Freitag, 22. Mai 2020 18:39:42 CEST Jonathan Wakely wrote: > On 22/05/20 09:49 +0200, Matthias Kretz wrote: > >On Donnerstag, 21. Mai 2020 17:46:01 CEST Marc Glisse wrote: > >> On Thu, 21 May 2020, Jonathan Wakely wrote: > >> > On 27/04/20 17:09 +0200, Matthias Kretz wrote: > >> >> From: Matthias Kretz > >> >>=20 > >> >> PR libstdc++/84949 > >> >> * include/std/limits: Let is_iec559 reflect whether > >> >> __GCC_IEC_559 says float and double support IEEE 754-2008. > >> >> * testsuite/18_support/numeric_limits/is_iec559.cc: Test IEC= 559 > >> >> mandated behavior if is_iec559 is true. > >> >> * testsuite/18_support/numeric_limits/infinity.cc: Only test > >> >> inf > >> >> behavior if is_iec559 is true, otherwise there is no guarant= ee > >> >> how arithmetic on inf behaves. > >> >> * testsuite/18_support/numeric_limits/quiet_NaN.cc: ditto for > >> >> NaN. > >> >> * testsuite/18_support/numeric_limits/denorm_min-1.cc: Compi= le > >> >> with -ffast-math. > >> >> * testsuite/18_support/numeric_limits/epsilon-1.cc: ditto. > >> >> * testsuite/18_support/numeric_limits/infinity-1.cc: ditto. > >> >> * testsuite/18_support/numeric_limits/is_iec559-1.cc: ditto. > >> >> * testsuite/18_support/numeric_limits/quiet_NaN-1.cc: ditto. > >> >=20 > >> > I'm inclined to go ahead and commit this (to master only, obviously). > >> > It certainly seems more correct to me, and we'll probably never find > >> > out if it's "safe" to do unless we actually change it and see what > >> > happens. > >> >=20 > >> > Marc, do you have an opinion? > >>=20 > >> I don't have a strong opinion on this. I thought we were refraining fr= om > >> changing numeric_limits based on flags (like -fwrapv for modulo) becau= se > >> that would lead to ODR violations when people link objects compiled wi= th > >> different flags. There is a value in libstdc++.so, which may have been > >> compiled with different flags than the application. > > > >But these ODR violations happen in any case: The floating-point types are > >different types with or without -ffast-math (and related) flags. They > >behave differently. Compiling a function in multiple TUs with different > >flags produces observably different results. Choosing a single one of th= em > >is obviously fragile and broken. That's the spirit of an ODR violation... > > > >It would sometimes be useful to have different types: > >float, float_no_nan, float_no_nan_no_signed_zero, ... >=20 > Sure. There are ODR violations like that, and then there are ones > like: >=20 > template > struct X > { > conditional_t::is_iec559, T, BigNum> val; > }; Nice. ;-) If only the mangling of a struct could include the type of its=20 members (recursively)... But at least val has a different type now. And=20 correctly so. Yes, the ABI breaks possible via this change is real, though= =20 I'd guess there are zero or close-to-zero ABI dependencies on is_iec559 out= in=20 the wild (at this point - because it didn't work anyway). > I'm generally not concerned about ODR violations where one TU behaves > as requested by the flags used to compile that TU and another behaves > as requested by the flats used to compile that second TU. That happens > all the time with -fno-exceptions and -fno-rtti and such like. That > causes ODR violations too, but of the kind where each definition does > what was requested. I am concerned. Showcase: https://godbolt.org/z/KzM3si. If you link those T= Us,=20 you get one of the two behaviors for both TUs. This can result in very hard= to=20 find Heisenbugs. > Constants defined by the library changing value is a bit more > concerning. But I don't know if it's really a problem in this case. template ::is_iec559> struct Float { T val }; =46inally, the standard mechanism that can help resolve those silent ODR=20 violations works. I.e. one can build float_559 and float_non559 types=20 (overloading all operators is still rather tedious) =2D-=20 =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Dr. Matthias Kretz https://mattkretz.github.io GSI Helmholtz Centre for Heavy Ion Research https://gsi.de std::experimental::simd https://github.com/VcDevel/std-simd =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80