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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
