This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

MIPS divide problem?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]