This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/13309] Incorrect code generated for __udivdi3 (really __udivmoddi4) (MIPS)
- From: "rsandifo at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 3 Apr 2004 15:19:21 -0000
- Subject: [Bug target/13309] Incorrect code generated for __udivdi3 (really __udivmoddi4) (MIPS)
- References: <20031205002859.13309.jch50@comcast.net>
- Reply-to: gcc-bugzilla 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