Re: [PATCH RFC] c++: use __cxa_call_terminate for MUST_NOT_THROW [PR97720]

[Jeff Law <jeffreyalaw@gmail.com>]

On 5/24/23 12:55, Jason Merrill via Gcc-patches 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.
OK on the middle end bits.  And I'd tend to agree MUST_NOT_THROW is just 
a special case of an exception-specification, so if you can make your 
proposal work it seems like a reasonable approach.

jeff