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

H.J. Lu via cfe-commits cfe-commits at lists.llvm.org
Mon Feb 8 15:01:40 PST 2016


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?

-- 
H.J.


More information about the cfe-commits mailing list