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

[Marc Glisse via cfe-commits]

On Sat, 20 Feb 2016, H.J. Lu wrote:

> 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.

Why not?

> We need to have a clear definition for what kinds of member functions 
> are allowed in an empty type.

-- 
Marc Glisse