[cfe-dev] std::pair not trivially copyable?

[David Blaikie via cfe-dev]

On Wed, Aug 26, 2020 at 11:34 AM Richard Smith via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On Wed, 26 Aug 2020 at 10:18, Nevin Liber via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> On Tue, Aug 25, 2020 at 4:37 PM David Blaikie via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>>
>>> From what I can tell, reading this (
>>> https://stackoverflow.com/questions/58283694/why-is-pair-of-const-trivially-copyable-but-pair-is-not )
>>> and the C++17 spec, it just doesn't specify the copy and move assignment
>>> operators as defaulted, or say anything about their triviality, so they
>>> aren't trivial even for trivial types. Perhaps an oversight when thinking
>>> about the other complexities of when they shuold be deleted.
>>>
>>
>> In general, move/copy assignment cannot be defaulted for pair, because
>> assignment of reference types has meaning:
>>
>> int i = 2;
>> int j = 3;
>> std::pair<int&, int> p1(i, 5);
>> std::pair<int&, int> p2(j, 7);
>> p2 = p1;  // j now has the value 2
>>
>>
>> struct A
>> {
>>     A(int& r_, int i_) : r(r_), i(i_) {}
>>     int& r;
>>     int i;
>> };
>>
>> int i = 2;
>> int j = 3;
>> A a1(i, 5);
>> A a2(j, 7);
>> a2 = a1;  // Compile time error - deleted copy assignment operator
>>
>>
>> Now,  this doesn't that pair couldn't have trivial copy/move assignment
>> operators when it holds trivially copy/move assignable types, but I don't
>> know how much of an ABI break this would be.
>>
>
> Making std::pair be trivially-copyable whenever possible would affect
> whether std::pair is POD for the purpose of layout, which could result in
> an ABI break for at least any code that derives from std::pair or that
> contains a [[no_unique_address]] std::pair member:
> https://godbolt.org/z/GTvo4r
>
> This is certainly not something we could do for the libc++ stable ABI.
> Maybe for the unstable ABI, but given the above change only makes layout
> worse, it's not clear that there would be a strong motivation. We already
> give std::pair trivial copy/move construction and trivial destruction
> whenever possible, so we can pass and return it efficiently.
>

Interesting - so POD for the purpose of layout is... not good? or more
restrictive on the layout than if not. (probably an impractical idea, but
would it be reasonable then to have an attribute that says "not POD for the
purposes of layout" but I guess that'd have to be cross-compiler/etc/etc...
probably too much work)

What's the cost of pair having non-trivial copy assignment? More expensive
vector of pair resizing (though I guess the copy ctor calls would be
readily optimized away & LLVM could get that back to a memcpy anyway?)?

(the original issue with the warning could be fixed by narrowing the
warning to only worry about trivial copy construction, not trivial
copyability in general)

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200826/12e59741/attachment-0001.html>