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]

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


------- 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


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