On 04/12/06 21:08, Otto Moerbeek wrote:
Hi,

This fixes a gcc code generation bug, demonstrated using -march=i686
-O2, but I suspect it can occur in other circumstances as well.

Yep, any architecture with and without -march=i686

The interesting thing is that the gcc people classified this as a m68k
bug (the gcc PR was for m68k), but the fix is not in target specific
code.

See <http://marc.theaimsgroup.com/?l=openbsd-misc&m=114419231323> for
the test program (and some noise) and

Some missching characters at the end of the link I presume:

http://marc.theaimsgroup.com/?l=openbsd-misc&m=11441923132379

+++chefren


<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10692>

So far I've done kernel builds and make builds using this diff on macppc
and i386. More testing (also on other gcc 3 platforms) appreciated.

        -Otto

Index: gcc/reload1.c
===================================================================
RCS file: /cvs/src/gnu/usr.bin/gcc/gcc/reload1.c,v
retrieving revision 1.3
diff -u -p -r1.3 reload1.c
--- gcc/reload1.c       25 Dec 2004 00:23:11 -0000      1.3
+++ gcc/reload1.c       11 Apr 2006 08:48:39 -0000
@@ -6923,6 +6923,10 @@ do_input_reload (chain, rl, j)
      actually no need to store the old value in it.  */
if (optimize
+      /* Only attempt this for input reloads; for RELOAD_OTHER we miss
+        that there may be multiple uses of the previous output reload.
+        Restricting to RELOAD_FOR_INPUT is mostly paranoia.  */
+      && rl->when_needed == RELOAD_FOR_INPUT
       && (reload_inherited[j] || reload_override_in[j])
       && rl->reg_rtx
       && GET_CODE (rl->reg_rtx) == REG

Reply via email to