From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D06CA3857014; Fri, 16 Sep 2022 16:48:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D06CA3857014 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1663346934; bh=d56O9SBXch3YNFnClp+AUHthouXxk3ghzMS14Icbf5M=; h=From:To:Subject:Date:In-Reply-To:References:From; b=kU0rsz9J0HV2t7UbzwWwByNDnre7numhVeljw8kujHrAHQHJAz8OCPVJfvu3VFmsW XdnHWak2FhV5WAmecwwFTDtBnMrCz1qAlR9dARSQ8SzaiYyzYGN9C+6NCbMeZQkihi Rtpc0QnbV206TMDGYosz1HCiyk6FdGOfCs9rKeUY= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/106654] [C++23] P1774 - Portable assumptions Date: Fri, 16 Sep 2022 16:48:54 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106654 --- Comment #6 from Jakub Jelinek --- (In reply to Pilar Latiesa from comment #5) > (In reply to Jakub Jelinek from comment #4) > > Note, I think for [[assume(i =3D=3D j)]]; we can just emit if (i =3D=3D= j) ; else > > __builtin_unreachable (); >=20 > It would be great if the attribute were somewhat cleverer than that. You've cut the second part of sentence, the above was meant for !TREE_SIDE_EFFECTS conditions and the rest is about how to treat conditions which do have side-effects (and that we should probably use more than just TREE_SIDE_EFFECTS test, but watch for any expressions that could possibly r= aise exceptions, or fault or trap). For the simple cases, we already can handle it without actually invoking anything at runtime and it will be cheaper compile time to handle it as bef= ore, for the more complex expressions sure, we need to come up with something new and make ranger and perhaps other optimizations be able to cope with it. BTW, the C++ paper mentions clang __builtin_assume, but that one seems to do roughly what our if (cond) ; else __builtin_unreachable (); does (which the= y I think support too) only if the expression doesn't contain side-effects. If= it does, it warns and doesn't do anything at all.=