[cxx-abi-dev] PATCH: Define "POD for the purpose of layout"

Thu May 22 18:18:50 UTC 2003

That a POD type for the purposes of layout could contain a non-POD type
for the purposes of layout seems ugly.

More seriously this is a substantive change that produces a binary
incompatibility. Consider:

struct A { int i : 2048; short j};

struct B : public A {short k;}

With the revised rule, because A is a non-POD type for the purposes of
layout, its tail padding will be reused in the layout of B. Hence
sizeof(B)= 264 at present but will be 260 with the change to the ABI.

Here is a simple program that shows this in the context of current
compilers without this change - I turn A into an actual non-POD type to
simulate the ABI change so as to demonstrate the layout change. I used
the g++ from RHL9 in this test. (3.2.2) 

-------------------   testolbf.cpp  ------------------------------
#include <iostream>
#ifdef NONPOD
struct A0 {};
struct A : A0 {
#else
struct A {
#endif
    int i : 2048;
    short j;
    };

struct B : public A {
    short k;
    };

int main() {
    std::cout << "size of A is " << sizeof(A) << " size of B is " <<
sizeof(B) << std::endl;
    return 0;
    }
------------------------------------------------------------------------
g++ testolbf.cpp -DNONPOD
./a.out
size of A is 260 size of B is 260
------------------------------------------------------------------------
g++ testolbf.cpp
./a.out
size of A is 260 size of B is 264

We are also adding an extra burden for compiler writers in that they now
need to track both PODness and PODness for the purposes of layout.

I have not seen any discussion of the alternative of simply saying that
an overlong bitfield in a POD type is laid out according to the rules of
2.4 II. Is there a fatal flaw in that that I am failing to see?

-----Original Message-----
From: Mark Mitchell [mailto:mark at codesourcery.com] 
Sent: Sunday, May 18, 2003 2:27 PM
To: cxx-abi-dev at codesourcery.com
Subject: [cxx-abi-dev] PATCH: Define "POD for the purpose of layout"

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.

! <dt> primary base class </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.

! <a name="POD" />
! <dt> POD for the purpose of layout<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>
! 
! 
! 
! <dt> primary base class </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>

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

! 
! 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>General</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>General</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>

<li> <h5> Finalization </h5>
 
! 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.