Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Sun, Feb 7, 2016 at 12:52 PM, H.J. Lu wrote:
> On Sun, Feb 7, 2016 at 12:48 PM, Florian Weimer wrote:
>> * H. J. Lu:
>>
I tested GCC 5.3.1 and Clang 3.5.0.
GCC Clang
s0 non-emptynon-empty
s1 non-emptyempty
s2 non-emptyempty
s3 emptyempty
s4 emptyempty
s5 non-emptyempty
I believe s3, s4, s5 are non-empty according to your rules. Why put
both compilers in the wrong? That doesn't make sense to me.
>>>
>>> Please try testcases in
>>>
>>> https://llvm.org/bugs/show_bug.cgi?id=26337
>>>
>>> with clang on both ia32 and x86-64. Clang isn't consistent between
>>> ia32 and x86-64.
>>
>> Okay, with -m32, I get non-empty passing for s5 from Clang as well.
>> But I still don't think it makes sense to change the ABI for s3 and
>> s4, and even for s5, the Clang/x86_64 behavior is arguably more
>> correct.
>
> Not really. For
>
> struct dummy0 { };
> struct dummy { struct dummy0 d[PAD_SIZE]; };
>
> clang changes behavior when PAD_SIZE > 16 on x86-64 and PAD_SIZE > 1
> on ia32.
>
Jason already indicated he intends GCC to move towards more empty
arguments, not fewer.
>> How do existing C++ compilers implement empty array members (an
>> extension)? Does the type of such members affect whether a class is a
>> standard-layout class?
> Are they "POD for the purpose of layout"? If yes, they are covered here.
The C++ standard does not define this.
>>>
>>> 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. */
>>> #define CLASSTYPE_NON_LAYOUT_POD_P(NODE) \
>>>
>>> We can use this definition for ia32, x86-64 and IA MCU psABIs.
>>
>> It still has to be spelled out in non-GCC terms, IMHO.
>
> Sure. Do you care to propose a wording for "POD for the purpose of layout"?
>
The standard-layout POD is well defined:
https://en.wikipedia.org/wiki/C%2B%2B11#Modification_to_the_definition_of_plain_old_data
Here is the updated proposal for Intel386, x86-64 and IA MCU psABIs:
1. "collection". A collection is a structure, union or C++ class.
2. "empty collection". An empty collection is:
a. A collection without member. Or
b. A collection with only empty collections. Or
c. An array of empty collections.
3. "empty record". An empty record is Plain Old Data (POD) for the purpose
of standard-layout and
a. A collection without member. Or
b. A collection with only empty collections.
4. No memory slot nor register should be used to pass or return an object of
empty record.
--
H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On 8 February 2016 at 13:54, H.J. Lu wrote: > On Sun, Feb 7, 2016 at 12:52 PM, H.J. Lu wrote: > > The standard-layout POD is well defined: > > https://en.wikipedia.org/wiki/C%2B%2B11#Modification_to_the_definition_of_plain_old_data > > Here is the updated proposal for Intel386, x86-64 and IA MCU psABIs: > > 1. "collection". A collection is a structure, union or C++ class. These are all "class types". Why invent a new term? > 2. "empty collection". An empty collection is: >a. A collection without member. Or What about base classes? What about bit-fields of length 0? >b. A collection with only empty collections. Or What does "with" mean? Only members, or bases too? >c. An array of empty collections. > 3. "empty record". An empty record is Plain Old Data (POD) for the purpose >of standard-layout and "For the purposes of standard-layout" doesn't mean anything. A type is a standard-layout type, or it isn't. Do you mean "An empty record is a standard-layout type and..." >a. A collection without member. Or >b. A collection with only empty collections. ? The C++ standard defines the std::is_empty trait as true when: "T is a class type, but not a union type, with no non-static data members other than bit-fields of length 0, no virtual member functions, no virtual base classes, and no base class B for which is_empty::value is false." > 4. No memory slot nor register should be used to pass or return an object of > empty record.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 7:02 AM, Jonathan Wakely wrote: > On 8 February 2016 at 13:54, H.J. Lu wrote: >> On Sun, Feb 7, 2016 at 12:52 PM, H.J. Lu wrote: >> >> The standard-layout POD is well defined: >> >> https://en.wikipedia.org/wiki/C%2B%2B11#Modification_to_the_definition_of_plain_old_data >> >> Here is the updated proposal for Intel386, x86-64 and IA MCU psABIs: >> >> 1. "collection". A collection is a structure, union or C++ class. > > These are all "class types". Why invent a new term? Because it applies to both C and C++. There is no class in C. >> 2. "empty collection". An empty collection is: >>a. A collection without member. Or > > What about base classes? > > What about bit-fields of length 0? Is a collection with them standard-layout POD type? >>b. A collection with only empty collections. Or > > What does "with" mean? Only members, or bases too? Is "A collection with only members of empty collections" better? >>c. An array of empty collections. >> 3. "empty record". An empty record is Plain Old Data (POD) for the purpose >>of standard-layout and > > "For the purposes of standard-layout" doesn't mean anything. > > 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 ..."? > Do you mean "An empty record is a standard-layout type and..." > >>a. A collection without member. Or >>b. A collection with only empty collections. > > ? > Is "A collection with only members of empty collections" better? > >> 4. No memory slot nor register should be used to pass or return an object of >> empty record. -- H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On 8 February 2016 at 15:42, H.J. Lu wrote:
> On Mon, Feb 8, 2016 at 7:02 AM, Jonathan Wakely wrote:
>> On 8 February 2016 at 13:54, H.J. Lu wrote:
>>> On Sun, Feb 7, 2016 at 12:52 PM, H.J. Lu wrote:
>>>
>>> The standard-layout POD is well defined:
>>>
>>> https://en.wikipedia.org/wiki/C%2B%2B11#Modification_to_the_definition_of_plain_old_data
>>>
>>> Here is the updated proposal for Intel386, x86-64 and IA MCU psABIs:
>>>
>>> 1. "collection". A collection is a structure, union or C++ class.
>>
>> These are all "class types". Why invent a new term?
>
> Because it applies to both C and C++. There is no class in C.
Then you could use the term "class type" in the ABI, defining it to
mean structure or union in C, or class type in C++. No need for a new
term.
>>> 2. "empty collection". An empty collection is:
>>>a. A collection without member. Or
>>
>> What about base classes?
>>
>> What about bit-fields of length 0?
>
> Is a collection with them standard-layout POD type?
(I'm not sure what the "bit-fields of length 0" part is for, but my
point is it would be useful to examine similar concepts in the
standard and align with them, not just make up entirely new
classifications.)
For base classes, yes. A standard-layout class can have base classes
of standard-layout type.
struct A { };
struct B { };
struct C : A, B { };
C is a standard-layout type. Is it an empty collection?
>>>b. A collection with only empty collections. Or
>>
>> What does "with" mean? Only members, or bases too?
>
> Is "A collection with only members of empty collections" better?
Should it mention base classes?
>>>c. An array of empty collections.
>>> 3. "empty record". An empty record is Plain Old Data (POD) for the purpose
>>>of standard-layout and
>>
>> "For the purposes of standard-layout" doesn't mean anything.
>>
>> 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.
>> Do you mean "An empty record is a standard-layout type and..."
>>
>>>a. A collection without member. Or
>>>b. A collection with only empty collections.
>>
>> ?
>>
>
> Is "A collection with only members of empty collections" better?
>
>>
>>> 4. No memory slot nor register should be used to pass or return an object of
>>> empty record.
>
>
>
> --
> H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely wrote:
> On 8 February 2016 at 15:42, H.J. Lu wrote:
>> On Mon, Feb 8, 2016 at 7:02 AM, Jonathan Wakely
>> wrote:
>>> On 8 February 2016 at 13:54, H.J. Lu wrote:
On Sun, Feb 7, 2016 at 12:52 PM, H.J. Lu wrote:
The standard-layout POD is well defined:
https://en.wikipedia.org/wiki/C%2B%2B11#Modification_to_the_definition_of_plain_old_data
Here is the updated proposal for Intel386, x86-64 and IA MCU psABIs:
1. "collection". A collection is a structure, union or C++ class.
>>>
>>> These are all "class types". Why invent a new term?
>>
>> Because it applies to both C and C++. There is no class in C.
>
> Then you could use the term "class type" in the ABI, defining it to
> mean structure or union in C, or class type in C++. No need for a new
> term.
I will do it.
>
2. "empty collection". An empty collection is:
a. A collection without member. Or
>>>
>>> What about base classes?
>>>
>>> What about bit-fields of length 0?
>>
>> Is a collection with them standard-layout POD type?
>
> (I'm not sure what the "bit-fields of length 0" part is for, but my
> point is it would be useful to examine similar concepts in the
> standard and align with them, not just make up entirely new
> classifications.)
I am replying on C++ compiler to tell if it is standard-layout
or not.
> For base classes, yes. A standard-layout class can have base classes
> of standard-layout type.
>
> struct A { };
> struct B { };
> struct C : A, B { };
>
> C is a standard-layout type. Is it an empty collection?
My understanding is
A type that is standard-layout means that it orders and packs its
members in a way that is compatible with C.
What is the corresponding compatible type in C?
b. A collection with only empty collections. Or
>>>
>>> What does "with" mean? Only members, or bases too?
>>
>> Is "A collection with only members of empty collections" better?
>
> Should it mention base classes?
It depends on the answer of my question above.
>
c. An array of empty collections.
3. "empty record". An empty record is Plain Old Data (POD) for the purpose
of standard-layout and
>>>
>>> "For the purposes of standard-layout" doesn't mean anything.
>>>
>>> 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.
>
I will update it.
Thanks.
--
H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On 8 February 2016 at 16:05, H.J. Lu wrote: > My understanding is > > A type that is standard-layout means that it orders and packs its > members in a way that is compatible with C. > > What is the corresponding compatible type in C? An empty structure, such as struct A. One of the requirements for standard-layout classes is "has all non-static data members and bit-fields in the class and its base classes first declared in the same class" so standard layout classes are allowed to have base classes, as long as either the base class is empty (so doesn't alter layout) or the derived class doesn't add members (so has the same layout as the base). If neither the base class is an empty record, and the derived class doesn't add any non-static data members or bit-fields, then the base class should be an empty record too.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 8:15 AM, Jonathan Wakely wrote:
> On 8 February 2016 at 16:05, H.J. Lu wrote:
>> My understanding is
>>
>> A type that is standard-layout means that it orders and packs its
>> members in a way that is compatible with C.
>>
>> What is the corresponding compatible type in C?
>
> An empty structure, such as struct A.
>
> One of the requirements for standard-layout classes is "has all
> non-static data members and bit-fields in the class and its base
> classes first declared in the same class" so standard layout classes
> are allowed to have base classes, as long as either the base class is
> empty (so doesn't alter layout) or the derived class doesn't add
> members (so has the same layout as the base). If neither the base
> class is an empty record, and the derived class doesn't add any
> non-static data members or bit-fields, then the base class should be
> an empty record too.
if it is the case
struct A { };
struct B { };
struct C : A, B { };
is an empty record.
--
H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely 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.
--
H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On 8 February 2016 at 18:26, Jonathan Wakely wrote:
> On 8 February 2016 at 17:58, H.J. Lu wrote:
>> On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely
>> 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.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 10:30 AM, Jonathan Wakely wrote:
> On 8 February 2016 at 18:26, Jonathan Wakely wrote:
>> On 8 February 2016 at 17:58, H.J. Lu wrote:
>>> On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely
>>> 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?
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?
--
H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On 8 February 2016 at 17:58, H.J. Lu wrote:
> On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely 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.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On 8 February 2016 at 18:31, H.J. Lu wrote:
> On Mon, Feb 8, 2016 at 10:30 AM, Jonathan Wakely
> wrote:
>> On 8 February 2016 at 18:26, Jonathan Wakely wrote:
>>> On 8 February 2016 at 17:58, H.J. Lu wrote:
On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely
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?
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 10:46 AM, Jonathan Wakely wrote:
> On 8 February 2016 at 18:31, H.J. Lu wrote:
>> On Mon, Feb 8, 2016 at 10:30 AM, Jonathan Wakely
>> wrote:
>>> On 8 February 2016 at 18:26, Jonathan Wakely wrote:
On 8 February 2016 at 17:58, H.J. Lu wrote:
> On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely
> 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.
Linux-abi group
Hi, I created a mailing list to discuss Linux specific,.processor independent modification and extension of generic System V Application Binary Interface: https://groups.google.com/d/forum/linux-abi I will start to document existing Linux extensions, like STT_GNU_IFUNC. I will propose some new extensions soon. -- H.J.
Re: Linux-abi group
* H. J. Lu: > I created a mailing list to discuss Linux specific,.processor independent > modification and extension of generic System V Application Binary Interface: > > https://groups.google.com/d/forum/linux-abi > > I will start to document existing Linux extensions, like STT_GNU_IFUNC. > I will propose some new extensions soon. Why can't you use the existing C++ ABI list? Is there no overlap at all? Florian
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
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.
Re: Linux-abi group
* H.J. Lu [2016-02-08 11:24:53 -0800]: > I created a mailing list to discuss Linux specific,.processor independent > modification and extension of generic System V Application Binary Interface: > > https://groups.google.com/d/forum/linux-abi > > I will start to document existing Linux extensions, like STT_GNU_IFUNC. > I will propose some new extensions soon. > seems to require a registered email address at google. (and the archive does not work from any console based browser or using direct http get tools.) the kernel seems to have a lot of mailing lists, may be they can handle this list too? thanks
Re: Linux-abi group
On Mon, Feb 8, 2016 at 11:32 AM, Florian Weimer wrote: > * H. J. Lu: > >> I created a mailing list to discuss Linux specific,.processor independent >> modification and extension of generic System V Application Binary Interface: >> >> https://groups.google.com/d/forum/linux-abi >> >> I will start to document existing Linux extensions, like STT_GNU_IFUNC. >> I will propose some new extensions soon. > > Why can't you use the existing C++ ABI list? Is there no overlap at > all? > : I wasn't referring to empty class https://gcc.gnu.org/ml/gcc/2016-02/msg00057.html I was referring to program properties: https://groups.google.com/forum/#!topic/generic-abi/fyIXttIsYc8 -- H.J.
Re: Linux-abi group
On Mon, Feb 8, 2016 at 11:33 AM, Szabolcs Nagy wrote: > * H.J. Lu [2016-02-08 11:24:53 -0800]: >> I created a mailing list to discuss Linux specific,.processor independent >> modification and extension of generic System V Application Binary Interface: >> >> https://groups.google.com/d/forum/linux-abi >> >> I will start to document existing Linux extensions, like STT_GNU_IFUNC. >> I will propose some new extensions soon. >> > > seems to require a registered email address at google. > (and the archive does not work from any console based browser > or using direct http get tools.) Do you want me to add you? > the kernel seems to have a lot of mailing lists, may be > they can handle this list too? > > thanks It is used to discuss more tool-oriented extensions than the kernel-oriented ones, like STT_GNU_IFUNC which has nothing to do with kernel. -- H.J.
Re: Linux-abi group
* H. J. Lu: > On Mon, Feb 8, 2016 at 11:32 AM, Florian Weimer wrote: >> * H. J. Lu: >> >>> I created a mailing list to discuss Linux specific,.processor independent >>> modification and extension of generic System V Application Binary Interface: >>> >>> https://groups.google.com/d/forum/linux-abi >>> >>> I will start to document existing Linux extensions, like STT_GNU_IFUNC. >>> I will propose some new extensions soon. >> >> Why can't you use the existing C++ ABI list? Is there no overlap at >> all? >> > : > I wasn't referring to empty class > > https://gcc.gnu.org/ml/gcc/2016-02/msg00057.html But still there is going to be some overlap? > I was referring to program properties: > > https://groups.google.com/forum/#!topic/generic-abi/fyIXttIsYc8 This looks more like an ELF topic to me, not really ABI. Please discuss this on a GNU project list because it affects the entire GNU project. Florian
Re: Linux-abi group
On Mon, Feb 8, 2016 at 11:44 AM, Florian Weimer wrote: > * H. J. Lu: > >> On Mon, Feb 8, 2016 at 11:32 AM, Florian Weimer wrote: >>> * H. J. Lu: >>> I created a mailing list to discuss Linux specific,.processor independent modification and extension of generic System V Application Binary Interface: https://groups.google.com/d/forum/linux-abi I will start to document existing Linux extensions, like STT_GNU_IFUNC. I will propose some new extensions soon. >>> >>> Why can't you use the existing C++ ABI list? Is there no overlap at >>> all? >>> >> : >> I wasn't referring to empty class >> >> https://gcc.gnu.org/ml/gcc/2016-02/msg00057.html > > But still there is going to be some overlap? I was told that it didn't belong to C++ ABI. Please free feel to raise the this issue with C++ ABI group. >> I was referring to program properties: >> >> https://groups.google.com/forum/#!topic/generic-abi/fyIXttIsYc8 > > This looks more like an ELF topic to me, not really ABI. > > Please discuss this on a GNU project list because it affects the > entire GNU project. > gABI is ELF and affects all users, including GNU project, of gABI. Linux-abi discusses Linux-specific extensions to gABI. It is for tools like compilers, assembler, linker and run-time. It isn't appropriate for any GNU project list. -- H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely 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 c. An array of empty class types. 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. 4. No memory slot nor register should be used to pass or return an object of empty record. -- H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith wrote: > On Mon, Feb 8, 2016 at 12:05 PM, H.J. Lu wrote: >> >> On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely >> 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. -- H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu wrote: > > On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith wrote: > > On Mon, Feb 8, 2016 at 12:05 PM, H.J. Lu wrote: > >> > >> On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely > >> 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.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
Do we really need an 'empty type' special case? The x86_64 psABI already seems clear that empty types with size <= 16 are not passed at all. Following the algorithm in section 3.2.3, each eightbyte is classified as NO_CLASS, and thus is not passed. So the proposed change would only affect the behavior of types larger than 16 bytes that contain no data. It doesn't seem worth breaking ABI to more efficiently pass those. On Mon, Feb 8, 2016 at 2:35 PM, Richard Smith wrote: > On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu wrote: >> >> On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith wrote: >> > On Mon, Feb 8, 2016 at 12:05 PM, H.J. Lu wrote: >> >> >> >> On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely >> >> 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.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 2:35 PM, Richard Smith wrote: > On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu wrote: >> >> On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith wrote: >> > On Mon, Feb 8, 2016 at 12:05 PM, H.J. Lu wrote: >> >> >> >> On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely >> >> 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. 3. No memory slot nor register should be used to pass or return an object of empty type. -- H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 2:42 PM, Richard Smith wrote: > Do we really need an 'empty type' special case? > > The x86_64 psABI already seems clear that empty types with size <= 16 > are not passed at all. Following the algorithm in section 3.2.3, each > eightbyte is classified as NO_CLASS, and thus is not passed. So the > proposed change would only affect the behavior of types larger than 16 > bytes that contain no data. It doesn't seem worth breaking ABI to more > efficiently pass those. > Clang isn't consistent between ia32 and x86-64. GCC isn't compatible with clang. My proposal will make GCC and clang compatible. It also makes GCC and clang behave the same on both ia32 and x86-64. -- H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 2:46 PM, H.J. Lu wrote: > On Mon, Feb 8, 2016 at 2:35 PM, Richard Smith wrote: >> On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu wrote: >>> >>> On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith >>> wrote: >>> > On Mon, Feb 8, 2016 at 12:05 PM, H.J. Lu wrote: >>> >> >>> >> On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely >>> >> 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). > 3. No memory slot nor register should be used to pass or return an object > of empty type. > > > -- > H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 2:51 PM, Richard Smith wrote: > On Mon, Feb 8, 2016 at 2:46 PM, H.J. Lu wrote: >> On Mon, Feb 8, 2016 at 2:35 PM, Richard Smith wrote: >>> On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu wrote: On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith wrote: > On Mon, Feb 8, 2016 at 12:05 PM, H.J. Lu wrote: >> >> On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely >> 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.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 2:49 PM, H.J. Lu wrote: > On Mon, Feb 8, 2016 at 2:42 PM, Richard Smith wrote: >> Do we really need an 'empty type' special case? >> >> The x86_64 psABI already seems clear that empty types with size <= 16 >> are not passed at all. Following the algorithm in section 3.2.3, each >> eightbyte is classified as NO_CLASS, and thus is not passed. So the >> proposed change would only affect the behavior of types larger than 16 >> bytes that contain no data. It doesn't seem worth breaking ABI to more >> efficiently pass those. >> > > Clang isn't consistent between ia32 and x86-64. GCC isn't compatible > with clang. My proposal will make GCC and clang compatible. It also > makes GCC and clang behave the same on both ia32 and x86-64. OK, but if the ABI is already saying what we want, and the only problem is that GCC and Clang don't conform to the ABI in some cases, then we just need to fix the compilers and not the ABI. Which cases do we think the existing ABI rule misclassifies?
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 2:54 PM, H.J. Lu wrote: > On Mon, Feb 8, 2016 at 2:51 PM, Richard Smith wrote: >> On Mon, Feb 8, 2016 at 2:46 PM, H.J. Lu wrote: >>> On Mon, Feb 8, 2016 at 2:35 PM, Richard Smith wrote: On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu wrote: > > On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith > wrote: > > On Mon, Feb 8, 2016 at 12:05 PM, H.J. Lu wrote: > >> > >> On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely > >> > >> 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).
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 2:58 PM, Richard Smith wrote: > On Mon, Feb 8, 2016 at 2:54 PM, H.J. Lu wrote: >> On Mon, Feb 8, 2016 at 2:51 PM, Richard Smith wrote: >>> On Mon, Feb 8, 2016 at 2:46 PM, H.J. Lu wrote: On Mon, Feb 8, 2016 at 2:35 PM, Richard Smith wrote: > On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu wrote: >> >> On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith >> wrote: >> > On Mon, Feb 8, 2016 at 12:05 PM, H.J. Lu wrote: >> >> >> >> On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely >> >> >> >> 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.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 2:55 PM, Richard Smith wrote: > On Mon, Feb 8, 2016 at 2:49 PM, H.J. Lu wrote: >> On Mon, Feb 8, 2016 at 2:42 PM, Richard Smith wrote: >>> Do we really need an 'empty type' special case? >>> >>> The x86_64 psABI already seems clear that empty types with size <= 16 >>> are not passed at all. Following the algorithm in section 3.2.3, each >>> eightbyte is classified as NO_CLASS, and thus is not passed. So the >>> proposed change would only affect the behavior of types larger than 16 >>> bytes that contain no data. It doesn't seem worth breaking ABI to more >>> efficiently pass those. >>> >> >> Clang isn't consistent between ia32 and x86-64. GCC isn't compatible >> with clang. My proposal will make GCC and clang compatible. It also >> makes GCC and clang behave the same on both ia32 and x86-64. > > OK, but if the ABI is already saying what we want, and the only > problem is that GCC and Clang don't conform to the ABI in some cases, > then we just need to fix the compilers and not the ABI. Which cases do > we think the existing ABI rule misclassifies? I want to make it explicit in psABIs to avoid any possible confusion and x86-64 classification rules don't apply to ia32. -- H.J.
Re: Linux-abi group
On Mon, 8 Feb 2016, H.J. Lu wrote: > >> I was referring to program properties: > >> > >> https://groups.google.com/forum/#!topic/generic-abi/fyIXttIsYc8 > > > > This looks more like an ELF topic to me, not really ABI. > > > > Please discuss this on a GNU project list because it affects the > > entire GNU project. > > > > gABI is ELF and affects all users, including GNU project, of gABI. > Linux-abi discusses Linux-specific extensions to gABI. It is for tools > like compilers, assembler, linker and run-time. It isn't appropriate > for any GNU project list. I find it extremely unlikely that many well-thought-out extensions would be appropriate for GNU systems using the Linux kernel but not for GNU systems using Hurd or other kernels - the only such cases would be for things very closely related to kernel functionality. There is a strong presumption that toolchain configuration should apply to all GNU systems rather than being specific to GNU/Linux without good reason. -- Joseph S. Myers jos...@codesourcery.com
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 3:01 PM, H.J. Lu wrote: > On Mon, Feb 8, 2016 at 2:58 PM, Richard Smith wrote: >> On Mon, Feb 8, 2016 at 2:54 PM, H.J. Lu wrote: >>> On Mon, Feb 8, 2016 at 2:51 PM, Richard Smith wrote: On Mon, Feb 8, 2016 at 2:46 PM, H.J. Lu wrote: > On Mon, Feb 8, 2016 at 2:35 PM, Richard Smith > wrote: >> On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu wrote: >>> >>> On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith >>> wrote: >>> > On Mon, Feb 8, 2016 at 12:05 PM, H.J. Lu wrote: >>> >> >>> >> On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely >>> >> >>> >> 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? Yes, the C++ standard defines the term (as an object that is contained within another via member, base class, and array element relationships). The C standard uses it in 6.7.9 to mean the same thing (recursing into class and array elements) but doesn't provide a formal definition.
Re: Linux-abi group
On Mon, Feb 8, 2016 at 3:08 PM, Joseph Myers wrote: > On Mon, 8 Feb 2016, H.J. Lu wrote: > >> >> I was referring to program properties: >> >> >> >> https://groups.google.com/forum/#!topic/generic-abi/fyIXttIsYc8 >> > >> > This looks more like an ELF topic to me, not really ABI. >> > >> > Please discuss this on a GNU project list because it affects the >> > entire GNU project. >> > >> >> gABI is ELF and affects all users, including GNU project, of gABI. >> Linux-abi discusses Linux-specific extensions to gABI. It is for tools >> like compilers, assembler, linker and run-time. It isn't appropriate >> for any GNU project list. > > I find it extremely unlikely that many well-thought-out extensions would > be appropriate for GNU systems using the Linux kernel but not for GNU > systems using Hurd or other kernels - the only such cases would be for > things very closely related to kernel functionality. There is a strong > presumption that toolchain configuration should apply to all GNU systems > rather than being specific to GNU/Linux without good reason. > Most of extensions aren't Linux kernel specific. But some extensions will require kernel support to function properly. -- H.J.
