[ItaniumCXXABI] Add -fassume-nothrow-exception-dtor to assume that all exception objects' destructors are non-throwing

[MaskRay]

Summary

Link: https://lists.llvm.org/pipermail/cfe-dev/2021-August/068740.html ("[Exception Handling] Could we mark __cxa_end_catch as nounwind conditionally?"
Link: https://github.com/llvm/llvm-project/issues/57375

A catch handler calls __cxa_begin_catch and __cxa_end_catch. For a catch-all
clause or a catch clause matching a record type, we:

• assume that the exception object may have a throwing destructor
• emit invoke void @__cxa_end_catch (as the call is not marked as the nounwind attribute).
• emit a landing pad to destroy local variables and call _Unwind_Resume

struct A { ~A(); };
struct B { int x; };
void opaque();
void foo() {
  A a;
  try { opaque(); } catch (...) { } // the exception object has an unknown type and may throw
  try { opaque(); } catch (B b) { } // B::~B is nothrow, but we do not utilize this
}

Per C++ [dcl.fct.def.coroutine], a coroutine's function body implies a catch (...).
Our code generation pessimizes even simple code, like:

UserFacing foo() {
  A a;
  opaque();
  co_return;
  // For `invoke void @__cxa_end_catch()`, the landing pad destroys the
  // promise_type and deletes the coro frame.
}

Throwing destructors are typically discouraged. In many environments, the
destructors of exception objects are guaranteed to never throw, making our
conservative code generation approach seem wasteful.

Furthermore, throwing destructors tend not to work well in practice:

• GCC does not emit call site records for the region containing __cxa_end_catch. This has been a long time, since 2000.
• If a catch-all clause catches an exception object that throws, both GCC and Clang using libstdc++ leak the allocated exception object.

To avoid code generation pessimization, add an opt-in driver option
-fassume-nothrow-exception-dtor to assume that __cxa_end_catch calls have the
nounwind attribute. This implies that thrown exception objects' destructors
will never throw.

To detect misuses, diagnose throw expressions with a potentially-throwing
destructor. Technically, it is possible that a potentially-throwing destructor
never throws when called transitively by __cxa_end_catch, but these cases seem
rare enough to justify a relaxed mode.

[ChuanqiXu]

Thanks for looking into this!
I am not familiar with exception handling. But from the comments, I worried that if it is a problem if there are exceptions whose destructor could throw (although it is not usual nor good).

[MaskRay]

In D108905#2971761, @ChuanqiXu wrote:

Thanks for looking into this!
I am not familiar with exception handling. But from the comments, I worried that if it is a problem if there are exceptions whose destructor could throw (although it is not usual nor good).

GCC does not emit call site records for the __cxa_end_catch region, so I believe it makes the same assumption.
Setting nounwind should be safe...

[ChuanqiXu]

In D108905#2971773, @MaskRay wrote:

In D108905#2971761, @ChuanqiXu wrote:

Thanks for looking into this!
I am not familiar with exception handling. But from the comments, I worried that if it is a problem if there are exceptions whose destructor could throw (although it is not usual nor good).

GCC does not emit call site records for the __cxa_end_catch region, so I believe it makes the same assumption.
Setting nounwind should be safe...

Make sense to me. Thanks for looking into this!

[MaskRay]

I confirm that GCC has had this behavior since 2000 (3.0).

[ChuanqiXu]

clang/lib/CodeGen/ItaniumCXXABI.cpp

4495–4508

If __cxa_end_catch is nounwind always now, do we need to refactor this one? Like:

struct CallEndCatch final : EHScopeStack::Cleanup {
    CallEndCatch() {}

    void Emit(CodeGenFunction &CGF, Flags flags) override {
      CGF.EmitNounwindRuntimeCall(getEndCatchFn(CGF.CGM));
    }
  };

[rjmccall]

Yes, this seems extremely reasonable; it was really just an oversight. Patch is semantically fine, although what we do in several other places is use EmitNounwindRuntimeCall to emit the call, and I think I'd like to do that here: I'd like to eventually eliminate EmitRuntimeCall entirely in favor of expecting the client to be explicit about whether the runtime call is allowed to throw.

Although... actually, it occurs to me that there is a reason __cxa_end_catch *could* throw in the abstract, which is that the exception destructor could throw. My first instinct is that this should call std::terminate, and if so, the runtime should handle that; but I don't see anything in either the standard or the Itanium ABI that directly supports that.

I'm not really sure what the standard expects to happen if an exception destructor throws. The standard tells us when the destruction happens — the latest point it can — but that clause doesn't mention exceptions from the destructor. If there's a specific clause on this, I can't find it. [except.throw]p7 says that "if the exception handling mechanism handling an uncaught exception directly invokes a function that exits via an exception, the function std::terminate is called", which is meant to cover exceptions thrown when initializing a catch variable. Once the catch clause is entered, though, the exception is considered caught unless it's rethrown, so this clause doesn't apply when destroying the exception at the end of the clause. If the catch variable's destructor throws, that seems to be specified to unwind normally (including destroying the exception, and if the destructor throws at that point then std::terminate gets called, as normal for exceptions during unwinding).

Neither libc++abi nor libsupc++ seem to handle the possibility of the exception destructor throwing when destroying exceptions; they'll both happily leak the exception object if it does. That's reasonable if the assumption is that the destructor function passed to __cxa_throw never throws, which is itself reasonable for the frontend to ensure if indeed the language rule is that std::terminate is supposed to be called. Clang does not actually do that, though: it just passes the address of the destructor, which would only be legal if the destructor was noexcept (which is, of course, now the default).

So tentatively I think this is okay, but it looks like it's uncovered some bugs in our handling of throwing destructors for exceptions.

[wenlei]

+@modimo

[MaskRay]

set nounwind in call sites

[• Quuxplusone]

