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 15:28:00 PST 2016


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.


More information about the cfe-commits mailing list