This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 3.2
- From: Jason Merrill <jason at redhat dot com>
- To: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>
- Cc: Mark Mitchell <mark at codesourcery dot com>, gcc at gcc dot gnu dot org,"Kevin B. Hendricks" <kevin dot hendricks at sympatico dot ca>,Jakub Jelinek <jakub at redhat dot com>, Jason Merrill <jason at redhat dot com>
- Date: Tue, 30 Jul 2002 00:32:14 +0100
- Subject: Re: GCC 3.2
- References: <40360000.1027723811@gandalf.codesourcery.com><200207271635.12319@enzo.bigblue.local>
On Sat, 27 Jul 2002 16:35:12 +0200, Franz Sirl <Franz.Sirl-kernel@lauterbach.com> wrote:
> Another thing, Kevin Hendricks, one of the OpenOffice developers, sent me a
> short test program with all the alignment stuff the OO people had to change
> between 2.9x and 3.x. Would some of the C++ people take a close look at this
> code? Note that the current ABI patches fixed already 2 problems the OO
> people had to workaround with gcc-3.1, so maybe the others are ABI bugs as
> well?
>
> And now with gcc-3.2:
>
> ### sizeof(C4) = 32 instead of expected 40!!!
> ### OFFSET_OF(C4, n4) = 20 instead of expected 24!!!
> ### OFFSET_OF(C4, d4) = 24 instead of expected 32!!!
This is not a bug. What's happening is that when we lay out C4, we
allocate n4 into the tail padding of C3. We can do this because C3 is not
a POD type; we just need to be careful not to copy the tail padding when we
assign to a C3. The ABI bug I fixed was that we were doing this with POD
bases as well, which is broken because POD classes must be compatible with
C code.
It's possible that we are copying the tail padding when assigning a C3; I'm
not seeing that, but am continuing to investigate. If so, that's a serious
bug, but fixing it will not impact the ABI. In other words, it can wait
for 3.2.1.
Jason