From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 71B893858D37; Mon, 22 May 2023 21:34:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 71B893858D37 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1684791260; bh=Cu3U0LKw33mb3aoP53kLAMmotI8wCwAScq3OOWqnYlU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=WBtFDZqq9djSpwX2LbcqQTLyuyjvDsg8IEFFvb8C4N3rNYxzDe/p4ubAcdKdie46+ KNo76RGbyGe1iJPiA72eCqqq9zOXrg5fop6IQ54ssOZWOlpZH+BQmitx6Ex67NzBXH Kz0kNhJFh4/6/u5sVFiI1Yr7+W1SL7Bd1A+c3b8M= From: "jason at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/97720] throw in try in noexcept fn calls terminate without handling the exception Date: Mon, 22 May 2023 21:34:19 +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: 10.2.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jason at gcc dot gnu.org X-Bugzilla-Status: NEW 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: everconfirmed cf_reconfirmed_on short_desc bug_status cc 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=3D97720 Jason Merrill changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Last reconfirmed| |2023-05-22 Summary|Sometimes |throw in try in noexcept fn |std::current_exception does |calls terminate without |not work properly in the |handling the exception |terminate handler | Status|UNCONFIRMED |NEW CC| |jason at gcc dot gnu.org --- Comment #4 from Jason Merrill --- Yes. https://eel.is/c++draft/except#handle-7 : "Also, an implicit handler = is considered active when the function std=E2=80=8B::=E2=80=8Bterminate is ent= ered due to a throw." This is handled properly for the case where there is no possible catch clau= se between the call and the noexcept: in that case the call site has no EH lan= ding pad, so the personality function calls __cxa_call_terminate, which properly handles the exception. In the comment #3 case where there are catch clauses, we represent the noex= cept region around the catch as a cleanup. This also means that the phase 1 sea= rch for a handler looks past it rather than properly recognizing that we found a (terminating) handler. And we call std::terminate directly rather than thr= ough __cxa_call_terminate, so indeed std::current_exception is wrong. I assume the optimization sensitivity the original testcase is seeing is du= e to inlining changing whether a particular call falls into the first or second = case above. It looks like Clang represents the second case roughly as catch (...) { std::terminate(); } It seems to me that it would be superior to represent the second case in the action table as an empty exception specification like C++98 throw(), but in= the generated code hand off to __cxa_call_terminate rather than __cxa_call_unexpected. Representing it that way rather than catch(...) wou= ld work better for PR88218 and PR55918.=