On Sun, 10 Dec 2023, Jason Merrill wrote: > On 12/10/23 05:22, Richard Biener wrote: > >> Am 09.12.2023 um 21:13 schrieb Jason Merrill : > >> > >> On 11/2/23 21:18, Nathaniel Shead wrote: > >>> Bootstrapped and regtested on x86-64_pc_linux_gnu. > >>> I'm not entirely sure if the change I made to have destructors clobber > >>> with > >>> CLOBBER_EOL instead of CLOBBER_UNDEF is appropriate, but nothing seemed to > >>> have > >>> broken by doing this and I wasn't able to find anything else that really > >>> depended on this distinction other than a warning pass. Otherwise I could > >>> experiment with a new clobber kind for destructor calls. > >> > >> It seems wrong to me: CLOBBER_EOL is documented to mean that the storage is > >> expiring at that point as well, which a (pseudo-)destructor does not imply; > >> it's perfectly valid to destroy an object and then create another in the > >> same storage. > >> > >> We probably do want another clobber kind for end of object lifetime. And/or > >> one for beginning of object lifetime. > > > > There?s not much semantically different between UNDEF and end of object but > > not storage lifetime? At least for what middle-end optimizations do. > > That's fine for the middle-end, but Nathaniel's patch wants to distinguish > between the clobbers at beginning and end of object lifetime in order to > diagnose stores to an out-of-lifetime object in constexpr evaluation. Ah, I see. I did want to add CLOBBER_SOL (start-of-life) when working on PR90348, but I always fail to finish working on that stack-slot sharing issue. But it would be for the storage life, not object life, also added by gimplification. > One option might be to remove the clobber at the beginning of the constructor; > are there any useful optimizations enabled by that, or is it just pedantically > breaking people's code? It's allowing DSE to the object that was live before the new one. Not all objects require explicit destruction (which would get you a clobber) before storage can be re-used. > > EOL is used by stack slot sharing and that operates on the underlying > > storage, not individual objects live in it. > > I wonder about changing the name to EOS (end of storage [duration]) to avoid > similar confusion with object lifetime? EOS{L,D}? But sure, better names (and documentation) are appreciated. Richard.