This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- Cc: Florian Weimer <fw at deneb dot enyo dot de>, GCC Development <gcc at gcc dot gnu dot org>, cfe-commits <cfe-commits at lists dot llvm dot org>
- Date: Mon, 8 Feb 2016 10:53:12 -0800
- Subject: Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Authentication-results: sourceware.org; auth=none
- References: <CAMe9rOofYT89yzF6jxFZFG2=QVQuQpEC7DP0HV_epjeawCf_sA at mail dot gmail dot com> <87d1s8wc4w dot fsf at mid dot deneb dot enyo dot de> <CAMe9rOp_6ZpR1YSJZ7AiLpa+FPRGJoLm5fTPkiH5BgF4Tkg3RA at mail dot gmail dot com> <87r3gouvv2 dot fsf at mid dot deneb dot enyo dot de> <CAMe9rOo2tPZKZEgpgFbbSnkyBiONzS9vfntn_QsxRPbVHZGmUw at mail dot gmail dot com> <87k2mgutzr dot fsf at mid dot deneb dot enyo dot de> <CAMe9rOoMujhjExxKWrz-Dv8uE33X=Upvi_X_HZsfeN0GS+=56A at mail dot gmail dot com> <CAMe9rOruCOvtM2D2AmG94A1_8Og8Kfu7tYF4De=XNfzUG+eh5g at mail dot gmail dot com> <CAH6eHdQci21ZhZ4odOfJRjC8s8HjuJ5X73LfK6oqvxCtOnzK6w at mail dot gmail dot com> <CAMe9rOpJXNUNvusTmwFb3riOxXyXLTGTquSMKqZkBe=nbmt_QQ at mail dot gmail dot com> <CAH6eHdQcvj7EY3jXgtUBQePfikiTbcuqsNFpDH7SWyxD628peQ at mail dot gmail dot com> <CAMe9rOrsV-zohnj=31_DDYSxUDyRDYL0anTi_NJm5vqogF9URQ at mail dot gmail dot com> <CAH6eHdQtnzMO6gLLRsczDdvmx0exkqXxyY-WvZ6RjuM7a3=85A at mail dot gmail dot com> <CAH6eHdQQjpOwD2kNCZVjH+w6N0Wh=gbdaaCcjg21iEbaHaAE5A at mail dot gmail dot com> <CAMe9rOq5QL9J0F-isO1njJyDJcZ08gF4zUk4vXNONWSfUtSzwA at mail dot gmail dot com> <CAH6eHdR0vJkYuYeKU=zyhthOY0KT-m8C=m2AtZ5GfVeyPOA=jw at mail dot gmail dot com>
On Mon, Feb 8, 2016 at 10:46 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 8 February 2016 at 18:31, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Mon, Feb 8, 2016 at 10:30 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>>> On 8 February 2016 at 18:26, Jonathan Wakely <jwakely.gcc@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@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.
>
>
>> 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?
Yes, struct B is an empty record. And also in
struct A { };
struct B { };
struct C : A, B { };
C isn't an empty record.
--
H.J.
- References:
- RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct