This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/34777] uClibc-0.9.29 compilation error for sh4 arch with gcc-4.x
- From: "olegendo at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 16 Oct 2012 00:58:27 +0000
- Subject: [Bug target/34777] uClibc-0.9.29 compilation error for sh4 arch with gcc-4.x
- Auto-submitted: auto-generated
- References: <bug-34777-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34777
--- Comment #11 from Oleg Endo <olegendo at gcc dot gnu.org> 2012-10-16 00:58:27 UTC ---
The following...
Index: gcc/config/sh/sh.c
===================================================================
--- gcc/config/sh/sh.c (revision 192482)
+++ gcc/config/sh/sh.c (working copy)
@@ -10527,6 +10527,15 @@
}
}
+ if (GET_CODE (*p) == PLUS && REG_P (XEXP (*p, 0)) && REG_P (XEXP (*p, 1))
+ && REGNO (XEXP (*p, 0)) != R0_REG)
+ {
+ *p = gen_rtx_PLUS (Pmode, XEXP (*p, 0), XEXP (*p, 1));
+ push_reload (*p, NULL_RTX, p, NULL, BASE_REG_CLASS, Pmode, VOIDmode, 0,
0,
+ opnum, type);
+ return true;
+ }
+
/* We must re-recognize what we created before. */
if (GET_CODE (*p) == PLUS
&& (mode_sz == 4 || mode_sz == 8)
seems to fix the test case of PR 34807. However, I've not tested it any
further and probably the fix is incomplete and works only for mem loads and not
stores.
In fact it can be broken again quite easily by inserting another insn that
requires R0 (tst #imm,r0 in this case):
int glob, glob1;
static int _dl_mmap (int xx)
{
register int __sc0 __asm__ ("r0") = glob1;
register int __sc1 __asm__ ("r1") = glob;
if (xx & 3)
__asm__ ("trapa %1 " : "=z" (__sc0) : "i" (0x10), "0" (__sc0), "r"
(__sc1));
return (__sc0);
}
void _start(int xx)
{
static int buf;
buf = _dl_mmap(xx);
}