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

[Mark Mitchell <mark@xxxxxxxxxxxxxxxx>]

Mark Mitchell wrote:
> Kerch Holt wrote:
>
> The question raised here was how an unnamed bitfield should be handled 
> in a non-POD.  (In a POD, the C++ ABI is clear -- follow the rules of 
> the C ABI.)
> > 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.
>
> Wow, I didn't realize an unnamed bitfield was not a member.
>
> > 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.
Since there was no further commentary, I checked in the change attached.

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

Index: abi.html
===================================================================
RCS file: /home/cvs/Repository/cxx-abi/abi.html,v
retrieving revision 1.79
diff -c -5 -p -r1.79 abi.html
*** abi.html	26 Oct 2004 01:10:01 -0000	1.79
--- abi.html	19 Nov 2004 07:47:44 -0000
*************** is not necessary.
*** 708,738 ****
  <p>
  <li> <h5> Allocation of Members Other Than Virtual Bases </h5>
  <p>
  For each data component D (first the primary base of C, if any, then
  the non-primary, non-virtual direct base classes in declaration order,
! then the non-static data members in declaration order), allocate as
! follows:
  
    <ol type=1>
  
    <p>
!   <li> If D is a bitfield, i.e. declared as "<code>T [b]: n;"</code>,
!        for some integral POD type T and bit count n:
  
         <p>
         There are two cases depending on <code>sizeof(T)</code>
         and <code>n</code>:
  
         <ol type=a>
         <p>
         <li>
         If <code>sizeof(T)*8 >= n</code>,
!        the bitfield is allocated as required by the underlying C psABI.
!        That is, it will be placed in the next available n bits,
!        subject to the constraint that it does not cross an alignment
!        boundary for type <code>T</code>.
  
         <p>
         If dsize(C) > 0, and the byte at offset dsize(C) - 1 is
         partially filled by a bitfield, and that bitfield is also a
         data member declared in C (but not in one of C's proper base
--- 708,737 ----
  <p>
  <li> <h5> Allocation of Members Other Than Virtual Bases </h5>
  <p>
  For each data component D (first the primary base of C, if any, then
  the non-primary, non-virtual direct base classes in declaration order,
! then the non-static data members and unnamed bitfields in declaration
! order), allocate as follows:
  
    <ol type=1>
  
    <p>
!   <li> If D is a (possibly unnamed) bitfield whose declared type is 
!        <code>T</code> and whose declared width is <code>n</code> bits:
  
         <p>
         There are two cases depending on <code>sizeof(T)</code>
         and <code>n</code>:
  
         <ol type=a>
         <p>
         <li>
         If <code>sizeof(T)*8 >= n</code>,
!        the bitfield is allocated as required by the underlying C psABI,
!        subject to the constraint that a bitfield is never placed in the 
!        tail padding of a base class of C.
  
         <p>
         If dsize(C) > 0, and the byte at offset dsize(C) - 1 is
         partially filled by a bitfield, and that bitfield is also a
         data member declared in C (but not in one of C's proper base
*************** unwind table location.
*** 4957,4966 ****
--- 4956,4969 ----
  <p>This version of this document is $Revision: 1.79 $.  No special
  significance should be attached to the form of the revision number; it
  is simply a identifying number.</p>
  
  <p>
+ <font color=blud>[041118]</font>
+ Clarify the layout of bitfields.
+ </p>
+ 
  <font color=blue>[041025]</font>
  Indicate that the TC1 definition of POD is intended in the section
  defining a &quot;POD for the purpose of layout&quot;.  Clearly
  indicate that an array whose elements are not PODs for the purpose of
  layout is itself not a POD for the purpose of layout.