[Bug target/13309] New: Incorrect code generated for __udivdi3

[Bug target/13309] New: Incorrect code generated for __udivdi3

[jch50 at comcast dot net]

GCC 3.3.1 was configured as follows:
~/mips-tools0/gcc-3.3.1/configure --target=mips-elf
--prefix=/usr/local/tools/mips-elf --enable-languages=c,c++ --with-gnu-as
--with-gnu-ld --with-newlib
--with-gxx-include-dir=/usr/local/tools/mips-elf/include -v 2>&

Binutils 2.14 was configured as follows:
~/mips-tools0/binutils-2.14/configure --target=mips-elf
--prefix=/usr/local/tools/mips-elf

It appears that __udivdi3 (libgcc2.c) contains incorrect code.  Specifically,

mips-elf-objdump -D libgcc.a
....
....
  cc:	006b0018 	mult	v1,t3
  d0:	00002812 	mflo	a1
  d4:	00c5182b 	sltu	v1,a2,a1
  d8:	1060000a 	beqz	v1,104 <__udivdi3+0x104>
  dc:	0147001b 	divu	zero,t2,a3
  e0:	00cc3021 	addu	a2,a2,t4
  e4:	00cc102b 	sltu	v0,a2,t4
  e8:	14400006 	bnez	v0,104 <__udivdi3+0x104>
  ec:	2529ffff 	addiu	t1,t1,-1
  f0:	00c5102b 	sltu	v0,a2,a1
  f4:	10400003 	beqz	v0,104 <__udivdi3+0x104>
  f8:	00000000 	nop
  fc:	2529ffff 	addiu	t1,t1,-1
 100:	00cc3021 	addu	a2,a2,t4
 104:	00c53023 	subu	a2,a2,a1
 108:	00c7001b 	divu	zero,a2,a3
 10c:	31e4ffff 	andi	a0,t7,0xffff
 110:	14e00002 	bnez	a3,11c <__udivdi3+0x11c>
 114:	00000000 	nop
 118:	0007000d 	break	0x7
 11c:	00001812 	mflo	v1
 120:	00001010 	mfhi	v0

The results from the first divu are never accessed, and a second divu is issued
before the first one has completed.  This appears to cause problems for r3000.
The following code produces incorrect results:

externC void cyg_start( void )
{ 
    volatile unsigned long long a = 0x23e3;
    volatile unsigned long long b = 0x15;
    volatile unsigned long c;

    c = a/b;
}

mips-elf-gcc -c  -I/home/chouston/ecos-projects/test0/test0_install/include
-I/home/chouston/ecos/packages/hal/common/current
-I/home/chouston/ecos/packages/hal/common/current/src
-I/home/chouston/ecos/packages/hal/common/current/tests -I.
-I/home/chouston/ecos/packages/hal/common/current/tests/ -mips1 -EB -msoft-float
-Wall -Wpointer-arith -Wstrict-prototypes -Winline -Wundef  -g -O2
-ffunction-sections -fdata-sections  -fno-exceptions   -G0
-Wp,-MD,tests/context.tmp -o tests/context.o
/home/chouston/ecos/packages/hal/common/current/tests/context.c

-- 
           Summary: Incorrect code generated for __udivdi3
           Product: gcc
           Version: 3.3.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jch50 at comcast dot net
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux
  GCC host triplet: i686-pc-linux
GCC target triplet: mips-elf-unkown


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13309

[Bug target/13309] Incorrect code generated for __udivdi3 (MIPS)

[jch50 at comcast dot net]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Incorrect code generated for|Incorrect code generated for
                   |__udivdi3                   |__udivdi3 (MIPS)


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13309

[Bug target/13309] Incorrect code generated for __udivdi3 (really __udivmoddi4) (MIPS)

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
            Summary|Incorrect code generated for|Incorrect code generated for
                   |__udivdi3 (MIPS)            |__udivdi3 (really
                   |                            |__udivmoddi4) (MIPS)


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13309

