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

[Mark Mitchell <mark@xxxxxxxxxxxxxxxx>]

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.
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.
Yan, are you using PowerPC instead of IA32?

Thanks,

--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@xxxxxxxxxxxxxxxx