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

[Kerch Holt]

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))