From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B0FFB3857826; Tue, 22 Feb 2022 14:47:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B0FFB3857826 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/104642] New: Add __builtin_trap() for missing return at -O0 Date: Tue, 22 Feb 2022 14:47:43 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: redi 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2022 14:47:43 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104642 Bug ID: 104642 Summary: Add __builtin_trap() for missing return at -O0 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- Again and again and again users are surprised (and often angry) about the effects of a missing return in C++. It's undefined behaviour but that doesn= 't stop bug reports like PR 104635 and questions like https://gcc.gnu.org/pipermail/gcc/2022-January/238200.html Users expect the undefined behaviour for a missing return to be "semi-defin= ed". We should just make it trap at -O0, then at least we can tell them that for unoptimized code, the result is guaranteed to crash. With optimisation, it's still undefined and can invalidate all their assumptions. As I said in https://gcc.gnu.org/pipermail/gcc/2022-January/238204.html What if we inserted the trap for -O0? 1. Not everybody uses ubsan even when they should use it. 2. The code can use unreachable annotations if it really needs to leave some paths unhandled, but really can't live with the branch and trap instructions. (The C++ standard is getting std::unreachable and std::assume to do that in a portable way, so there is less excuse for not doing it).=