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

[Richard Smith via cfe-commits]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160208/f5035019/attachment-0001.html>