Peanut gallery says: Does this godbolt demonstrate the situation where "destroying an exception can throw an exception"?
https://godbolt.org/z/Ghjz53rrj
You're not proposing to change the behavior of this program, are you?
(If you're proposing to change it: I don't think you should. If you're not proposing to change it, but rather the issue is something subtler: never mind me, then.)

[rjmccall]

Well, I'm saying two things. First, it is not clear to me what the expected behavior of that code is under the standard. The fact that it appears to work in one particular implementation is not in any way conclusive; we have to look at the specification. Second, I think it only appears to work: looking at the runtime code in both libc++abi and libsupc++, it leaks the memory of the exception object, which it's clearly not allowed to do. You should be able to fairly easy prove that by looking at heap usage if you do it in a loop.

[• Quuxplusone]

Well, I'm saying two things. First, it is not clear to me what the expected behavior of that code is under the standard. The fact that it appears to work in one particular implementation is not in any way conclusive; we have to look at the specification.

Aha, I had thought it worked on "both Clang and GCC," but now I see that Godbolt uses libsupc++ for both Clang and GCC (and that's where the issue is). Switching to a branch that uses libc++abi, I see that libc++abi just calls std::terminate in this situation: https://godbolt.org/z/4s8aMvr3K

Second, I think it only appears to work: looking at the runtime code in both libc++abi and libsupc++, it leaks the memory of the exception object, which it's clearly not allowed to do. You should be able to fairly easy prove that by looking at heap usage if you do it in a loop.

Yep, memory leak confirmed. (Via the same Godbolt: https://godbolt.org/z/4s8aMvr3K ) So okay, never mind me.

[modimo]

In D108905#2971861, @rjmccall wrote:

I'm not really sure what the standard expects to happen if an exception destructor throws. The standard tells us when the destruction happens — the latest point it can — but that clause doesn't mention exceptions from the destructor. If there's a specific clause on this, I can't find it. [except.throw]p7 says that "if the exception handling mechanism handling an uncaught exception directly invokes a function that exits via an exception, the function std::terminate is called", which is meant to cover exceptions thrown when initializing a catch variable. Once the catch clause is entered, though, the exception is considered caught unless it's rethrown, so this clause doesn't apply when destroying the exception at the end of the clause.

Scanning through the standard this to me also looks like an overlooked corner case in the standard (TBF this is very corner case).

If the catch variable's destructor throws, that seems to be specified to unwind normally (including destroying the exception, and if the destructor throws at that point then std::terminate gets called, as normal for exceptions during unwinding).

In this case, the destructor is throwing during normal scope exit so I don't think terminate behavior from [except.throw]p7 is enforced since we're not currently handling an uncaught exception. The handler is already active since we're past the initialization of the catch. Given that, I think this is akin to the example in [except.ctor]p2 and if the destructor is noexcept(false) should trigger a proper unwind like how an exception in the destructor of a simple automatic variable inside the handler scope would also do.

[rjmccall]

In D108905#2973066, @modimo wrote:

In D108905#2971861, @rjmccall wrote:

I'm not really sure what the standard expects to happen if an exception destructor throws. The standard tells us when the destruction happens — the latest point it can — but that clause doesn't mention exceptions from the destructor. If there's a specific clause on this, I can't find it. [except.throw]p7 says that "if the exception handling mechanism handling an uncaught exception directly invokes a function that exits via an exception, the function std::terminate is called", which is meant to cover exceptions thrown when initializing a catch variable. Once the catch clause is entered, though, the exception is considered caught unless it's rethrown, so this clause doesn't apply when destroying the exception at the end of the clause.

Scanning through the standard this to me also looks like an overlooked corner case in the standard (TBF this is very corner case).

If the catch variable's destructor throws, that seems to be specified to unwind normally (including destroying the exception, and if the destructor throws at that point then std::terminate gets called, as normal for exceptions during unwinding).

In this case, the destructor is throwing during normal scope exit so I don't think terminate behavior from [except.throw]p7 is enforced since we're not currently handling an uncaught exception. The handler is already active since we're past the initialization of the catch. Given that, I think this is akin to the example in [except.ctor]p2 and if the destructor is noexcept(false) should trigger a proper unwind like how an exception in the destructor of a simple automatic variable inside the handler scope would also do.

Yeah, I think this is the most natural interpretation of the current standard. But that would be a very unfortunate rule, because people who write catch (...) {} do reasonably expect that that code will never throw. In fact, it would be quite difficult — perhaps impossible — to write code that actually swallowed all exceptions: even try { try { foo() } catch(...) {} } catch (...) {} wouldn't work, because you could throw an exception whose destructor throws an exception whose destructor throws an exception ad infinitum.

[modimo]

In D108905#2973099, @rjmccall wrote:

Yeah, I think this is the most natural interpretation of the current standard. But that would be a very unfortunate rule, because people who write catch (...) {} do reasonably expect that that code will never throw. In fact, it would be quite difficult — perhaps impossible — to write code that actually swallowed all exceptions: even try { try { foo() } catch(...) {} } catch (...) {} wouldn't work, because you could throw an exception whose destructor throws an exception whose destructor throws an exception ad infinitum.

Yeah it's not great and also something that practically will never happen. I think terminate guards are the only thing that really swallows all exceptions except here you can't guard the catch variable destructor unless you want to change up and depend on library implementation. My immediate thought is something like catch(...) noexcept {} to express this but it's a solution to a problem that really shouldn't exist.

[rjmccall]

In D108905#2973172, @modimo wrote:

In D108905#2973099, @rjmccall wrote:

Yeah, I think this is the most natural interpretation of the current standard. But that would be a very unfortunate rule, because people who write catch (...) {} do reasonably expect that that code will never throw. In fact, it would be quite difficult — perhaps impossible — to write code that actually swallowed all exceptions: even try { try { foo() } catch(...) {} } catch (...) {} wouldn't work, because you could throw an exception whose destructor throws an exception whose destructor throws an exception ad infinitum.

Yeah it's not great and also something that practically will never happen. I think terminate guards are the only thing that really swallows all exceptions except here you can't guard the catch variable destructor unless you want to change up and depend on library implementation. My immediate thought is something like catch(...) noexcept {} to express this but it's a solution to a problem that really shouldn't exist.

Well, I think catch (...) { std::terminate(); } should work to express that outer catch, if only because the end of the catch is never reached. But yeah, I agree that this is clearly a problem that shouldn't exist.

We might be able to require exception types to have noexcept destructors. Formally, it would have source compatibility / language-version incompatibility implications, but in practice I doubt it would cause many problems, especially if it was just a "if this actually throws it'll have UB" warning in pre-C++23 language modes for throwing types with explicitly noexcept destructors.

[rsmith]

I've forwarded the question here onto CWG, with Arthur's example and the suggestion that maybe we shouldn't allow throwing an exception with a non-noexcept destructor.

[rjmccall]

Thanks, Richard. Fangrui, I think we can't do anything on this patch without a CWG decision about the right semantics, so this will have to sit.

[rsmith]

No decision as yet, but so far it looks very likely that we'll settle on the rule that exceptions cannot have potentially-throwing destructors, and that we should reject throws of such types. I don't think that should be applied retroactively to C++98, though, because destructors were not implicitly non-throwing back then.

[rjmccall]

In D108905#2975712, @rsmith wrote:

No decision as yet, but so far it looks very likely that we'll settle on the rule that exceptions cannot have potentially-throwing destructors, and that we should reject throws of such types. I don't think that should be applied retroactively to C++98, though, because destructors were not implicitly non-throwing back then.

Is the committee comfortable with implementations causing potentially-throwing exception destructors to trigger std::terminate? I understand that this is a weird question because it implies the use of / interoperation with an old language standard, but we do need to know how to compile in C++98 mode, and we may need to demote this to a warning pre-C++23. If it's not an error in old modes, but the committee doesn't approve of calling std::terminate if it happens, then we still need to compile catch (...) as throwing in case we're interoperating.

[ChuanqiXu]

In D108905#2975806, @rjmccall wrote:

In D108905#2975712, @rsmith wrote:

No decision as yet, but so far it looks very likely that we'll settle on the rule that exceptions cannot have potentially-throwing destructors, and that we should reject throws of such types. I don't think that should be applied retroactively to C++98, though, because destructors were not implicitly non-throwing back then.

Is the committee comfortable with implementations causing potentially-throwing exception destructors to trigger std::terminate? I understand that this is a weird question because it implies the use of / interoperation with an old language standard, but we do need to know how to compile in C++98 mode, and we may need to demote this to a warning pre-C++23. If it's not an error in old modes, but the committee doesn't approve of calling std::terminate if it happens, then we still need to compile catch (...) as throwing in case we're interoperating.

@rjmccall @rsmith Do you think it makes sense to make __cxa_end_catch nounwind conditionally? I mean, in higher standard than C++98, we could make __cxa_end_catch nounwind.

[smeenai]

In D108905#2975712, @rsmith wrote:

No decision as yet, but so far it looks very likely that we'll settle on the rule that exceptions cannot have potentially-throwing destructors, and that we should reject throws of such types. I don't think that should be applied retroactively to C++98, though, because destructors were not implicitly non-throwing back then.

Were there any updates here? This seems like a useful change for us, and I was wondering if it could be unblocked now.

[ChuanqiXu]

In D108905#4654393, @smeenai wrote:

In D108905#2975712, @rsmith wrote:

No decision as yet, but so far it looks very likely that we'll settle on the rule that exceptions cannot have potentially-throwing destructors, and that we should reject throws of such types. I don't think that should be applied retroactively to C++98, though, because destructors were not implicitly non-throwing back then.

Were there any updates here? This seems like a useful change for us, and I was wondering if it could be unblocked now.

What @rsmith talked about is in the standard-wise. I mean, if you feel this is useful, it is possible to add an compiler option to enable this. I've filed an issue to track this: https://github.com/llvm/llvm-project/issues/57375. My plan was to make this happen this year.

[smeenai]

In D108905#4654403, @ChuanqiXu wrote:

In D108905#4654393, @smeenai wrote:

In D108905#2975712, @rsmith wrote:

No decision as yet, but so far it looks very likely that we'll settle on the rule that exceptions cannot have potentially-throwing destructors, and that we should reject throws of such types. I don't think that should be applied retroactively to C++98, though, because destructors were not implicitly non-throwing back then.

Were there any updates here? This seems like a useful change for us, and I was wondering if it could be unblocked now.

What @rsmith talked about is in the standard-wise. I mean, if you feel this is useful, it is possible to add an compiler option to enable this. I've filed an issue to track this: https://github.com/llvm/llvm-project/issues/57375. My plan was to make this happen this year.

Yup, an option to enable this would be great for us.

[MaskRay]

In D108905#4654410, @smeenai wrote:

In D108905#4654403, @ChuanqiXu wrote:

In D108905#4654393, @smeenai wrote:

In D108905#2975712, @rsmith wrote:

No decision as yet, but so far it looks very likely that we'll settle on the rule that exceptions cannot have potentially-throwing destructors, and that we should reject throws of such types. I don't think that should be applied retroactively to C++98, though, because destructors were not implicitly non-throwing back then.

Were there any updates here? This seems like a useful change for us, and I was wondering if it could be unblocked now.

What @rsmith talked about is in the standard-wise. I mean, if you feel this is useful, it is possible to add an compiler option to enable this. I've filed an issue to track this: https://github.com/llvm/llvm-project/issues/57375. My plan was to make this happen this year.

Yup, an option to enable this would be great for us.

I am happy to revive the patch with an option? Any suggestion to the name? CC1 or Driver?

[ChuanqiXu]

In D108905#4654411, @MaskRay wrote:

In D108905#4654410, @smeenai wrote:

In D108905#4654403, @ChuanqiXu wrote:

In D108905#4654393, @smeenai wrote:

In D108905#2975712, @rsmith wrote:

No decision as yet, but so far it looks very likely that we'll settle on the rule that exceptions cannot have potentially-throwing destructors, and that we should reject throws of such types. I don't think that should be applied retroactively to C++98, though, because destructors were not implicitly non-throwing back then.

Were there any updates here? This seems like a useful change for us, and I was wondering if it could be unblocked now.

What @rsmith talked about is in the standard-wise. I mean, if you feel this is useful, it is possible to add an compiler option to enable this. I've filed an issue to track this: https://github.com/llvm/llvm-project/issues/57375. My plan was to make this happen this year.

Yup, an option to enable this would be great for us.

I am happy to revive the patch with an option? Any suggestion to the name? CC1 or Driver?

In our downstream, we use the name -fdisable-exception-with-may-throw-dtor as a Driver option.

[smeenai]

I'd vote for something like -fassume-nothrow-exception-dtor or -fenforce-nothrow-exception-dtor depending on if the patch will also implement the enforcement mentioned in https://github.com/llvm/llvm-project/issues/57375#issuecomment-1230590204, but we can bikeshed that on the patch :)

[MaskRay]

Switch to opt-in

Add -fassume-nothrow-exception-dtor

[smeenai]

This looks great to me, thanks. @rjmccall should sign off on it though.

[ChuanqiXu]

This comment was removed by ChuanqiXu.

[ChuanqiXu]

LGTM since this is exactly what we do in the downstream. The effects of the change in our workloads is 4% size reduction in a coroutine intensive project. (But it requires the coroutine's final suspend can't except via symetric transfer. I was meant to send a paper to WG21 to discuss this). After all, this should be a win for most projects.

We need to mention this in the docs and the ReleaseNotes since we add a new flag.

To make this self contained, we need to add a check in the frontend and emit errors if the compiler find the throwing exception's destructor may throw. This is not required in the current patch but it may be good to add a FIXME or TODO somewhere.

(BTW, the Phab itself is extremly slow now. So if we want more discuss on this, let's move this to Github?)

[MaskRay]

In D108905#4654561, @smeenai wrote:

This looks great to me, thanks. @rjmccall should sign off on it though.

@rjmccall Are you happy with this opt-in option?

In D108905#4654626, @ChuanqiXu wrote:

LGTM since this is exactly what we do in the downstream. The effects of the change in our workloads is 4% size reduction in a coroutine intensive project. (But it requires the coroutine's final suspend can't except via symetric transfer. I was meant to send a paper to WG21 to discuss this). After all, this should be a win for most projects.

We need to mention this in the docs and the ReleaseNotes since we add a new flag.

To make this self contained, we need to add a check in the frontend and emit errors if the compiler find the throwing exception's destructor may throw. This is not required in the current patch but it may be good to add a FIXME or TODO somewhere.

(BTW, the Phab itself is extremly slow now. So if we want more discuss on this, let's move this to Github?)

The slowness was due to a malicious/aggressive distributed crawler. I have fixed it and updated php-fpm config:) https://discourse.llvm.org/t/phabricator-is-very-slow/73132/14

[MaskRay]

I'll land this patch next week if there is no objection. This seems very useful to a few parties and the current behavior is opt-in.

[ChuanqiXu]

We need to mention this in the docs and the ReleaseNotes since we add a new flag.

To make this self contained, we need to add a check in the frontend and emit errors if the compiler find the throwing exception's destructor may throw. This is not required in the current patch but it may be good to add a FIXME or TODO somewhere.

There are 2 comments not addressed yet : )

[MaskRay]

clang/lib/CodeGen/ItaniumCXXABI.cpp

4495–4508

Since __cxa_end_catch is no longer nounwind in the latest revision, we cannot simplify the code...

[ChuanqiXu]

Oh, I am not saying the legacy and old comment. I mean you need to touch ReleaseNotes.rst and UserManual.rst since we add a new flag. Also we need either add a TODO/FIXME saying we need to emit an error in Sema if we find the the dtor of the exception we're throwing may throw or implement the semantics actually.

[MaskRay]

Update clang/docs/UsersManual.rst and clang/docs/ReleaseNotes.rst

[ChuanqiXu]

clang/docs/UsersManual.rst

2145–2147

I think it is better to treat the program as invalid if the compiler find the exception object's destructor is `noexcept(false)`. The earlier error message is better than debugging and understanding what happened actually.

[MaskRay]

In D108905#4655694, @ChuanqiXu wrote:

Oh, I am not saying the legacy and old comment. I mean you need to touch ReleaseNotes.rst and UserManual.rst since we add a new flag. Also we need either add a TODO/FIXME saying we need to emit an error in Sema if we find the the dtor of the exception we're throwing may throw or implement the semantics actually.

Thanks for the reminder about ReleaseNotes.rst and UsersManual.rst!

I think many changes don't update UsersManual.rst but this option is probably quite useful and therefore deserves an entry. Added.
The primary change is to clang/lib/CodeGen/ItaniumCXXABI.cpp, which does not report warnings.
If we want to implement a warning, we should probably do it in clang/lib/Sema/SemaDeclCXX.cpp Sema::BuildExceptionDeclaration, which is not touched in this file, so a TODO seems not appropriate...

Is the warning to warn about noexcept(false) destructor in an exception-declaration? When?
If at catch handlers, unfortunately we are cannot determine the exception object for a catch (...) { ... } (used by coroutines).
Technically, even if a destructor is noexcept(false), the destructor may not throw when __cxa_end_catch destroys the object.

So we probably should warn about throw expressions, which can be done in Sema::CheckCXXThrowOperand and I will investigate it.
However, this warning appears orthogonal to -fassume-nothrow-exception-dtor.
We can argue that even without -fassume-nothrow-exception-dtor, an thrown object with a noexcept(false) destructor is probably not a good idea.
However, I am on the fence whether the warning should be enabled-by-default.

[ChuanqiXu]

In D108905#4655907, @MaskRay wrote:

In D108905#4655694, @ChuanqiXu wrote:

Oh, I am not saying the legacy and old comment. I mean you need to touch ReleaseNotes.rst and UserManual.rst since we add a new flag. Also we need either add a TODO/FIXME saying we need to emit an error in Sema if we find the the dtor of the exception we're throwing may throw or implement the semantics actually.

Thanks for the reminder about ReleaseNotes.rst and UsersManual.rst!

I think many changes don't update UsersManual.rst but this option is probably quite useful and therefore deserves an entry. Added.
The primary change is to clang/lib/CodeGen/ItaniumCXXABI.cpp, which does not report warnings.
If we want to implement a warning, we should probably do it in clang/lib/Sema/SemaDeclCXX.cpp Sema::BuildExceptionDeclaration, which is not touched in this file, so a TODO seems not appropriate...

Is the warning to warn about noexcept(false) destructor in an exception-declaration? When?
If at catch handlers, unfortunately we are cannot determine the exception object for a catch (...) { ... } (used by coroutines).
Technically, even if a destructor is noexcept(false), the destructor may not throw when __cxa_end_catch destroys the object.

So we probably should warn about throw expressions, which can be done in Sema::CheckCXXThrowOperand and I will investigate it.
However, this warning appears orthogonal to -fassume-nothrow-exception-dtor.
We can argue that even without -fassume-nothrow-exception-dtor, an thrown object with a noexcept(false) destructor is probably not a good idea.
However, I am on the fence whether the warning should be enabled-by-default.

The idea of diagnosing such cases is originally raised by @rjmccall in https://github.com/llvm/llvm-project/issues/57375#issuecomment-1230590204. And in fact, John is suggesting an error instead of a warning. To be honest, in our downstream implementation, we didn't implement that semantical check neither.

For the implementation, I think Sema::CheckCXXThrowOperand may be a good place and we can left a TODO there.

Technically, we're using a dialect after we enable -fassume-nothrow-exception-dtor. In our dialect, we don't want to see an exception to throw exceptions. This is a rule for our dialect. And generally we have 2 strategies for implementing such language rules :

• Detect it and emit errors after we found users violating the rules.
• Don't detect it and claims it is the fault of the users.

No matter what the strategy we choose, it is not orthogonal to -fassume-nothrow-exception-dtor for sure. It is highly related. Then, I think the first strategy is always a better choice. Generally we only choose 2 when we can't diagnose such cases.

[MaskRay]

Add a diagnostic

[ChuanqiXu]

LGTM. Thanks.

clang/lib/Sema/SemaExprCXX.cpp

1110

It looks like err_throw_object_throwing_dtor doesn't require any parameters?

[MaskRay]

remove unused err_ arguments.
fix and test throw new B

clang/docs/ReleaseNotes.rst

* ``-fverify-intermediate-code`` and its complement ``-fno-verify-intermediate-code``.
   compiler bugs at the cost of extra compile time.
   Since enabling the verifier adds a non-trivial cost of a few percent impact on
   build times, it's disabled by default, unless your LLVM distribution itself is
   compiled with runtime checks enabled.
 * ``-fkeep-system-includes`` modifies the behavior of the ``-E`` option,
   preserving ``#include`` directives for "system" headers instead of copying
   the preprocessed text to the output. This can greatly reduce the size of the
   preprocessed output, which can be helpful when trying to reduce a test case.
+* ``-fassume-nothrow-exception-dtor`` is added to assume that the destructor of
+  an thrown exception object will not throw. The generated code for catch
+  handlers will be smaller. A throw expression of a type with a
+  potentially-throwing destructor will lead to an error.
 
 Deprecated Compiler Flags
 -------------------------
 
 Modified Compiler Flags
 -----------------------
 
 * ``-Woverriding-t-option`` is renamed to ``-Woverriding-option``.

clang/docs/UsersManual.rst

 .. option:: -fno-assume-sane-operator-new
 
    Don't assume that the C++'s new operator is sane.
 
    This option tells the compiler to do not assume that C++'s global
    new operator will always return a pointer that does not alias any
    other pointer when the function returns.
 
+.. option:: -fassume-nothrow-exception-dtor
+
+   Assume that an exception object' destructor will not throw, and generate
+   less code for catch handlers. A throw expression of a type with a
+   potentially-throwing destructor will lead to an error.
+
+   By default, Clang assumes that the exception object may have a throwing
+   destructor. For the Itanium C++ ABI, Clang generates a landing pad to
+   destroy local variables and call ``_Unwind_Resume`` for the code
+   ``catch (...) { ... }``. This option tells Clang that an exception object's
+   destructor will not throw and code simplification is possible.
+
 .. option:: -ftrap-function=[name]
 
    Instruct code generator to emit a function call to the specified
    function name for ``__builtin_trap()``.
 
    LLVM code generator translates ``__builtin_trap()`` to a trap
    instruction if it is supported by the target ISA. Otherwise, the
    builtin is translated into a call to ``abort``. If this option is

clang/include/clang/Basic/DiagnosticSemaKinds.td

 def note_throw_underaligned_obj : Note<
   "required alignment of type %0 (%1 bytes) is larger than the supported "
   "alignment of C++ exception objects on this target (%2 bytes)">;
 def err_return_in_constructor_handler : Error<
   "return in the catch of a function try block of a constructor is illegal">;
 def warn_cdtor_function_try_handler_mem_expr : Warning<
   "cannot refer to a non-static member from the handler of a "
   "%select{constructor|destructor}0 function try block">, InGroup<Exceptions>;
+def err_throw_object_throwing_dtor : Error<
+  "cannot throw object of type %0 with a potentially-throwing destructor">;
 
 let CategoryName = "Lambda Issue" in {
   def err_capture_more_than_once : Error<
     "%0 can appear only once in a capture list">;
   def err_reference_capture_with_reference_default : Error<
     "'&' cannot precede a capture when the capture default is '&'">;
   def err_copy_capture_with_copy_default : Error<
     "'&' must precede a capture when the capture default is '='">;

clang/include/clang/Basic/LangOptions.def

 LANGOPT(Exceptions        , 1, 0, "exception handling")
 LANGOPT(ObjCExceptions    , 1, 0, "Objective-C exceptions")
 LANGOPT(CXXExceptions     , 1, 0, "C++ exceptions")
 LANGOPT(EHAsynch          , 1, 0, "C/C++ EH Asynch exceptions")
 ENUM_LANGOPT(ExceptionHandling, ExceptionHandlingKind, 3,
              ExceptionHandlingKind::None, "exception handling")
 LANGOPT(IgnoreExceptions  , 1, 0, "ignore exceptions")
 LANGOPT(ExternCNoUnwind   , 1, 0, "Assume extern C functions don't unwind")
+LANGOPT(AssumeNothrowExceptionDtor , 1, 0, "Assume exception object's destructor is nothrow")
 LANGOPT(TraditionalCPP    , 1, 0, "traditional CPP emulation")
 LANGOPT(RTTI              , 1, 1, "run-time type information")
 LANGOPT(RTTIData          , 1, 1, "emit run-time type information data")
 LANGOPT(MSBitfields       , 1, 0, "Microsoft-compatible structure layout")
 LANGOPT(MSVolatile        , 1, 0, "Microsoft-compatible volatile loads and stores")
 LANGOPT(Freestanding, 1, 0, "freestanding implementation")
 LANGOPT(NoBuiltin         , 1, 0, "disable builtin functions")
 LANGOPT(NoMathBuiltin     , 1, 0, "disable math builtin functions")

clang/include/clang/Driver/Options.td

def exception_model : Separate<["-"], "exception-model">,
   NormalizedValues<["DwarfCFI", "SjLj", "WinEH", "Wasm"]>,
   MarshallingInfoEnum<LangOpts<"ExceptionHandling">, "None">;
 def exception_model_EQ : Joined<["-"], "exception-model=">,
   Visibility<[CC1Option]>, Alias<exception_model>;
 def fignore_exceptions : Flag<["-"], "fignore-exceptions">, Group<f_Group>,
   Visibility<[ClangOption, CC1Option]>,
   HelpText<"Enable support for ignoring exception handling constructs">,
   MarshallingInfoFlag<LangOpts<"IgnoreExceptions">>;
+defm assume_nothrow_exception_dtor: BoolFOption<"assume-nothrow-exception-dtor",
+  LangOpts<"AssumeNothrowExceptionDtor">, DefaultFalse,
+  PosFlag<SetTrue, [], [ClangOption, CC1Option], "Assume that exception objects' destructors are non-throwing">,
+  NegFlag<SetFalse>>;
 def fexcess_precision_EQ : Joined<["-"], "fexcess-precision=">, Group<f_Group>,
   Visibility<[ClangOption, CLOption]>,
   HelpText<"Allows control over excess precision on targets where native "
   "support for the precision types is not available. By default, excess "
   "precision is used to calculate intermediate results following the "
   "rules specified in ISO C99.">,
   Values<"standard,fast,none">, NormalizedValuesScope<"LangOptions">,
   NormalizedValues<["FPP_Standard", "FPP_Fast", "FPP_None"]>;

clang/lib/CodeGen/ItaniumCXXABI.cpp

namespace {
   ///     assume that the thrown exception might have a destructor.
   ///   - Catches by reference behave according to their base types.
   ///   - Catches of non-record types will only trigger for exceptions
   ///     of non-record types, which never have destructors.
   ///   - Catches of record types can trigger for arbitrary subclasses
   ///     of the caught type, so we have to assume the actual thrown
   ///     exception type might have a throwing destructor, even if the
   ///     caught type's destructor is trivial or nothrow.
   struct CallEndCatch final : EHScopeStack::Cleanup {
     CallEndCatch(bool MightThrow) : MightThrow(MightThrow) {}
     bool MightThrow;
 
     void Emit(CodeGenFunction &CGF, Flags flags) override {
       if (!MightThrow) {
         CGF.EmitNounwindRuntimeCall(getEndCatchFn(CGF.CGM));
         return;
       }
 
       CGF.EmitRuntimeCallOrInvoke(getEndCatchFn(CGF.CGM));
     }
   };
 }
 
 /// Emits a call to __cxa_begin_catch and enters a cleanup to call
-/// __cxa_end_catch.
+/// __cxa_end_catch. If -fassume-nothrow-exception-dtor is specified, we assume
+/// that the exception object's dtor is nothrow, therefore the __cxa_end_catch
+/// call can be marked as nounwind even if EndMightThrow is true.
 ///
 /// \param EndMightThrow - true if __cxa_end_catch might throw
 static llvm::Value *CallBeginCatch(CodeGenFunction &CGF,
                                    llvm::Value *Exn,
                                    bool EndMightThrow) {
   llvm::CallInst *call =
     CGF.EmitNounwindRuntimeCall(getBeginCatchFn(CGF.CGM), Exn);
 
-  CGF.EHStack.pushCleanup<CallEndCatch>(NormalAndEHCleanup, EndMightThrow);
+  CGF.EHStack.pushCleanup<CallEndCatch>(
+      NormalAndEHCleanup,
+      EndMightThrow && !CGF.CGM.getLangOpts().AssumeNothrowExceptionDtor);
 
   return call;
 }
 
 /// A "special initializer" callback for initializing a catch
 /// parameter during catch initialization.
 static void InitCatchParam(CodeGenFunction &CGF,
                            const VarDecl &CatchParam,

clang/lib/Driver/ToolChains/Clang.cpp

if (types::isCXX(InputType)) {
     }
   }
 
   // OPT_fignore_exceptions means exception could still be thrown,
   // but no clean up or catch would happen in current module.
   // So we do not set EH to false.
   Args.AddLastArg(CmdArgs, options::OPT_fignore_exceptions);
 
+  Args.addOptInFlag(CmdArgs, options::OPT_fassume_nothrow_exception_dtor,
+                    options::OPT_fno_assume_nothrow_exception_dtor);
+
   if (EH)
     CmdArgs.push_back("-fexceptions");
   return EH;
 }
 
 static bool ShouldEnableAutolink(const ArgList &Args, const ToolChain &TC,
                                  const JobAction &JA) {
   bool Default = true;

clang/lib/Sema/SemaExprCXX.cpp

if (Context.getTargetInfo().getCXXABI().isItaniumFamily()) {
     CharUnits ExnObjAlign = Context.getExnObjectAlignment();
     if (ExnObjAlign < TypeAlign) {
       Diag(ThrowLoc, diag::warn_throw_underaligned_obj);
       Diag(ThrowLoc, diag::note_throw_underaligned_obj)
           << Ty << (unsigned)TypeAlign.getQuantity()
           << (unsigned)ExnObjAlign.getQuantity();
     }
   }
+  if (!isPointer && getLangOpts().AssumeNothrowExceptionDtor) {
+    if (CXXDestructorDecl *Dtor = RD->getDestructor()) {
+      auto Ty = Dtor->getType();
+      if (auto *FT = Ty.getTypePtr()->getAs<FunctionProtoType>()) {
+        if (!isUnresolvedExceptionSpec(FT->getExceptionSpecType()) &&
+            !FT->isNothrow())
+          Diag(ThrowLoc, diag::err_throw_object_throwing_dtor) << RD;
+      }
+    }
+  }
 
   return false;
 }
 
 static QualType adjustCVQualifiersForCXXThisWithinLambda(
     ArrayRef<FunctionScopeInfo *> FunctionScopes, QualType ThisTy,
     DeclContext *CurSemaContext, ASTContext &ASTCtx) {
 

clang/test/CodeGenCXX/eh.cpp

-// RUN: %clang_cc1 -fcxx-exceptions -fexceptions -triple x86_64-apple-macosx10.13.99 -std=c++11 -emit-llvm -o - %s | FileCheck --check-prefix=CHECK --check-prefix=UNALIGNED %s
-// RUN: %clang_cc1 -fcxx-exceptions -fexceptions -triple x86_64-apple-macosx10.14 -std=c++11 -emit-llvm -o - %s | FileCheck --check-prefix=CHECK --check-prefix=ALIGNED %s
+// RUN: %clang_cc1 -fcxx-exceptions -fexceptions -triple x86_64-apple-macosx10.13.99 -std=c++11 -emit-llvm -o - %s | FileCheck --check-prefixes=CHECK,UNALIGNED,THROWEND %s
+// RUN: %clang_cc1 -fcxx-exceptions -fexceptions -triple x86_64-apple-macosx10.14 -std=c++11 -emit-llvm -o - %s | FileCheck --check-prefixes=CHECK,ALIGNED,THROWEND %s
+// RUN: %clang_cc1 -fcxx-exceptions -fexceptions -triple x86_64-apple-macosx10.14 -std=c++11 -emit-llvm -o - %s -fassume-nothrow-exception-dtor -DNOTHROWEND | FileCheck --check-prefixes=CHECK,ALIGNED,NOTHROWEND %s
 
 struct test1_D {
   double d;
 } d1;
 
 void test1() {
   throw d1;
 }
void foo() {
     } catch (int i) {
     // CHECK:      call ptr @__cxa_begin_catch
     // CHECK-NEXT: load i32, ptr
     // CHECK-NEXT: store i32
     // CHECK-NEXT: call void @__cxa_end_catch() [[NUW:#[0-9]+]]
     } catch (B a) {
     // CHECK:      call ptr @__cxa_begin_catch
     // CHECK-NEXT: call void @llvm.memcpy
-    // CHECK-NEXT: invoke void @__cxa_end_catch()
+    // THROWEND-NEXT:   invoke void @__cxa_end_catch()
+    // NOTHROWEND-NEXT: call void @__cxa_end_catch() [[NUW]]
     } catch (...) {
     // CHECK:      call ptr @__cxa_begin_catch
-    // CHECK-NEXT: invoke void @__cxa_end_catch()
+    // THROWEND-NEXT:   invoke void @__cxa_end_catch()
+    // NOTHROWEND-NEXT: call void @__cxa_end_catch() [[NUW]]
     }
 
-    // CHECK: call void @_ZN6test101AD1Ev(
+    // THROWEND:       call void @_ZN6test101AD1Ev(
+    // NOTHROWEND-NOT: call void @_ZN6test101AD1Ev(
   }
 }
 
 // __cxa_begin_catch returns pointers by value, even when catching by reference
 namespace test11 {
   void opaque();
 
   // CHECK-LABEL: define{{.*}} void @_ZN6test113fooEv()

 namespace test16 {
   struct A { A(); ~A() noexcept(false); };
   struct B { int x; B(const A &); ~B() noexcept(false); };
   void foo();
   bool cond();
 
   // CHECK-LABEL: define{{.*}} void @_ZN6test163barEv()
   void bar() {
-    // CHECK:      [[EXN_SAVE:%.*]] = alloca ptr
-    // CHECK-NEXT: [[EXN_ACTIVE:%.*]] = alloca i1
-    // CHECK-NEXT: [[TEMP:%.*]] = alloca [[A:%.*]],
-    // CHECK-NEXT: [[EXNSLOT:%.*]] = alloca ptr
-    // CHECK-NEXT: [[SELECTORSLOT:%.*]] = alloca i32
-    // CHECK-NEXT: [[TEMP_ACTIVE:%.*]] = alloca i1
+    // THROWEND:      [[EXN_SAVE:%.*]] = alloca ptr
+    // THROWEND-NEXT: [[EXN_ACTIVE:%.*]] = alloca i1
+    // THROWEND-NEXT: [[TEMP:%.*]] = alloca [[A:%.*]],
+    // THROWEND-NEXT: [[EXNSLOT:%.*]] = alloca ptr
+    // THROWEND-NEXT: [[SELECTORSLOT:%.*]] = alloca i32
+    // THROWEND-NEXT: [[TEMP_ACTIVE:%.*]] = alloca i1
 
+#ifndef NOTHROWEND
     cond() ? throw B(A()) : foo();
+#endif
 
-    // CHECK-NEXT: [[COND:%.*]] = call noundef zeroext i1 @_ZN6test164condEv()
-    // CHECK-NEXT: store i1 false, ptr [[EXN_ACTIVE]]
-    // CHECK-NEXT: store i1 false, ptr [[TEMP_ACTIVE]]
-    // CHECK-NEXT: br i1 [[COND]],
-
-    // CHECK:      [[EXN:%.*]] = call ptr @__cxa_allocate_exception(i64 4)
-    // CHECK-NEXT: store ptr [[EXN]], ptr [[EXN_SAVE]]
-    // CHECK-NEXT: store i1 true, ptr [[EXN_ACTIVE]]
-    // CHECK-NEXT: invoke void @_ZN6test161AC1Ev(ptr {{[^,]*}} [[TEMP]])
-    // CHECK:      store i1 true, ptr [[TEMP_ACTIVE]]
-    // CHECK-NEXT: invoke void @_ZN6test161BC1ERKNS_1AE(ptr {{[^,]*}} [[EXN]], ptr noundef nonnull align {{[0-9]+}} dereferenceable({{[0-9]+}}) [[TEMP]])
-    // CHECK:      store i1 false, ptr [[EXN_ACTIVE]]
-    // CHECK-NEXT: invoke void @__cxa_throw(ptr [[EXN]],
-
-    // CHECK:      invoke void @_ZN6test163fooEv()
-    // CHECK:      br label
-
-    // CHECK:      invoke void @_ZN6test161AD1Ev(ptr {{[^,]*}} [[TEMP]])
-    // CHECK:      ret void
-
-    // CHECK:      [[T0:%.*]] = load i1, ptr [[EXN_ACTIVE]]
-    // CHECK-NEXT: br i1 [[T0]]
-    // CHECK:      [[T1:%.*]] = load ptr, ptr [[EXN_SAVE]]
-    // CHECK-NEXT: call void @__cxa_free_exception(ptr [[T1]])
-    // CHECK-NEXT: br label
+    // THROWEND-NEXT: [[COND:%.*]] = call noundef zeroext i1 @_ZN6test164condEv()
+    // THROWEND-NEXT: store i1 false, ptr [[EXN_ACTIVE]]
+    // THROWEND-NEXT: store i1 false, ptr [[TEMP_ACTIVE]]
+    // THROWEND-NEXT: br i1 [[COND]],
+
+    // THROWEND:      [[EXN:%.*]] = call ptr @__cxa_allocate_exception(i64 4)
+    // THROWEND-NEXT: store ptr [[EXN]], ptr [[EXN_SAVE]]
+    // THROWEND-NEXT: store i1 true, ptr [[EXN_ACTIVE]]
+    // THROWEND-NEXT: invoke void @_ZN6test161AC1Ev(ptr {{[^,]*}} [[TEMP]])
+    // THROWEND:      store i1 true, ptr [[TEMP_ACTIVE]]
+    // THROWEND-NEXT: invoke void @_ZN6test161BC1ERKNS_1AE(ptr {{[^,]*}} [[EXN]], ptr noundef nonnull align {{[0-9]+}} dereferenceable({{[0-9]+}}) [[TEMP]])
+    // THROWEND:      store i1 false, ptr [[EXN_ACTIVE]]
+    // THROWEND-NEXT: invoke void @__cxa_throw(ptr [[EXN]],
+
+    // THROWEND:      invoke void @_ZN6test163fooEv()
+    // THROWEND:      br label
+
+    // THROWEND:      invoke void @_ZN6test161AD1Ev(ptr {{[^,]*}} [[TEMP]])
+    // THROWEND:      ret void
+
+    // THROWEND:      [[T0:%.*]] = load i1, ptr [[EXN_ACTIVE]]
+    // THROWEND-NEXT: br i1 [[T0]]
+    // THROWEND:      [[T1:%.*]] = load ptr, ptr [[EXN_SAVE]]
+    // THROWEND-NEXT: call void @__cxa_free_exception(ptr [[T1]])
+    // THROWEND-NEXT: br label
   }
 }
 
 namespace test17 {
 class BaseException {
 private:
   int a[4];
 public:

clang/test/CodeGenCXX/exceptions.cpp

 // RUN: %clang_cc1 -no-enable-noundef-analysis %s -triple=x86_64-linux-gnu -emit-llvm -std=c++98 -o - -fcxx-exceptions -fexceptions | FileCheck -check-prefix=CHECK -check-prefix=CHECK98 %s
-// RUN: %clang_cc1 -no-enable-noundef-analysis %s -triple=x86_64-linux-gnu -emit-llvm -std=c++11 -o - -fcxx-exceptions -fexceptions | FileCheck -check-prefix=CHECK -check-prefix=CHECK11 %s
+// RUN: %clang_cc1 -no-enable-noundef-analysis %s -triple=x86_64-linux-gnu -emit-llvm -std=c++11 -o - -fcxx-exceptions -fexceptions | FileCheck --check-prefixes=CHECK,CHECK11,THROWEND11 %s
+// RUN: %clang_cc1 -no-enable-noundef-analysis %s -triple=x86_64-linux-gnu -emit-llvm -std=c++11 -o - -fcxx-exceptions -fexceptions -fassume-nothrow-exception-dtor | FileCheck --check-prefixes=CHECK,CHECK11,NOTHROWEND11 %s
 
 // CHECK: %[[STRUCT_TEST13_A:.*]] = type { i32, i32 }
 
 typedef __typeof(sizeof(0)) size_t;
 
 // Declare the reserved global placement new.
 void *operator new(size_t, void*);
 
namespace test10 {
   // CHECK:      invoke void @_ZN6test107cleanupEv()
   // CHECK:      call ptr @__cxa_begin_catch
   // CHECK-NEXT: load i8, ptr @_ZN6test108suppressE, align 1
   // CHECK-NEXT: trunc
   // CHECK-NEXT: br i1
 
   // CHECK98:      call void @__cxa_end_catch()
   // CHECK98-NEXT: br label
-  // CHECK11:      invoke void @__cxa_end_catch()
-  // CHECK11-NEXT: to label
+  // THROWEND11:        invoke void @__cxa_end_catch()
+  // THROWEND11-NEXT:   to label %invoke.cont[[#]] unwind label %terminate.lpad
+  // NOTHROWEND11:      call void @__cxa_end_catch()
+  // NOTHROWEND11-NEXT: br label %try.cont
 
   // CHECK:      invoke void @__cxa_rethrow()
   // CHECK:      unreachable
+
+  // CHECK:      terminate.lpad:
+  // CHECK:        call void @__clang_call_terminate(
 }
 
 // Ensure that an exception in a constructor destroys
 // already-constructed array members.  PR14514
 namespace test11 {
   struct A {
     A();
     ~A() {}

clang/test/CodeGenCoroutines/coro-cleanup.cpp

 // Verify that coroutine promise and allocated memory are freed up on exception.
-// RUN: %clang_cc1 -std=c++20 -triple=x86_64-unknown-linux-gnu -emit-llvm -o - %s -fexceptions -fcxx-exceptions -disable-llvm-passes | FileCheck %s
+// RUN: %clang_cc1 -std=c++20 -triple=x86_64-unknown-linux-gnu -emit-llvm -o - %s -fexceptions -fcxx-exceptions -disable-llvm-passes | FileCheck %s --check-prefixes=CHECK,THROWEND
+// RUN: %clang_cc1 -std=c++20 -triple=x86_64-unknown-linux-gnu -emit-llvm -o - %s -fexceptions -fcxx-exceptions -fassume-nothrow-exception-dtor -disable-llvm-passes | FileCheck %s --check-prefixes=CHECK,NOTHROWEND
 
 namespace std {
 template <typename... T> struct coroutine_traits;
 
 template <class Promise = void> struct coroutine_handle {
   coroutine_handle() = default;
   static coroutine_handle from_address(void *) noexcept;
 };
void f() {
   // If promise constructor throws, check that we free the memory.
 
   // CHECK: invoke void @_ZNSt16coroutine_traitsIJvEE12promise_typeC1Ev(
   // CHECK-NEXT: to label %{{.+}} unwind label %[[DeallocPad:.+]]
 
   // CHECK: [[DeallocPad]]:
   // CHECK-NEXT: landingpad
   // CHECK-NEXT:   cleanup
-  // CHECK: br label %[[Dealloc:.+]]
+  // THROWEND:        br label %[[Dealloc:.+]]
+  // NOTHROWEND:      icmp ne ptr %[[#]], null
+  // NOTHROWEND-NEXT: br i1 %[[#]], label %[[Dealloc:.+]], label
 
   Cleanup cleanup;
   may_throw();
 
   // if may_throw throws, check that we destroy the promise and free the memory.
 
   // CHECK: invoke void @_Z9may_throwv(
   // CHECK-NEXT: to label %{{.+}} unwind label %[[CatchPad:.+]]
 
   // CHECK: [[CatchPad]]:
   // CHECK-NEXT:  landingpad
   // CHECK-NEXT:       catch ptr null
   // CHECK:  call void @_ZN7CleanupD1Ev(
   // CHECK:  br label %[[Catch:.+]]
 
   // CHECK: [[Catch]]:
   // CHECK:    call ptr @__cxa_begin_catch(
   // CHECK:    call void @_ZNSt16coroutine_traitsIJvEE12promise_type19unhandled_exceptionEv(
-  // CHECK:    invoke void @__cxa_end_catch()
-  // CHECK-NEXT:    to label %[[Cont:.+]] unwind
+  // THROWEND:        invoke void @__cxa_end_catch()
+  // THROWEND-NEXT:     to label %[[Cont:.+]] unwind
+  // NOTHROWEND:      call void @__cxa_end_catch()
+  // NOTHROWEND-NEXT:   br label %[[Cont2:.+]]
 
-  // CHECK: [[Cont]]:
-  // CHECK-NEXT: br label %[[Cont2:.+]]
-  // CHECK: [[Cont2]]:
-  // CHECK-NEXT: br label %[[Cleanup:.+]]
+  // THROWEND:      [[Cont]]:
+  // THROWEND-NEXT:   br label %[[Cont2:.+]]
+  // CHECK:         [[Cont2]]:
+  // CHECK-NEXT:      br label %[[Cleanup:.+]]
 
   // CHECK: [[Cleanup]]:
   // CHECK: call void @_ZNSt16coroutine_traitsIJvEE12promise_typeD1Ev(
   // CHECK: %[[Mem0:.+]] = call ptr @llvm.coro.free(
   // CHECK: call void @_ZdlPv(ptr noundef %[[Mem0]]
 
   // CHECK: [[Dealloc]]:
-  // CHECK:   %[[Mem:.+]] = call ptr @llvm.coro.free(
-  // CHECK:   call void @_ZdlPv(ptr noundef %[[Mem]])
+  // THROWEND:   %[[Mem:.+]] = call ptr @llvm.coro.free(
+  // THROWEND:   call void @_ZdlPv(ptr noundef %[[Mem]])
 
   co_return;
 }
 
 // CHECK-LABEL: define{{.*}} void @_Z1gv(
 void g() {
   for (;;)
     co_await suspend_always{};
   // Since this is the endless loop there should be no fallthrough handler (call to 'return_void').
   // CHECK-NOT: call void @_ZNSt16coroutine_traitsIJvEE12promise_type11return_voidEv
 }

clang/test/Driver/clang-exception-flags.cpp

 // OFF3-NOT: "-cc1" {{.*}} "-fcxx-exceptions"
 //
 // RUN: %clang -### -fexceptions -fno-cxx-exceptions %s 2>&1 | FileCheck %s -check-prefix=OFF4
 // OFF4-NOT: "-cc1" {{.*}} "-fcxx-exceptions"
 //
 // RUN: %clang -### -target x86_64-scei-ps4 %s 2>&1 | FileCheck %s -check-prefix=PS-OFF
 // RUN: %clang -### -target x86_64-sie-ps5 %s 2>&1 | FileCheck %s -check-prefix=PS-OFF
 // PS-OFF-NOT: "-cc1" {{.*}} "-f{{(cxx-)?}}exceptions"
+
+// RUN: %clang -### -fexceptions -fno-assume-nothrow-exception-dtor -fassume-nothrow-exception-dtor %s 2>&1 | FileCheck %s --check-prefix=NOTHROW-DTOR
+// NOTHROW-DTOR: "-cc1"{{.*}} "-fcxx-exceptions" "-fassume-nothrow-exception-dtor"

clang/test/SemaCXX/assume-nothrow-exception-dtor.cpp

+// RUN: %clang_cc1 -triple %itanium_abi_triple -fsyntax-only %s -fcxx-exceptions -fassume-nothrow-exception-dtor -verify
+
+namespace test1 {
+template <typename T> struct A { A(); ~A(); };
+struct B { ~B() noexcept(false); };
+struct B1 : B {};
+struct B2 { B b; };
+struct C { virtual void f(); } c;
+struct MoveOnly { MoveOnly(); MoveOnly(MoveOnly&&); };
+void run() {
+  throw A<int>();
+  throw B();  // expected-error{{cannot throw object of type 'B' with a potentially-throwing destructor}}
+  throw new B;
+  throw B1(); // expected-error{{cannot throw object of type 'B1' with a potentially-throwing destructor}}
+  B2 b2;
+  throw b2;   // expected-error{{cannot throw object of type 'B2' with a potentially-throwing destructor}}
+  throw c;
+  MoveOnly m;
+  throw m;
+}
+}