PATCH: Define "POD for the purpose of layout"

[Mark Mitchell]

This patch implements the consensus that we need to define a notion of
"POD for the purpose of layout" that does not include PODs with
"overlong" bitfields.

I have comitted this change, but there is still a lingering issue:

  struct A { int i : 2048; };

  struct B { struct A a; };

Is B a POD for the purpose of layout?  

With the patch below, B *is* a POD for the purpose of layout, which is
plausible because the underlying C ABI does still explain how to lay
out B, given a layout for A.

It is unlikely that this distinction will make any difference on any
real system, but if people feel that B should be laid out according to
the C++ rules, rather than the C rules, we could make that change.

--
Mark Mitchell
CodeSourcery, LLC
mark at codesourcery.com

Index: abi.html
===================================================================
RCS file: /usr/local/Repository/cxx-abi/abi.html,v
retrieving revision 1.61
diff -c -5 -p -r1.61 abi.html
*** abi.html	16 Mar 2003 20:50:14 -0000	1.61
--- abi.html	18 May 2003 21:24:52 -0000
*************** A class that contains a virtual pointer,
*** 225,239 ****
  </ul>
  Such classes may be primary base classes even if virtual,
  sharing a virtual pointer with the derived class.
  
  <p>
! <dt> <i>primary base class</i> </dt>
  <dd>
! For a dynamic class,
! the unique base class (if any) with which it shares the virtual pointer
! at offset 0.
  
  <p>
  <dt> <i>secondary virtual table</i> </dt>
  <dd>
  The instance of a virtual table for a base class
--- 225,248 ----
  </ul>
  Such classes may be primary base classes even if virtual,
  sharing a virtual pointer with the derived class.
  
  <p>
! <a name="POD" />
! <dt> <i>POD for the purpose of layout</i><dt>
  <dd>
! A type is considered a POD for the purposes of layout if it is a POD
! type (in the sense of [basic.types]), and is not a POD-struct or
! POD-union (in the sense of [class]) with a bitfield member whose declared
! width is wider than the declared type of the bitfield
! </dd>
! </p>
! 
! <p>
! <dt> <i>primary base class</i> </dt> <dd> For a dynamic class, the
! unique base class (if any) with which it shares the virtual pointer at
! offset 0.
  
  <p>
  <dt> <i>secondary virtual table</i> </dt>
  <dd>
  The instance of a virtual table for a base class
*************** without virtual bases.
*** 537,551 ****
  <p> <hr> <p>
  <a name=pod>
  <h3> 2.2 POD Data Types </h3>
  
  <p>
! The size and alignment of C POD types is as specified by the base (C) ABI.
! Type bool has size and alignment 1.
! All of these types have data size and non-virtual size equal to their size.
! (We ignore tail padding for PODs because the Standard does not allow us
! to use it for anything else.)
  
  
  <p> <hr> <p>
  <a name=member-pointers></a>
  <h3> 2.3 Member Pointers </h3>
--- 546,562 ----
  <p> <hr> <p>
  <a name=pod>
  <h3> 2.2 POD Data Types </h3>
  
  <p>
! 
! The size and alignment of a type which is a <a href="#POD">POD for the
! purpose of layout<a> is as specified by the base (C) ABI.  Type bool
! has size and alignment 1.  All of these types have data size and
! non-virtual size equal to their size.  (We ignore tail padding for
! PODs because the Standard does not allow us to use it for anything
! else.)
  
  
  <p> <hr> <p>
  <a name=member-pointers></a>
  <h3> 2.3 Member Pointers </h3>
*************** of a class containing those two members,
*** 587,600 ****
  
  <p> <hr> <p>
  <a name=class-types>
  <h3> 2.4 Non-POD Class Types </h3>
  
! For non-POD class types C, assume that all component types
! (i.e. proper base classes and non-static data member types)
! have been laid out, defining size, data size, non-virtual size,
! alignment, and non-virtual alignment.
  (See the description of these terms in
  <a href=#general><b>General</b></a> above.)
  Further, assume for data members that nvsize==size, and nvalign==align.
  Layout (of type C) is done using the following procedure.
  
--- 598,613 ----
  
  <p> <hr> <p>
  <a name=class-types>
  <h3> 2.4 Non-POD Class Types </h3>
  
! For a class type C which is not a <a href="#POD">POD for the purpose
! of layout</a>, assume that all component types (i.e. proper base
! classes and non-static data member types) have been laid out, defining
! size, data size, non-virtual size, alignment, and non-virtual
! alignment.
! 
  (See the description of these terms in
  <a href=#general><b>General</b></a> above.)
  Further, assume for data members that nvsize==size, and nvalign==align.
  Layout (of type C) is done using the following procedure.
  
*************** and the full layout is equivalent to the
*** 868,878 ****
  </code></pre>
  
  <p>
  <li> <h5> Finalization </h5>
  <p>
! Round sizeof(C) up to a non-zero multiple of align(C).
  
  </ol>
  
  
  <p> <hr> <p>
--- 881,892 ----
  </code></pre>
  
  <p>
  <li> <h5> Finalization </h5>
  <p>
! Round sizeof(C) up to a non-zero multiple of align(C).  If C is a POD,
! but not a POD for the purpose of layout, set nvsize(C) = sizeof(C).
  
  </ol>
  
  
  <p> <hr> <p>
*************** unwind table location.
*** 4893,4902 ****
--- 4907,4920 ----
  
  <p> <hr> <p>
  <a name=revisions>
  <h2> Appendix R: Revision History </h2>
  <p> <hr> <p>
+ 
+ <p>
+ <font color=blue>[030518]</font>
+ Define "POD for the purpose of layout."
  
  <p>
  <font color=blue>[030316]</font>
  Add acknowledgements section.