Re: [cxx-abi-dev] question on the virtual base offset

[Kerch Holt <kerch@xxxxxxxxxx>]

Seems like this issue hasn't been resolved...

Mark Mitchell wrote:
> Nathan Sidwell wrote:
>
> > Yan Liu wrote:
> >
> > > I found that g++ 3.3, 3.4 and 3.5 have different class layout for the
> > > following testcase:
> > > struct A {char a;};
> > >
> > > struct B: virtual public A {};
> > >
> > > struct C:public B{
> > >   int c;
> > >   virtual void f() {};
> > > };
> > > struct D {
> > >         char d;
> > > };
> > > struct E {int:3;};
> > > struct F: public C, virtual E, public D {
> > >         char f1;
> > >         virtual void f(){}
> > > };
> > > int main()
> > > {F f;}
> > >
> > > Attached files are the class and vft  layout results with three g++
> > > compilers using -fdump-class-hierarchy option.
> > >
> > >
> > > (See attached file: temp4.g++35.class)(See attached file:
> > > temp4.g++33.class)(See attached file: temp4.C.g++34_32.class)
> > > According to the C++ ABI online document chapter 2.4
> > > (http://www.codesourcery.com/cxx-abi/abi.html).  After mapping the 
> > > virtual
> > > base class A while mapping of the most derived class F,  the 
> > > dsize(F)=11,
> > > size(F)=11, align(F)=4, and nvsize(E)=4, nvalign(E)=4.  So, when mapping
> > > virtual base class E, the next available bits are at offset 
> > > dsize(F)=11.  E
> > > should be put at offset(F) which is the dsize(F) =11, and the final 
> > > class
> > > size should be 12. To me, g++3.4 gives the most reasonable result, I 
> > > don't
> > > understand why g++3.5 put E at offset 12, and the final class size is 
> > > 16.
> > > Is it means that ABI has changed or just a gcc bug?
> > >
> > > Your kind help is highly appreciated. Thanks.
> >
> >
> > the layout 3.5 gives looks ok to me.  E requires 4 byte alignment, so
> > cannot be at 11.
>
> If E should have 4-byte alignment (as indicated above by "nvalign(E)"), 
> then I agree.
Since E only contains an "unnamed bitfield" which is not even considered
a member (see 9.6 P2) I think the nvalign(E) should be 1.

> Of course, independently of which choice is correct, we don't want G++ 
> changing the ABI without explicit use of -fabi-version.  However, I see 
> the size of F as 12 with both G++ 3.4.1 and the current mainline, on 
> i686-pc-linux-gnu.
Does this need extra wording in the ABI to deal with the special case
of unnamed bitfields? Perhaps alter 2.4 II 1. to say:
    If D is not an unnamed bitfield
        update align(C) to max(align(C),align(T))