This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: attribute "unpadded"

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      
CodeSourcery, LLC  

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]