RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

On Fri, Feb 19, 2016 at 1:07 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> On Fri, Feb 19, 2016 at 5:35 AM, Michael Matz <matz at suse.de> wrote:
>> Hi,
>>
>> On Thu, 18 Feb 2016, Richard Smith wrote:
>>
>>> >> An empty type is a type where it and all of its subobjects
>>> >> (recursively) are of class, structure, union, or array type.  No
>>> >> memory slot nor register should be used to pass or return an object
>>> >> of empty type.
>>> >
>>> > The trivially copyable is gone again.  Why is it not necessary?
>>>
>>> The C++ ABI doesn't defer to the C psABI for types that aren't
>>> trivially-copyable. See
>>> http://mentorembedded.github.io/cxx-abi/abi.html#normal-call
>>
>> Hmm, yes, but we don't want to define something for only C and C++, but
>> language independend (so far as possible).  And given only the above
>> language I think this type:
>>
>> struct S {
>>   S() {something();}
>> };
>>
>> would be an empty type, and that's not what we want.
>
> Yes it is. Did you mean to give S a copy constructor, copy assignment
> operator, or destructor instead?
>
>> "Trivially copyable"
>> is a reasonably common abstraction (if in doubt we could even define it in
>> the ABI), and captures the idea that we need well (namely that a bit-copy
>> is enough).

In this case:

struct dummy0
{
};

struct dummy
{
  dummy0 d[20];

  dummy0 * foo (int i);
};

dummy0 *
dummy::foo (int i)
{
  return &d[i];
}

dummy0 *
bar (dummy d, int i)
{
  return d.foo (i);
}

dummy shouldn't be passed as empty type.  We need to have a clear
definition for what kinds of member functions are allowed in an empty
type.

-- 
H.J.