On 12/10/23 05:22, Richard Biener wrote:
Am 09.12.2023 um 21:13 schrieb Jason Merrill <ja...@redhat.com>:
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.
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?
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?
Jason