[Bug target/13309] Incorrect code generated for __udivdi3 (really __udivmoddi4) (MIPS)

[dhazeghi at yahoo dot com]

------- Additional Comments From dhazeghi at yahoo dot com  2004-01-18 18:09 -------
Eric, would you mind commenting on the code in this bug? Is libgcc in fact wrong
here? Thanks.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |echristo at redhat dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13309

[Bug target/13309] Incorrect code generated for __udivdi3 (really __udivmoddi4) (MIPS)

[echristo at redhat dot com]

------- Additional Comments From echristo at redhat dot com  2004-02-23 23:23 -------
i haven't forgotten this.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13309

[Bug target/13309] Incorrect code generated for __udivdi3 (really __udivmoddi4) (MIPS)

[echristo at redhat dot com]

------- Additional Comments From echristo at redhat dot com  2004-04-02 09:39 -------
Richard was going to look at this.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rsandifo at redhat dot com
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13309

[Bug target/13309] Incorrect code generated for __udivdi3 (really __udivmoddi4) (MIPS)

[rsandifo at gcc dot gnu dot org]

------- Additional Comments From rsandifo at gcc dot gnu dot org  2004-04-03 15:19 -------
This is an effect of libgcc being compiled with -fnon-call-exceptions.
In a similar vein to your volatile example, the same thing can be seen with:

void f (int x, int y)
{
  g (x / y);
  g (x % y);
}

If you run GCC with -fexceptions -fnon-call-exceptions, it can reuse the
result of first division for the second call to g(), but it won't actually
delete the second division since it might trap.

This isn't really a bug, it's just that GCC has no workaround for this
particular hardware problem.

Which r3000 target are you using?  Is this behaviour documented somewhere,
such as in an r3000 errata?

I'm reclassifying this as an enhancement request to add -mfix-r3000,
(or whatever).  One less-than-optimal implementation for HEAD would
be to add "mflo $0" to the end of mips_output_division.  A more
intrusive alternative would be to add separate r3000 divmodsi3 and
udivmodsi3 patterns that assign directly to GPRs.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
             Status|ASSIGNED                    |SUSPENDED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13309

[Bug target/13309] Incorrect code generated for __udivdi3 (really __udivmoddi4) (MIPS)

[rsandifo at gcc dot gnu dot org]

------- Additional Comments From rsandifo at gcc dot gnu dot org  2004-04-03 15:20 -------
Bugzilla never quite does what I expect ;)

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |SUSPENDED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13309

[Bug target/13309] Incorrect code generated for __udivdi3 (really __udivmoddi4) (MIPS)

[rsandifo at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|rsandifo at redhat dot com  |unassigned at gcc dot gnu
                   |                            |dot org
             Status|SUSPENDED                   |NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13309

[Bug target/13309] Incorrect code generated for __udivdi3 (really __udivmoddi4) (MIPS)

[echristo at redhat dot com]

------- Additional Comments From echristo at redhat dot com  2005-04-05 21:26 -------
Richard,
I think we should probably close this one unless we actually get a chip part
that has this failing :)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13309

[Bug target/13309] Incorrect code generated for __udivdi3 (really __udivmoddi4) (MIPS)

[rsandifo at gcc dot gnu dot org]

------- Additional Comments From rsandifo at gcc dot gnu dot org  2005-04-06 06:56 -------
> Richard,
> I think we should probably close this one unless we actually get a chip part
> that has this failing :)

...or at least get some documentation about what the hardware
limitation actually is. ;)

I was keeping this open (but suspended) so that we could track
the fact that gcc doesn't work around this particular problem.
But I agree that there's not enough information here to be useful.

We can always reopen the PR if someone does provide the docs
(although we'd probably just suspend it again, unless someone's
actually volunteering to implement the workaround).

Richard


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|SUSPENDED                   |RESOLVED
         Resolution|                            |WORKSFORME


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13309