[cxx-abi-dev] Transfer modes for parameters and return values

David Vandevoorde daveed at edg.com
Mon Nov 26 22:04:51 UTC 2012


That works for me.

	Daveed


On Nov 26, 2012, at 4:09 PM, Richard Smith <richardsmith at google.com> wrote:

> On Mon, Nov 26, 2012 at 12:23 PM, John McCall <rjmccall at apple.com> wrote:
> 
>> On Nov 25, 2012, at 9:03 PM, Richard Smith <richardsmith at google.com>
>> wrote:
>> 
>> On Fri, Nov 23, 2012 at 12:37 PM, Jason Merrill <jason at redhat.com> wrote:
>> 
>>> On 06/03/2009 04:59 PM, David Vandevoorde wrote:
>>> 
>>>> In 3.1.1 and 3.1.4, the ABI specifies that "by value" class type
>>>> parameters and class type return values are passed via the address of a
>>>> reference if the class type has
>>>>     (a) a nontrivial destructor, or
>>>>     (b) a nontrivial copy constructor.
>>>> 
>>>> Should we now also add to that:
>>>>     (c) a (nontrivial) move constructor
>>>> ?
>>>> 
>>> 
>>> This change doesn't seem to have been applied to the ABI, though G++
>>> implements it.  What are other compilers doing?
>> 
>> 
>> I happened to be looking into this very recently... Clang implements the
>> ABI as currently specified (along with the corresponding miscompiles).
>> However, the proposed approach doesn't appear to remove all the
>> miscompiles, for at least two reasons:
>> 
>> 1) A parameter can be passed or a return value constructed by calling a
>> constructor which is not a copy or move constructor. This can happen when a
>> templated constructor is selected:
>> 
>> struct A {
>>  A(const A&) = default; // suppress implicit move constructor, still
>> trivial
>>  template<typename T> A(T &&); // chosen for copies from non-const
>> objects and for moves, not a copy constructor nor a move constructor
>> };
>> 
>> 2) A parameter can be passed or a return value constructed by
>> copy-list-initialization with no copy or move occurring:
>> 
>> struct B {
>>  B(int);
>>  B(const B&) = delete; // deleted, but still trivial
>>  B(B&&) = delete; // likewise
>>  B *p = this;
>> };
>> B f(B x) {
>>  return { 1 };
>> }
>> void g() {
>>  f({2});
>> }
>> 
>> Both of these cases can lead to miscompiles with both g++ 4.7 and Clang
>> trunk due to the ABI's rules. Both problems can also arise for classes with
>> no user-declared special members.
>> 
>> The second issue in particular seems unsolvable without a major ABI break
>> or a core language change (we cannot pass types in registers if they have
>> any non-trivial constructors).
>> 
>> 
>> I think a relatively modest core language change would simply be to say
>> that passing or returning a trivially copyable type is allowed to introduce
>> extra copies.  That would make your examples have unspecified behavior.
>> 
> 
> The rule would need more finessing (as proposed, it would be disastrous for
> 'struct B', and would still require an ABI break for classes which have
> trivial copy construction but non-trivial copy assignment), but I think
> something along these lines could be workable.
> 
> Suggestion for core language:
> 
> When an object of class type C is passed to or returned from a function, if
> C has a trivial, accessible copy or move constructor that is not deleted,
> and has no non-trivial copy constructors, move constructors, nor
> destructors, implementations are permitted to perform an additional copy or
> move of the object using the trivial constructor (even if it would not be
> selected by overload resolution to perform a copy or move of the object).
> [Note: This latitude is granted to allow objects of class type to be passed
> to or returned from functions in registers -- end note]
> 
> Suggestion for Itanium ABI:
> 
> [parameters and return values are passed by address if] the type has a
> non-trivial copy constructor, move constructor or destructor, or if neither
> the copy constructor nor the move constructor is public and non-deleted.
> 
> If that seems reasonable, I'll take this over to the core reflector for
> more discussion.
> _______________________________________________
> cxx-abi-dev mailing list
> cxx-abi-dev at codesourcery.com
> http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev



More information about the cxx-abi-dev mailing list