[PATCH] D42092: implement C++ dr388 for the Itanium C++ ABI: proper handling of catching exceptions by reference

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In https://reviews.llvm.org/D42092#1058841, @rsmith wrote:

> 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.


Agreed.


Repository:
  rC Clang

https://reviews.llvm.org/D42092