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 14:54:49 PST 2016


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?

>> 3. No memory slot nor register should be used to pass or return an object
>> of empty type.
>>
>>
>> --
>> H.J.



-- 
H.J.


More information about the cfe-commits mailing list