Re: RFC: attribute "unpadded"

[Mark Mitchell <mark at codesourcery dot com>]

> Or perhaps you see the ABI creating intermediate types, such as
>
> 	struct __A { void *__vptr; char c; } attribute((unpadded));
> 	struct A { struct __A body; };
> 	struct B { struct __A base; char d; };
>
> In this modified form, A is correctly sized for an array,
> though __A is not.
Yes.  Most front ends (sample of 4) actually create both types, although
they do:

 struct A { void *__vptr; char c; };

rather than:

 struct A { struct __A body; }

I'm not sure if there's ever a case where that matters.

If there is a virtual base "V" then the full "A" looks like:

 struct A { void *__vptr; char c; struct __V vbase; };

Some front ends do this because their back ends expect all types to
be basically C types.

G++ doesn't actually create both types because we play other tricks; we
use DECL_SIZE to set the size of the fields corresponding to base classes
correctly (i.e., DECL_SIZE (field)) does not match
TYPE_SIZE (TREE_TYPE (field)).  Add we don't keep the FIELD_DECLs
for bases anyhow; we only use them to get the layout set up right.

This is part of why type-based alias analysis and C++ run into trouble;
traversing the FIELD_DECLs in a RECORD_TYPE created by the C++ front
end does not find you all of the subobjects.

--
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com