[cxx-abi-dev] The magic of uncalled copy constructors; documenting the bug

John McCall rjmccall at apple.com
Wed Feb 12 16:55:54 UTC 2014


On Feb 10, 2014, at 12:39 PM, Richard Smith <richardsmith at google.com> wrote:
> On 10 February 2014 09:32, John McCall <rjmccall at apple.com> wrote:
> On Feb 9, 2014, at 6:17 PM, Richard Smith <richardsmith at google.com> wrote:
>> On 9 February 2014 05:37, Hubert Tong <hstong at ca.ibm.com> wrote:
>> Core Issue 1590 mentions that the trivial copy or move constructor should be non-deleted and accessible.
>> Replacing the pair of copy constructors below with private, deleted copy and move constructors seems to make GCC avoid the "magic" copy, but not Clang.
>> Which compiler has the preferred behaviour?
>> 
>> I think GCC does, whereas Clang obeys the current description of the ABI.
>> 
>> Under the current wording of core issue 1590, we're not allowed to perform a 'trivial' copy here. I think we should update the ABI document (in 3.1.1/1) to make this work (perhaps something equivalent to replacing "non-trivial" with "non-trivial, non-public, or deleted" each time it occurs).
> 
> gcc’s rule appears to just be “non-trivial or deleted”, which I think is reasonable for the ABI to adopt.  Would you like to write up a proposal for that?
> 
> Sure.
>  
> “Accessible” does not mean “public”.  That’s a standards bug: we need to be able to decide the ABI signature of a function at its point of declaration, not have it be dependent on whether there exist (or might exist) calls to it which would not be allowed to use a privately-defaulted trivial copy constructor.
> 
> I don't see anything wrong with the standard here. Inaccessible implies non-public for these members (because they're not inherited from a base class), so the ABI can look for a public special member where the standard says any accessible special member is permitted to be called.

Inaccessible does imply non-public, but accessibility in general is context-sensitive.

Are you asking for the ABI rule to actually be “non-public, non-trivial, or deleted”?  I agree that that’s what the standard is requesting, because it’s the only way we can guarantee at the point of declaration of a function that all callers will be able to access the special member.  However, it’s not the current practice of any compiler, probably because we generally try quite hard to prevent access control from affecting the ABI, e.g. because it seems unfortunate for things like "#define private public” to actually break binary compatibility.  (I’ll grant that it’s legal under the standard, and it might also already affect the ABI in corner cases by making a base class suddenly POD.)

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20140212/ca3aeaf7/attachment.html>


More information about the cxx-abi-dev mailing list