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