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
