2.4.II.2

[Jim Dehnert]

> From: Mark Mitchell <mark at codesourcery.com>
> 
> This section (on laying out bases/fields) is still not right in the
> case where the thing being laid out is a field.  Basically, this
> section doesn't take into account that for fields you lay out the
> virtual bases, too.

I've fixed this by adding a comment at the top of 2.4 saying that
nvsize=size and nvalign=align for data members.

> In particular, 
> 
>   Otherwise, if D is not an empty base class (including all data
>   members), start at offset dsize(C), incremented if necessary for
>   alignment to nvalign(type(D)) for base classes or to align(type(D))
>   for data members. Place D at this offset unless doing so would result
>   in two components (direct or indirect) of the same type having the
>   same offset. If such a component type conflict occurs, increment the
>   candidate offset by nvalign(type(D)), and try again, repeating until
>   success occurs (which will occur no later than sizeof(C) rounded up to
>   the required alignment).
> 
> In this paragraph, both occurrences of `nvalign' are wrong for fields;
> they should be `align' in that case.

Only the second is wrong (the first already distinguished data
members).  I made the second consistent with the first.
> 
>      Update sizeof(C) to max (sizeof(C), offset(D)+nvsize(D)). Update
>      align(C) to max (align(C), nvalign(D)). If D is a base class (not
>      empty in this case), update dsize(C) to offset(D)+nvsize(D). If D
>      is a data member, update dsize(C) to max (offset(D)+dsize(D),
>      offset(D)+1).
> 
> Similarly, the occurrences of `nvsize' in this section should be size
> in this case.  Perhaps we could parameterize this section by making
> `s' and `a' definitions at the beginning that are nvsize/sizeof and
> nvalign/align appropriately.

I fixed the align update (by distinguishing), and left the sizeof
update to depend on the first change at the beginning.  I don't think
it admits of much confusion -- you have to allocate the member with its
bases, and shouldn't even consider not including their size...  Let me
know if this isn't enough.

Jim

-	    Jim Dehnert		dehnert at sgi.com
				(650)933-4272