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

[Mark Mitchell <mark@xxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxx