This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: bug 3820, empty base & TYPE_NONCOPIED_PARTS
- To: Nathan Sidwell <nathan at codesourcery dot com>, "gcc-bugs at gcc dot gnu dot org" <gcc-bugs at gcc dot gnu dot org>
- Subject: Re: bug 3820, empty base & TYPE_NONCOPIED_PARTS
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Tue, 31 Jul 2001 09:37:27 -0700
- cc: "jason at redhat dot com" <jason at redhat dot com>
--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