bug 3820, empty base & TYPE_NONCOPIED_PARTS
Tue Jul 31 09:38:00 GMT 2001
--On Tuesday, July 31, 2001 04:37:33 PM +0100 Nathan Sidwell
> There's a problem with empty bases, as shown by the attached test
> 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
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
Mark Mitchell email@example.com
CodeSourcery, LLC http://www.codesourcery.com
More information about the Gcc-bugs