[PATCH] D42092: implement C++ dr388 for the Itanium C++ ABI: proper handling of catching exceptions by reference
Richard Smith - zygoloid via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Thu Apr 5 13:07:19 PDT 2018
rsmith abandoned this revision.
rsmith added a comment.
In https://reviews.llvm.org/D42092#1058772, @rjmccall wrote:
> Issue #3 is tricky; it's arguably not okay to force a landing at a landing pad if we're not actually catching anything.
I think the only way this is observable (at least within the bounds of well-defined C++ code) is whether -- and how much -- the stack is unwound before a call to `terminate()` in the case where an exception is not caught.
[except.handle]p9 says: "If no matching handler is found, the function std::terminate() is called; whether or not the stack is unwound before this call to std::terminate() is implementation-defined (18.5.1)."
[except.terminate]p2 says: " In the situation where no matching handler is found, it is implementation-defined whether or not the stack is unwound before std::terminate() is called. In the situation where the search for a handler (18.3) encounters the outermost block of a function with a non-throwing exception specification (18.4), it is implementation-defined whether the stack is unwound, unwound partially, or not unwound at all before std::terminate() is called. In all other situations, the stack shall not be unwound before std::terminate() is called."
So I think you're right; this solution to issue #3 is non-conforming, because it will result in the stack being partially unwound on the path to a call to `std::terminate()` for an unhandled exception. Even if we changed the rule for `terminate` to allow partial unwinding when no handler is found, this patch would still give a QoI regression for that case (because the call to the `terminate_handler` would happen after some unwinding had been performed).
I'm not particularly interested in pushing this patch further if it can't actually make catch-by-reference work properly. Let's drop this for now and encourage interested parties to work on an alternative personality function.
Repository:
rC Clang
https://reviews.llvm.org/D42092
More information about the cfe-commits
mailing list