PING Re: [PATCH RFA (tree-eh)] c++: use __cxa_call_terminate for MUST_NOT_THROW [PR97720]

[Jason Merrill]

On 6/5/23 02:09, Richard Biener wrote:
> On Fri, Jun 2, 2023 at 6:57 PM Jason Merrill via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>>
>> Since Jonathan approved the library change, I'm looking for middle-end
>> approval for the tree-eh change, even without advice on the potential
>> follow-up.
>>
>> On 5/24/23 14:55, Jason Merrill wrote:
>>> Middle-end folks: any thoughts about how best to make the change described in
>>> the last paragraph below?
>>>
>>> Library folks: any thoughts on the changes to __cxa_call_terminate?
>>>
>>> -- 8< --
>>>
>>> [except.handle]/7 says that when we enter std::terminate due to a throw,
>>> that is considered an active handler.  We already implemented that properly
>>> for the case of not finding a handler (__cxa_throw calls __cxa_begin_catch
>>> before std::terminate) and the case of finding a callsite with no landing
>>> pad (the personality function calls __cxa_call_terminate which calls
>>> __cxa_begin_catch), but for the case of a throw in a try/catch in a noexcept
>>> function, we were emitting a cleanup that calls std::terminate directly
>>> without ever calling __cxa_begin_catch to handle the exception.
>>>
>>> A straightforward way to fix this seems to be calling __cxa_call_terminate
>>> instead.  However, that requires exporting it from libstdc++, which we have
>>> not previously done.  Despite the name, it isn't actually part of the ABI
>>> standard.  Nor is __cxa_call_unexpected, as far as I can tell, but that one
>>> is also used by clang.  For this case they use __clang_call_terminate; it
>>> seems reasonable to me for us to stick with __cxa_call_terminate.
>>>
>>> I also change __cxa_call_terminate to take void* for simplicity in the front
>>> end (and consistency with __cxa_call_unexpected) but that isn't necessary if
>>> it's undesirable for some reason.
>>>
>>> This patch does not fix the issue that representing the noexcept as a
>>> cleanup is wrong, and confuses the handler search; since it looks like a
>>> cleanup in the EH tables, the unwinder keeps looking until it finds the
>>> catch in main(), which it should never have gotten to.  Without the
>>> try/catch in main, the unwinder would reach the end of the stack and say no
>>> handler was found.  The noexcept is a handler, and should be treated as one,
>>> as it is when the landing pad is omitted.
>>>
>>> The best fix for that issue seems to me to be to represent an
>>> ERT_MUST_NOT_THROW after an ERT_TRY in an action list as though it were an
>>> ERT_ALLOWED_EXCEPTIONS (since indeed it is an exception-specification).  The
>>> actual code generation shouldn't need to change (apart from the change made
>>> by this patch), only the action table entry.
>>>
>>>        PR c++/97720
>>>
>>> gcc/cp/ChangeLog:
>>>
>>>        * cp-tree.h (enum cp_tree_index): Add CPTI_CALL_TERMINATE_FN.
>>>        (call_terminate_fn): New macro.
>>>        * cp-gimplify.cc (gimplify_must_not_throw_expr): Use it.
>>>        * except.cc (init_exception_processing): Set it.
>>>        (cp_protect_cleanup_actions): Return it.
>>>
>>> gcc/ChangeLog:
>>>
>>>        * tree-eh.cc (lower_resx): Pass the exception pointer to the
>>>        failure_decl.
>>>        * except.h: Tweak comment.
>>>
>>> libstdc++-v3/ChangeLog:
>>>
>>>        * libsupc++/eh_call.cc (__cxa_call_terminate): Take void*.
>>>        * config/abi/pre/gnu.ver: Add it.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>>        * g++.dg/eh/terminate2.C: New test.
>>> ---
>>>    gcc/cp/cp-tree.h                     |  2 ++
>>>    gcc/except.h                         |  2 +-
>>>    gcc/cp/cp-gimplify.cc                |  2 +-
>>>    gcc/cp/except.cc                     |  5 ++++-
>>>    gcc/testsuite/g++.dg/eh/terminate2.C | 30 ++++++++++++++++++++++++++++
>>>    gcc/tree-eh.cc                       | 16 ++++++++++++++-
>>>    libstdc++-v3/libsupc++/eh_call.cc    |  4 +++-
>>>    libstdc++-v3/config/abi/pre/gnu.ver  |  7 +++++++
>>>    8 files changed, 63 insertions(+), 5 deletions(-)
>>>    create mode 100644 gcc/testsuite/g++.dg/eh/terminate2.C
>>>
>>> diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
>>> index a1b882f11fe..a8465a988b5 100644
>>> --- a/gcc/cp/cp-tree.h
>>> +++ b/gcc/cp/cp-tree.h
>>> @@ -217,6 +217,7 @@ enum cp_tree_index
>>>           definitions.  */
>>>        CPTI_ALIGN_TYPE,
>>>        CPTI_TERMINATE_FN,
>>> +    CPTI_CALL_TERMINATE_FN,
>>>        CPTI_CALL_UNEXPECTED_FN,
>>>
>>>        /* These are lazily inited.  */
>>> @@ -358,6 +359,7 @@ extern GTY(()) tree cp_global_trees[CPTI_MAX];
>>>    /* Exception handling function declarations.  */
>>>    #define terminate_fn                        cp_global_trees[CPTI_TERMINATE_FN]
>>>    #define call_unexpected_fn          cp_global_trees[CPTI_CALL_UNEXPECTED_FN]
>>> +#define call_terminate_fn            cp_global_trees[CPTI_CALL_TERMINATE_FN]
>>>    #define get_exception_ptr_fn                cp_global_trees[CPTI_GET_EXCEPTION_PTR_FN]
>>>    #define begin_catch_fn                      cp_global_trees[CPTI_BEGIN_CATCH_FN]
>>>    #define end_catch_fn                        cp_global_trees[CPTI_END_CATCH_FN]
>>> diff --git a/gcc/except.h b/gcc/except.h
>>> index 5ecdbc0d1dc..378a9e4cb77 100644
>>> --- a/gcc/except.h
>>> +++ b/gcc/except.h
>>> @@ -155,7 +155,7 @@ struct GTY(()) eh_region_d
>>>        struct eh_region_u_must_not_throw {
>>>          /* A function decl to be invoked if this region is actually reachable
>>>         from within the function, rather than implementable from the runtime.
>>> -      The normal way for this to happen is for there to be a CLEANUP region
>>> +      The normal way for this to happen is for there to be a TRY region
> 
> I only wondered about this, whether it shouldn't say CLEANUP or TRY instead
> of just TRY?  Do you know of other frontends making use of MUST_NOT_THROW?

If there are only CLEANUPs within the MUST_NOT_THROW, we optimize them 
away and omit the landing pad, so the region is not actually reachable.

Jason