C++ Logo


Advanced search

Re: [std-proposals] Relocation in C++

From: Edward Catmur <ecatmur_at_[hidden]>
Date: Fri, 23 Dec 2022 21:36:34 +0100
On Fri, 23 Dec 2022 at 10:13, S├ębastien Bini <sebastien.bini_at_[hidden]>

> I don't see the benefits of making it ill-formed for immovable types,
>>> while I clearly see some benefits of allowing it. A function taking a
>>> lock_guard by value needs not do anything different than before, since
>>> lock_guard has no relocation constructor. If the ABI allows it, then `reloc
>>> guard;` will call the destructor, otherwise it's ill-formed.
>> OK. I want to avoid making discarded-value expressions magic, but maybe
>> we can accomplish that by having the relocation occur (or potentially
>> occur) at temporary materialization, as you've suggested.
> That seems like the best approach.
>> The other thing I want is for well-formedness of code (here `reloc
>> guard;`) to not be platform-dependent. So `reloc guard;` is always valid,
>> but may prevent linking a calling TU compiled by an old compiler or under
>> an old standard.
> Yes, well-formedness is important. I don't know how to make `reloc guard`
> always valid without breaking the ABI even more...
> Things are already complex enough, and I don't believe that is required to
> have for the MVP. So I'd say that relocation+destroy must be legal,
> although relocation may be elided (so `reloc guard;` is ill-formed because
> immovable). This is suboptimal, but at least it doesn't close the door to
> future evolutions. And another proposal can be made later, especially when
> we have a first feedback on how well the ABI evolution was handled by
> library/compiler vendors.

OK, I'm reluctantly coming round. The issue that's changed my stance is
that tricks with symbols and thunks are all very good, but function
pointers and virtual functions blow a hole in any such scheme; we cannot
require a change in ABI for function pointers and virtual functions taking
existing types unchanged across language (or compiler) versions.

So at minimum `reloc guard` will have to be ill-formed for `guard` a
by-value function parameter of an immovable type on Itanium. The question
is then whether this extends to callee-destroy platforms, and whether it
extends to local variables. I feel like saying that unmaterialized
temporaries relocated from function parameters behave differently is the
better option, such that `reloc guard` is always ill-formed for `guard` an
immovable by-value function parameter, and well-formed otherwise.

Received on 2022-12-23 20:36:47