This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: GCC3.0-release and multiple inheritance
- To: Nathan Sidwell <nathan at codesourcery dot com>
- Subject: Re: GCC3.0-release and multiple inheritance
- From: Simon Gee <simong at oz dot agile dot tv>
- Date: Fri, 03 Aug 2001 11:48:43 +1000
- CC: gcc-bugs at gcc dot gnu dot org
- Organization: AgileTV Corporation Australia
- References: <3B68CBC7.457DC00B@oz.agile.tv> <3B69235B.B8510E04@codesourcery.com>
> Are you sure it was a released 3.0 (and not a prerelease)? I fixed
> a bug in the prerelease which had this signature. FWIW your sample
> works as expected on i686-pc-linux-gnu.
>
> Please verify that you are using a 3.0 release (or even better try the
> 3.0.1 prerelease from CVS). If the problem persists please file a GNATs
> bug report.
Hmm, I'm definitely compiling with GCC 3.0-release and compiling the testcase
with a compiler generated from the same code on an i386 gives the me correct
behaviour which led me to believe that I am looking at a machine dependent
issue.
Just as a follow up to the problem - there seems to be a problem with the
assembly that is produced by GCC with respect to the Bmethod destructor method
calls for the testcase. Two destructor calls are present for Bmethod (as is the
case with equivalent i386 assembly) however one of Bmethod's destructor calls
calls the the other of Bmethod's destructor calls, both of which also call the
destructor for class D thereby causing the former of Bmethod's destructor calls
to call the destructor for class D twice (-- the code included here,
http://gcc.gnu.org/ml/gcc-bugs/2001-08/msg00061.html , should clear up my
obscure references :) ). The reason this is functional with the i386 (from an
outputted assembly point of view) is due to the fact that in the equivalent
i386 assembly there are no calls made between the Bmethod destructor calls.
Since that was probably as clear as mud, a snippet of the MIPS assembly for the
failing case (minus the cerr's) with annotation pointing out the offending
calls is below.
$LFB18:
.ent _ZThn4_N1C7BmethodE1D
_ZThn4_N1C7BmethodE1D:
.frame $fp,56,$31 # vars= 16, regs= 4/0, args= 16, extra=
8
.mask 0xd0010000,-4
.fmask 0x00000000,0
.set noreorder
.cpload $25
.set reorder
subu $sp,$sp,56
.cprestore 16
$LCFI83:
# basic block 0
sw $31,52($sp)
$LCFI84:
sw $fp,48($sp)
$LCFI85:
sw $28,44($sp)
$LCFI86:
sw $16,40($sp)
$LCFI87:
move $fp,$sp
$LCFI88:
move $2,$4
sw $5,60($fp)
addu $2,$2,-4
move $4,$2
lw $5,60($fp)
$LEHB0:
la $25,_ZN1C7BmethodE1D
jal $31,$25 # <-- call to other destructor call for Bmethod
$LEHE0:
# basic block 1
lw $4,60($fp)
$LEHB1:
la $25,_ZN1DD1Ev
jal $31,$25 # <-- call to class D destructor -- we have now called
the class D destructor twice!
$LEHE1:
j $L65
<SNIP ... landing pad guff>
$L65:
# basic block 3
move $sp,$fp
lw $31,52($sp)
lw $fp,48($sp)
lw $16,40($sp)
addu $sp,$sp,56
j $31
.end _ZThn4_N1C7BmethodE1D
<SNIP>
$LFB19:
.ent _ZN1C7BmethodE1D
_ZN1C7BmethodE1D:
.frame $fp,48,$31 # vars= 8, regs= 3/0, args= 16, extra=
8 .mask 0xd0000000,-8
.fmask 0x00000000,0
.set noreorder
.cpload $25
.set reorder
subu $sp,$sp,48
.cprestore 16
$LCFI89:
# basic block 0
sw $31,40($sp)
$LCFI90:
sw $fp,36($sp)
$LCFI91:
sw $28,32($sp)
$LCFI92:
move $fp,$sp
$LCFI93:
move $2,$5
move $4,$2
la $25,_ZN1DD1Ev
jal $31,$25 # <-- call to class D destructor
move $sp,$fp
lw $31,40($sp)
lw $fp,36($sp)
addu $sp,$sp,48
j $31
.end _ZN1C7BmethodE1D