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

[Mark Mitchell <mark@xxxxxxxxxxxxxxxx>]

Dennis Handly wrote:
> > From: Mark Mitchell <mark@xxxxxxxxxxxxxxxx>
> >
> > > 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))
>
> > I think the right thing to do is to handle unnamed bitfields as they 
> > would be handled in the underlying C ABI.  In some C ABIs, that results 
> > in an update to the alignment; in other C ABIs it does not.
>
> I think Kerch is saying that neither g++ 3.4 nor aC++ look at those
> unnamed bit fields and it's too late now.  In fact he said that 3.5
> looked at them and then somehow this change was backed out as a bad idea?
G++ behaves differently on different architectures; it follows the 
underlying C ABI.
Both of these types:

  struct A {
    char c;
    long long : 1;
  };

  struct B {
    B();
    char c;
    long long : 1;
  };

have size 2 with aCC and G++ 3.4.3 on IA64 HP-UX.  cc also gives A size 
2.  In other words, the fact that B is not a POD has no impact; both 
structures follow the underlying C ABI.
It happens that the C ABI on IA64 HP-UX does not affect the alignment 
for unnamed bitfields.  On other systems, it does affect the alignment.
> > 1) Revise the first paragraph of 2.4 II to say:
> > "then the non-static data members (including unnamed bitfields, although 
> > they are not members in ISO C++) in declaration order"
>
> And this wouldn't match.
Huh?

> > 3) Update 2.4.II.1.a to read:
> > Update align(C) to max (align(C), align(T))."
> Mark Mitchell
>
> I believe this is what we don't want if T is an unnamed bit field.
Well, OK, we can remove the example then.  The point is just that for 
bitfields whose declared width is no wider than the declared type, you 
use the C ABI rules.  The only interesting case from the point of view 
of the C++ ABI is when the declared width is wider than the underlying type.
--
Mark Mitchell
CodeSourcery, LLC
mark@xxxxxxxxxxxxxxxx