MIPS divide problem?

MIPS divide problem?

[jch50]

Sorry in advance if this is the wrong list for this.  

I'm not sure if this is a bug or if I'm just missing something obvious...
I'm using gcc 3.3.1, newlib 1.11.0, and binutils-2.14 and cross-compiling for mips.  In the function udivdi3 (libgcc2.c), the following code is generated (I 
believe this is from the ___udiv_qrnnd_c macro in longlong.h):


9fc00cc0:	0147001b 	divu	zero,t2,a3
9fc00cc4:	00cc3021 	addu	a2,a2,t4
9fc00cc8:	00cc102b 	sltu	v0,a2,t4
9fc00ccc:	14400006 	bnez	v0,9fc00ce8 <__udivdi3+0x104>
9fc00cd0:	2529ffff 	addiu	t1,t1,-1
9fc00cd4:	00c5102b 	sltu	v0,a2,a1
9fc00cd8:	10400003 	beqz	v0,9fc00ce8 <__udivdi3+0x104>
9fc00cdc:	00000000 	nop
9fc00ce0:	2529ffff 	addiu	t1,t1,-1
9fc00ce4:	00cc3021 	addu	a2,a2,t4
9fc00ce8:	00c53023 	subu	a2,a2,a1
9fc00cec:	00c7001b 	divu	zero,a2,a3
9fc00cf0:	31e4ffff 	andi	a0,t7,0xffff

This seems a bit strange, as the results from the first divu instruction never
seem to be accessed.  I'm not sure what the behaviour of a "normal" mips core
is when this sequence is encountered (two consecutive divides without an intervening mflo/mfhi), but it does seem to cause trouble on the derivative we're using if the second divu is started before the first one completes (as is
the case here).
For reference, binutils was configured with "--target=mips-elf", gcc was
configured with "--target=mips-elf --enable-languages=c,c++ --with-gnu-as".

Thanks,
-Chris

Re: MIPS divide problem?

[Jim Wilson]

jch50@comcast.net wrote:
> This seems a bit strange, as the results from the first divu instruction never
> seem to be accessed.

You probably should submit a bug report into our bugzilla database. 
This looks like either a gcc bug, or maybe a gcc/gas disagreement on 
which divide instructions to use.  See
	http://gcc.gnu.org/bugs.html
for info reporting bugs.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com