[cxx-abi-dev] Non-trivial move constructor

[John McCall]

> On Jul 1, 2016, at 7:13 AM, Jonathan Wakely <jwakely at redhat.com> wrote:
> On 22/06/16 12:59 -0700, Reid Kleckner wrote:
>> This bug still isn't fixed in Clang. It's
>> https://llvm.org/bugs/show_bug.cgi?id=19668. You should probably go ahead
>> and update the document.
> 
> It's probably also the cause of
> https://llvm.org/bugs/show_bug.cgi?id=23034
> which I've been asked about (because it involves the libstdc++
> std::tuple).
> 
> Is the current status that Clang is still believed to require a
> change, and that G++ is doing the right thing already?

Yes.

John.

> 
> 
> 
>> On Wed, Feb 24, 2016 at 10:41 PM, John McCall <rjmccall at apple.com> wrote:
>> 
>>> > On Feb 24, 2016, at 1:14 PM, Richard Smith <richardsmith at googlers.com>
>>> wrote:
>>> > On 24 February 2016 at 12:56, John McCall <rjmccall at apple.com> wrote:
>>> >>> On Feb 24, 2016, at 11:43 AM, Richard Smith <richardsmith at googlers.com>
>>> wrote:
>>> >>> On 24 February 2016 at 05:54, Jason Merrill <jason at redhat.com> wrote:
>>> >>>> On 02/24/2016 05:51 AM, Marc Glisse wrote:
>>> >>>>>
>>> >>>>> in 3.1.1, we use "In the special case where the parameter type has a
>>> >>>>> non-trivial copy constructor or destructor" to force passing by
>>> >>>>> reference. It seems that for C++11, this should also include move
>>> >>>>> constructors, for the same reasons.
>>> >>>>
>>> >>>>
>>> >>>> We talked about adding move constructors to that sentence years ago.
>>> Did it
>>> >>>> never make it into the spec?
>>> >>>
>>> >>> Looks like it didn't. The rule we ended up with was:
>>> >>>
>>> >>> "[Pass an object of class type by value if] every copy constructor and
>>> >>> move constructor is deleted or trivial and at least one of them is not
>>> >>> deleted, and the destructor is trivial.”
>>> >>>
>>> >>>
>>> >>> However, this seems overly-cautious to me; it would seem sufficient
>>> >>> for there to be at least one copy or move constructor that is trivial
>>> >>> and not deleted, and a trivial destructor. It's not really
>>> >>> particularly plausible for there to be a trivial copy and a
>>> >>> non-trivial move or vice versa, but it *is* plausible for there to be
>>> >>> two non-deleted copy constructors -- a trivial one, and one that takes
>>> >>> a const volatile reference -- and in that case, passing through
>>> >>> registers seems completely reasonable. How about changing the rule in
>>> >>> 3.1.1 bullet 1 to:
>>> >>>
>>> >>> "In the special case where the parameter type does not have both a
>>> >>> trivial destructor and at least one trivial copy or move constructor
>>> >>> that is not deleted, the caller must allocate space for a temporary
>>> >>> copy, and pass the resulting copy by reference (below). Specifically
>>> >>> […]"
>>> >>
>>> >> I agree with your proposal in theory, but I’m concerned about changing
>>> >> the ABI at this point.  We *are* talking about the language standard
>>> that was
>>> >> released six years ago, and an area of that standard that was
>>> theoretically
>>> >> fully implemented by compilers several years before that.
>>> >>
>>> >> Do we understand the scope of the ABI disagreement between GCC and
>>> Clang here?
>>> >> What do other compilers do?
>>> >
>>> > Clang's rule is the one in the ABI: a class is passed indirectly if it
>>> > has a non-trivial destructor or a non-trivial copy constructor. This
>>> > rule definitely needs some adjustment, because it's not meaningful to
>>> > ask whether an implicitly-deleted function is trivial.
>>> 
>>> That sounds like it’s on us to fix.  Do GCC and other compilers correctly
>>> implement the rule that we agreed on?  If so, I’ll go ahead and apply
>>> the change to the ABI document, and we should fix this in clang.
>>> 
>>> John.
>>> _______________________________________________
>>> cxx-abi-dev mailing list
>>> cxx-abi-dev at codesourcery.com
>>> http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
>>> 
> 
>> _______________________________________________
>> cxx-abi-dev mailing list
>> cxx-abi-dev at codesourcery.com
>> http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
>