type layout bug, or not?

type layout bug, or not?

[Chris Lattner]

Consider this C++ example (I've annotated each class decl with the  
unit size of each structure):

struct A { virtual ~A(); };     // 4
struct B { virtual ~B(); };     // 4

struct X : virtual public A,
                 virtual public B {  // 8
};

struct Y : virtual public B { // 4
   virtual ~Y();
};

struct Z : virtual public X, public Y {   // 8
   Z();
};

Z::Z() {}


In this example, the DECL_SIZE_UNIT of "Z" is 8 bytes.  Here, the  
FIELD_DECL corresponding to it's Y superclass has an offset of 0  
bytes and size 4 bytes.

Confusingly (to me at least), the FIELD_DECL for the X superclass has  
an offset of 4 bytes and and a size of 8 bytes, which means that the  
end of the object is 12 bytes, despite the fact that Z has a  
DECL_SIZE_UNIT of 8 bytes.

Is this the intended layout of this structure?  What does it mean  
when a field runs off the end of the structure?  In this case, should  
I just ignore the type size and assume that the 8 bytes are  
dynamically there?

Thanks,

-Chris

Re: type layout bug, or not?

[Andrew Pinski]

On Feb 21, 2006, at 4:44 PM, Chris Lattner wrote:
>
> Is this the intended layout of this structure?  What does it mean when 
> a field runs off the end of the structure?  In this case, should I 
> just ignore the type size and assume that the 8 bytes are dynamically 
> there?

I wonder if this is the same problem as recorded as PR 22488.  To me it 
does sound
like the same issue.

Thanks,
Andrew Pinski

Re: type layout bug, or not?

[Richard Guenther]

On 2/21/06, Andrew Pinski <pinskia@physics.uc.edu> wrote:
>
> On Feb 21, 2006, at 4:44 PM, Chris Lattner wrote:
> >
> > Is this the intended layout of this structure?  What does it mean when
> > a field runs off the end of the structure?  In this case, should I
> > just ignore the type size and assume that the 8 bytes are dynamically
> > there?
>
> I wonder if this is the same problem as recorded as PR 22488.  To me it
> does sound
> like the same issue.

Which should remind the C++ folks that they promised to fix this for 4.2 :P

Richard.