bug 3820, empty base & TYPE_NONCOPIED_PARTS

[Mark Mitchell]

--On Tuesday, July 31, 2001 04:37:33 PM +0100 Nathan Sidwell 
<nathan@codesourcery.com> wrote:

> Hi,
> There's a problem with empty bases, as shown by the attached test
> case.
>
> An empty class with no bases gets a single field appended to it, and
> included in TYPE_NONCOPIED_PARTS.

Ack, don't say that macro.  I battled with it before, and it wasn't
pretty.

TYPE_NONCOPIED_PARTS is designed to allow an optimization whereby
you memcpy most everything, but then restore a few bits you didn't
want to memcpy.  I think that is all very well, in theory, but not
worth it in practice, and the front-end or back-end could always
make this optimization anyway; if you are copying nine consecutive
fields, do a memcpy.

And the empty-base optimization stuff in the new ABI means that there
is much less empty junk to copy than there was in the old ABI.

So, I agree with your plan; fix copy-constructors and
assignment-operators to just not copy stuff they don't need, and
then lose this macro, or at least its uses in the C++ front-end.

> If we have a non-empty class that ends in an empty object, we don't
> allow that end padding to be overlaid by something else, when being
> used as a base of field of some other class - do we?

No.  I think we did, but I think I made us stop.  (Us being the ABI
committee.)

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