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 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
