[clang] [Clang] More aggressively mark this* dead_on_return in destructors (PR #183347)

Oliver Hunt via cfe-commits cfe-commits at lists.llvm.org
Tue Apr 7 23:00:13 PDT 2026


ojhunt wrote:

> > I'm not sure what semantics are being applied here.
> 
> My understanding is the semantics that are being applied here after the most recent fix are strictly about _objects_, not about _storage_. At the point where the lifetime of an object of type `T` ends, we are no longer required to preserve the value stored in that object. And so we can treat the contents of that object as "becoming `undef` / `poison`" (being dead) at the point where the destructor completes.
> 
> `operator delete` isn't involved in this in any way, except that at the ABI level there is a "deleting destruction" operation that combines a destructor with an invocation of `operator delete`, and we inaccurately internally think of the combined function as being a destructor. This led to a bug where we'd accidentally mark the object as being dead too late -- after the `operator delete` ran, at the end of the deleting destructor, instead of after the end of the actual destructor and before the `operator delete` call.

I'm trying to understand (from the example in https://github.com/llvm/llvm-project/pull/183347#pullrequestreview-4044060000) -- is the problem path 

1. the destructor is run (which should end the object lifetime)
2. then delete runs, and writes to the memory
3. _now_ clang actually says the object lifetime is ended and has become poison/undef

Then because (3) happens after the write in (2), we decide the write in (2) is unobservable and drop it?

https://github.com/llvm/llvm-project/pull/183347


More information about the cfe-commits mailing list