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

[Richard Smith]

On 6 May 2014 19:57, Jason Merrill <jason at redhat.com> wrote:

> On 05/06/2014 09:31 PM, Richard Smith wrote:
>
>> The core language part of this (core issue 1590) is now in 'ready'
>> status. Time to go ahead with the corresponding ABI change?
>>
>
> On 11/26/2012 04:09 PM, Richard Smith wrote:> Suggestion for Itanium >
> 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.
>>
>
> I disagree with the latter part of this; passing by invisible reference
> should based on triviality, not on callability.


I think it would be *extremely* surprising if we implicitly added a call to
a function that is deleted or inaccessible, that the original code didn't
call. What alternative do you suggest?

Backstory:

struct A {
  A(void*);
  A(const A&) = delete;
  A(A&&) = default;
  void *p;
};

Here, A should "obviously" be passed by value, not by pointer (you don't
want to pass unique_ptr indirectly). And here we have a trivial copy ctor,
a trivial deleted move ctor, and a trivial dtor. But if the copy ctor is
*also* deleted:

struct B {
  B(void*);
  B(const B&) = delete;
  B(B&&) = delete;
  void *p;
};

... then I think it's equally obvious that this should *not* be passed by
value, and must be passed by "invisible reference". Eg:

  B::B(void*) : p(this) {}
  void f(B b) { assert(b.p == &b); } // this assert should hold!
  int main() { f({0}); }

The only difference between these two is whether the copy ctor is deleted
(it's trivial either way). So it seems to me that we /must/ consider that.

Access checking probably doesn't have as compelling a story, but as with
deletedness checking, the fundamental point seems to be that we should not
implicitly *add* a call to a function that the code in question couldn't
originally call.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20140507/cf435b15/attachment.html>