[cxx-abi-dev] What is a POD? TC1 or first C++ Standard

[Mark Mitchell]

Nathan Sidwell wrote:

> Mark Mitchell wrote:
>
>> Dennis Handly wrote:
>>
>>>> GCC is not going to change back to the pre-TC1 definition, even for
>>>> return values
>>>>   
>>>
>>>
>>>
>>> What do you mean by "return values"?  I said it only affects layout.
>>> I first thought it also affects them but 3.1.4 Return Values, says 
>>> nothing
>>> about PODs.
>>>  
>>>
>> You are correct.  I thought it said that non-PODs could not be 
>> passed/returned in registers, but, in fact, it is more specific: it 
>> talks about non-trivial copy constructors and destructors.
>>
>> That makes things somewhat simpler.
>>
>> It seems to me that a POD with a pointer-to-member data member should 
>> not be a "POD for purpose of layout" because the layout of a "POD for 
>> the purpose of layout" is supposed to be whatever the C ABI would 
>> require -- and the C ABI does not specify the layout of a type 
>> containing a pointer-to-member.
>>
>> Now, the question is, when would this make a difference?  Dennis, can 
>> you post a small test case showing where the layout is different 
>> depending on whether you use the TC1 or pre-TC1 definition of POD?
>>
> I would have thought it'd change when the tail padding of such a class 
> could
> be used by a derived class. Something like,
>
> struct A {
>   int A::*ptr;
>   char f;
> };
>
> struct B : A {
>   char g;
> };
>
> Where is B::g placed?

Right, good.  Again, it looks like G++ 3.4 will treat A as a POD, 
following TC1, and will therefore not place B::g in the tail padding for A.

 From what Dennis, says that sounds like G++ and aCC are incompatible in 
this respect, but that G++ is probably compatible with (recent versions 
of) EDG.  I'm not sure what the most equitable way to resolve the 
ambiguity in the ABI specification is.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark at codesourcery.com