From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lxmtout1.gsi.de (lxmtout1.gsi.de [140.181.3.111]) by sourceware.org (Postfix) with ESMTPS id 61CA3389ECA6; Sun, 30 Jun 2024 03:03:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 61CA3389ECA6 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gsi.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gsi.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 61CA3389ECA6 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=140.181.3.111 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1719716606; cv=none; b=K03zGnoajKnGjDmfSooUFruNd+R3s3TR7m5MaCOZ6lzUPbvAeqPs8D5plxwCynKIJIgYWpVLiHb9vtlFNi9Y9OgSFJRldA3AHvVmPzGOdKFDWhxnwU73D87nf5UFDwd3mDKjKNXiEjxRmz6NDCGR06j/p5uCPerQR1eli9QCHME= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1719716606; c=relaxed/simple; bh=UcP1FeBjtYyFQG6BlGgq5y46Kj3J1wG9jg9j/iy4gus=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=joPkReQHNGA4s29d/YZ8/gsRaQ7d0OtvfZ3K8UdC9mU+2L1xpuTUxnlBZ10igbGCyq3ULc5L9BFlkS417VUK17V9Y8QP4+ZiKva9PS6qWufux4Jivjo/tXs7e8eF59NLk0Gc1ifAo578kF101OgFmQNkDTbEl7cIormBk1APaew= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from localhost (localhost [127.0.0.1]) by lxmtout1.gsi.de (Postfix) with ESMTP id 78B2D2051042; Sun, 30 Jun 2024 05:03:20 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lxmtout1.gsi.de Received: from lxmtout1.gsi.de ([127.0.0.1]) by localhost (lxmtout1.gsi.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wdcFsSA6jpNY; Sun, 30 Jun 2024 05:03:20 +0200 (CEST) Received: from srvEX6.campus.gsi.de (srvex6.campus.gsi.de [10.10.4.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lxmtout1.gsi.de (Postfix) with ESMTPS id 589572051040; Sun, 30 Jun 2024 05:03:20 +0200 (CEST) Received: from vir-laptop.localnet (140.181.3.12) by srvEX6.campus.gsi.de (10.10.4.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Sun, 30 Jun 2024 05:03:19 +0200 From: Matthias Kretz To: GCC Mailing List , Martin Uecker CC: Andrew Pinski , Subject: Re: IFNDR on UB? [was: Straw poll on shifts with out of range operands] Date: Sun, 30 Jun 2024 05:03:16 +0200 Message-ID: <4752703.ECZNHGQPT7@vir-laptop> Organization: GSI Helmholtz Center for Heavy Ion Research In-Reply-To: <1d1d276da222028af8bd03e575fe0d22752f0494.camel@gwdg.de> References: <4588024.GUh0CODmnK@vir-laptop> <1d1d276da222028af8bd03e575fe0d22752f0494.camel@gwdg.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8289590.zQ0Gbyo6oJ"; micalg=pgp-sha512; protocol="application/pgp-signature" X-Originating-IP: [140.181.3.12] X-ClientProxiedBy: srvex5.Campus.gsi.de (10.10.4.95) To srvEX6.campus.gsi.de (10.10.4.96) X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,BODY_8BITS,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --nextPart8289590.zQ0Gbyo6oJ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; protected-headers="v1" From: Matthias Kretz Cc: Andrew Pinski , libstdc++@gcc.gnu.org Date: Sun, 30 Jun 2024 05:03:16 +0200 Message-ID: <4752703.ECZNHGQPT7@vir-laptop> Organization: GSI Helmholtz Center for Heavy Ion Research In-Reply-To: <1d1d276da222028af8bd03e575fe0d22752f0494.camel@gwdg.de> MIME-Version: 1.0 On Saturday, 29 June 2024 16:20:55 GMT+2 Martin Uecker wrote: > Am Samstag, dem 29.06.2024 um 08:50 -0500 schrieb Matthias Kretz via Gcc: > > I.e. once UB becomes IFNDR, the dreaded time-travel optimizations can't > > happen anymore. Instead precondition checks bubble up because otherwise > > the program is ill-formed. >=20 > It is not clear to mean what you mean by this? It would help if you could point out what is unclear to you. I assume you k= now=20 IFNDR? And I gave an example for the "bubbling up" of precondition checks=20 directly above your quoted paragraph. > Note that in C time-travel optimizations are already not allowed. Then, calling __builtin_unreachable is non-conforming for C? ... at least i= n=20 the English sense of "this code is impossible to reach", which implies that= =20 the condition leading up to it must be 'false', allowing time-travel=20 optimization. Or how would C define 'unreachable'? > But I am not sure how this is relevant here as this affects only > observable behavior and the only case where GCC does not seem to > already conform to this is volatile. Now you lost me. > Of course, C++ may be different but I suspect that some of the > discussion is confusing compiler bugs with time-travel: "some of the discussion" is referring to what? > > Again, I don't believe this would be conforming to the C++ standard. Bu= t I > > believe it's a very interesting mode to add as a compiler flag. > >=20 > > -fharden=3D0 (default) > > -fharden=3D1 (make UB ill-formed or unreachable) > > -fharden=3D2 (make UB ill-formed or trap) > >=20 > > If there's interest I'd be willing to look into a patch to libstdc++, > > building upon the above sketch as a starting point. Ultimately, if this > > becomes a viable build mode, I'd like to have a replacement for the > > [[gnu::error("")]] hack with a dedicated builtin. >=20 > -fharden should never turn this into unreachable. Well, if the default is 'unreachable' and the next step is 'ill-formed or=20 unreachable' it's a step up. But I'm all for a better name. > IMHO the FEs should insert the conditional traps when requested to > and the middle end could then treat it as UB and more freely > decide what to do. Right I was thinking of turning my library-solution hack into a builtin (if= it=20 shows potential). The behavior of which then depends on a compiler flag. Th= en=20 both library and language UB could invoke that builtin. E.g. 'operator+(int= ,=20 int)' would add '__check_precondition(not __builtin_add_overflow_p(a, b, a)= );' With my proposed '-fharden=3D1 -O2' you'd then get a compilation error on=20 '0x7fff'ffff + 1', but no code size increase for all other additions. With= =20 '-fharden=3D2 -O2' the 'lea' would turn into an actual 'add' instruction wi= th=20 subsequent 'jo' to 'ud2' (on x86). > Also IMHO this should be split up from > UBsan which has specific semantics and upstream dependencies > which are are not always ideal. (But UBSan could share the > same infrastructure) I'm not sure what you're thinking of here. UBsan detects UB at runtime wher= eas=20 my '-fharden=3D1' proposal is about flagging UB as ill-formed on compile-ti= me.=20 So UBsan is a more verbose '-fharden=3D2' then? =2D Matthias =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 Center for Heavy Ion Research https://gsi.de 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 --nextPart8289590.zQ0Gbyo6oJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEroo/QdgfHhrjcEOni/oLaRkZhWgFAmaAyvQACgkQi/oLaRkZ hWgMcgf/Ybnt72gGXkeW3wukWWqAa6uF9fDCiOiTBhvPsb93hsj2PXBh1mXNPtNO lUr2HdfJJlwnNQX2gNiPvd4qvdAW1CA18y/StxIjKyuuvrFOtjkUAblABKkCH23E BWNeY2K9vylSkMmLXHMA76+fQ8AqnNiO3LfDunhfw2jrPsu7Wm/VMYD6OvVoUmV0 Vc/P34zKLNLYnWb1AjZhHo9PAA2Z0yjJMzGg4WzE99361vraFsmG/LDRYALNcGWt UL+j+HajZx2rVpiTWp4Tkg/RBcyOUw8YtBkELkM8cSFPh9WMGM8SUSmPxib4RI32 QHaInuMU5ufMzbXp+zKaU6hiQD1vkA== =vdKk -----END PGP SIGNATURE----- --nextPart8289590.zQ0Gbyo6oJ--