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 10:46 AM, Jonathan Wakely via cfe-commits <
cfe-commits at lists.llvm.org> wrote:

> On 8 February 2016 at 18:31, H.J. Lu <hjl.tools at gmail.com> wrote:
> > On Mon, Feb 8, 2016 at 10:30 AM, Jonathan Wakely <jwakely.gcc at gmail.com>
> wrote:
> >> On 8 February 2016 at 18:26, Jonathan Wakely <jwakely.gcc at gmail.com>
> wrote:
> >>> On 8 February 2016 at 17:58, H.J. Lu wrote:
> >>>> On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely <
> jwakely.gcc at gmail.com> wrote:
> >>>>>>> A type is a standard-layout type, or it isn't.
> >>>>>>
> >>>>>> How about "An empty record is standard-layout Plain Old Data (POD)
> >>>>>> type and ..."?
> >>>>>
> >>>>> That's redundant, all POD types are standard-layout types.
> >>>>>
> >>>>
> >>>> Apparently, not all standard-layout types are POD types.  GCC has
> >>>>
> >>>> /* Nonzero means that this class type is not POD for the purpose of
> layout
> >>>>    (as defined in the ABI).  This is different from the language's
> POD.  */
> >>>> CLASSTYPE_NON_LAYOUT_POD_P
> >>>>
> >>>> and
> >>>>
> >>>> /* Nonzero means that this class type is a non-standard-layout
> class.  */
> >>>> #define CLASSTYPE_NON_STD_LAYOUT
> >>>>
> >>>> They aren't the same.
> >>>>
> >>>> struct A { };
> >>>> struct B { };
> >>>> struct C : A, B { };
> >>>>
> >>>> C is a standard-layout type, but not a standard-layout POD type.
> >>>
> >>> As the comment says, "POD for the purposes of layout" is different
> >>> from the language's POD. All standard-layout types are POD types
> >>> according to the language.
> >>>
> >>> So when you previously had "POD for the purposes of layout" that was
> >>> at least partially clear that you meant something other than what the
> >>> language means. But as pointed out, using a GCC-specific term is not
> >>> ideal.
> >>>
> >>> When you changed it to "POD for the purpose of standard-layout" that
> >>> became a completely meaningless term. Where is that defined?
> >>>
> >>> Your next suggestion was "standard-layout Plain Old Data (POD)" which
> >>> is even worse, now you're using two terms defined by the C++ language,
> >>> but you mean something different.
> >>>
> >>> When you mean something that is the same as the language (like "class
> >>> type") it makes sense to use the same term.
> >>>
> >>> When you mean something that is not the same as the language (like
> >>> "POD") it makes sense to use a different term, or clearly define how
> >>> you are using it.
> >>
> >> To be clear: it's really confusing to take two terms defined by the
> >> language, "POD" and "standard-layout", and smash them together to mean
> >> something new.
> >>
> >> According to your proposal, struct C is a POD type, and  a
> >> standard-layout type, but not a "standard-layout POD type". That's
> >> just crazy.
> >
> > Can you suggest a better wording?
>
> I don't know what the definition of "POD for the purposes of layout"
> is, but if I was trying to define a better name for it I would start
> by trying to understand how it is specified, instead of just throwing
> existing terms together.


"POD for the purpose of layout" is defined in the Itanium C++ ABI here:

  http://mentorembedded.github.io/cxx-abi/abi.html#definitions

> Another issue, if I define
> >
> > 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
> >    c. An array of empty class types.
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > Will it confuse people?
>
> Yes :-)
>
> But that was already confusing when you called it an "empty
> collection" because an array isn't a collection.
>
> If I understand correctly, your proposal says that given:
>
> struct A { };  // empty class type
> typedef A A2[2];  // array of empty class types
>
> struct B { A a[2]; };  // empty record?
>
> struct B is an empty record ... is that right?
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160208/6e6c55e0/attachment.html>