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

Richard Smith via cfe-commits cfe-commits at lists.llvm.org
Mon Feb 8 14:58:29 PST 2016


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


More information about the cfe-commits mailing list