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

[H.J. Lu via cfe-commits]

On Tue, Feb 9, 2016 at 6:45 AM, H.J. Lu <hjl.tools at gmail.com> wrote:
> On Mon, Feb 8, 2016 at 3:28 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>> On Mon, Feb 8, 2016 at 3:01 PM, H.J. Lu <hjl.tools at gmail.com> wrote:
>>> On Mon, Feb 8, 2016 at 2:58 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>>>> On Mon, Feb 8, 2016 at 2:54 PM, H.J. Lu <hjl.tools at gmail.com> wrote:
>>>>> On Mon, Feb 8, 2016 at 2:51 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>>>>>> On Mon, Feb 8, 2016 at 2:46 PM, H.J. Lu <hjl.tools at gmail.com> wrote:
>>>>>>> On Mon, Feb 8, 2016 at 2:35 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>>>>>>>> On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu <hjl.tools at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>>>>>>>>> > On Mon, Feb 8, 2016 at 12:05 PM, H.J. Lu <hjl.tools at gmail.com> wrote:
>>>>>>>>> >>
>>>>>>>>> >> On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely <jwakely.gcc at gmail.com>
>>>>>>>>> >> wrote:
>>>>>>>>> >> > On 8 February 2016 at 19:23, Richard Smith wrote:
>>>>>>>>> >> >> "POD for the purpose of layout" is defined in the Itanium C++ ABI here:
>>>>>>>>> >> >>
>>>>>>>>> >> >>   http://mentorembedded.github.io/cxx-abi/abi.html#definitions
>>>>>>>>> >> >
>>>>>>>>> >> > Thanks. So there's no problem using "POD for the purposes of layout",
>>>>>>>>> >> > and the change to "POD for the purpose of standard-layout" was
>>>>>>>>> >> > unnecessary and just confused things.
>>>>>>>>> >>
>>>>>>>>> >> Here is the revised proposal:
>>>>>>>>> >>
>>>>>>>>> >> 1. "class type".  A class type is a structure, union or C++ class.
>>>>>>>>> >> 2. "empty class type".  An empty class type is:
>>>>>>>>> >>    a. A class type without member.  Or
>>>>>>>>> >>    b. A class type with only members of empty class types.  Or
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > (a) is a special case of (b).
>>>>>>>>> >
>>>>>>>>> >>    c. An array of empty class types.
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > It seems confusing to call an array a class type. Instead, how about:
>>>>>>>>> >
>>>>>>>>> >   2. An empty type is either an array of empty types or a class type where
>>>>>>>>> > every member is of empty type.
>>>>>>>>> >
>>>>>>>>> >> 3. "empty record".  An empty record is Plain Old Data (POD) for the
>>>>>>>>> >>    purposes of layout and
>>>>>>>>> >>    a. A class type without member.  Or
>>>>>>>>> >>    b. A class type with only members of empty class types.
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > (a) is a special case of (b).
>>>>>>>>> >
>>>>>>>>> >> 4. No memory slot nor register should be used to pass or return an object
>>>>>>>>> >> of empty record.
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > Objects of array type are never passed or returned (but if through some
>>>>>>>>> > language extension they were, we'd want this rule to apply). So you don't
>>>>>>>>> > need rule 3 and this can be just:
>>>>>>>>> >
>>>>>>>>> >  3. No memory slot nor register should be used to pass or return an object
>>>>>>>>> > of empty type.
>>>>>>>>>
>>>>>>>>> Thanks very much for your inputs.  Here is the proposal:
>>>>>>>>>
>>>>>>>>> 1. "class type".  A class type is a structure, union or C++ class.
>>>>>>>>> 2. "empty type".  An empty type is either an array of empty types or a
>>>>>>>>> class type where every member is of empty type.
>>>>>>>>> 3. No memory slot nor register should be used to pass or return an object
>>>>>>>>> of empty type.
>>>>>>>>
>>>>>>>> David Majnemer points out that we also need to say something about
>>>>>>>> base classes. We could handle that case like this:
>>>>>>>>
>>>>>>>>  2. "empty type".  An empty type is a type where it and all of its
>>>>>>>> subobjects are of class or array type.
>>>>>>>>
>>>>>>>> Following the C++ rules, this also means that a class that contains
>>>>>>>> only unnamed bitfields is empty, because unnamed bitfields are not
>>>>>>>> subobjects, but might be worth explicitly stating for the C case. That
>>>>>>>> also matches Clang's behavior.
>>>>>>>
>>>>>>> Like this?
>>>>>>>
>>>>>>> 1. "class type".  A class type is a structure, union or C++ class.
>>>>>>> 2. "empty type".  An empty type is
>>>>>>>    a. A type where it and all of its subobjects are of class or array
>>>>>>>    type. And
>>>>>>>    b. Either an array of empty types or a class type where every member
>>>>>>>    is of empty type.
>>>>>>
>>>>>> You don't need (b). It's implied by (a).
>>>>>
>>>>> Does (a) cover empty type?
>>>>
>>>> Yes, (a) is a complete definition of "empty type" by itself: the
>>>> definition is, essentially, that a complete recursive walk of the type
>>>> and all its subobjects never sees anything that would require any
>>>> storage (that is, it only sees class types and array types).
>>>
>>> Is there a definition of subobject?
>>
>> Yes, the C++ standard defines the term (as an object that is contained
>> within another via member, base class, and array element
>> relationships). The C standard uses it in 6.7.9 to mean the same thing
>> (recursing into class and array elements) but doesn't provide a formal
>> definition.
>
> Here is the new one:
>
> 1. "class type".  A class type is a structure, union or C++ class.
> 2. "empty type".  An empty type is Plain Old Data (POD) for the
>    purposes of layout, and.a type where it and all of its subobjects
>    are of class or array type.
>
> I put back " Plain Old Data (POD) for the purposes of layout" to
> explicitly exclude array here.

I updated PDF files for passing/returning empty type:

https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI


-- 
H.J.