This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
MIPS divide problem?
- From: jch50 at comcast dot net
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 04 Dec 2003 00:54:57 +0000
- Subject: 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