[Bug target/34777] uClibc-0.9.29 compilation error for sh4 arch with gcc-4.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34777 --- Comment #15 from Eric Gallager --- (In reply to Oleg Endo from comment #14) > (In reply to Eric Gallager from comment #13) > > > > > > I've tried that test case with the sh-lra branch and the problems seem to > > > be > > > gone. > > > > So is this FIXED yet then? > > LRA is not enabled by default on SH, so I'd say no, not fixed yet. Please > leave open. OK, please remember to come back to this if/when LRA is ever the default on SH then.
[Bug target/34777] uClibc-0.9.29 compilation error for sh4 arch with gcc-4.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34777 --- Comment #14 from Oleg Endo --- (In reply to Eric Gallager from comment #13) > > > > I've tried that test case with the sh-lra branch and the problems seem to be > > gone. > > So is this FIXED yet then? LRA is not enabled by default on SH, so I'd say no, not fixed yet. Please leave open.
[Bug target/34777] uClibc-0.9.29 compilation error for sh4 arch with gcc-4.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34777
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment #13 from Eric Gallager ---
(In reply to Oleg Endo from comment #12)
> (In reply to Oleg Endo from comment #11)
> >
> > 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);
> > }
>
> I've tried that test case with the sh-lra branch and the problems seem to be
> gone.
So is this FIXED yet then?
[Bug target/34777] uClibc-0.9.29 compilation error for sh4 arch with gcc-4.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34777
Oleg Endo changed:
What|Removed |Added
Depends on||55212
--- Comment #12 from Oleg Endo ---
(In reply to Oleg Endo from comment #11)
>
> 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);
> }
I've tried that test case with the sh-lra branch and the problems seem to be
gone.
[Bug target/34777] uClibc-0.9.29 compilation error for sh4 arch with gcc-4.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34777
--- Comment #11 from Oleg Endo 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);
}
[Bug target/34777] uClibc-0.9.29 compilation error for sh4 arch with gcc-4.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34777 --- Comment #10 from Oleg Endo 2012-10-16 00:17:41 UTC --- (In reply to comment #9) > (In reply to comment #8) > > Since this doesn't seem to be an issue on current trunk (4.8), can we close > > this PR? > > The test case in PR 34807 which is marked as a duplicate of this PR > still ICEs on trunk in the similar way. Oh, I see. I'm not sure, could it be related to the (still existing) problem with some of the atomic patterns (which clobber R0), as described here http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751#c28 ?
[Bug target/34777] uClibc-0.9.29 compilation error for sh4 arch with gcc-4.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34777 --- Comment #9 from Kazumoto Kojima 2012-10-15 23:04:13 UTC --- (In reply to comment #8) > Since this doesn't seem to be an issue on current trunk (4.8), can we close > this PR? The test case in PR 34807 which is marked as a duplicate of this PR still ICEs on trunk in the similar way.
[Bug target/34777] uClibc-0.9.29 compilation error for sh4 arch with gcc-4.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34777 --- Comment #8 from Oleg Endo 2012-10-15 22:09:34 UTC --- Since this doesn't seem to be an issue on current trunk (4.8), can we close this PR?
[Bug target/34777] uClibc-0.9.29 compilation error for sh4 arch with gcc-4.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34777 --- Comment #7 from Oleg Endo 2012-10-15 21:59:27 UTC --- Author: olegendo Date: Mon Oct 15 21:59:21 2012 New Revision: 192478 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192478 Log: PR target/34777 * gcc.target/sh/torture/sh-torture.exp: New. * gcc.target/sh/torture/pr34777.c: New. Added: trunk/gcc/testsuite/gcc.target/sh/torture/ trunk/gcc/testsuite/gcc.target/sh/torture/pr34777.c trunk/gcc/testsuite/gcc.target/sh/torture/sh-torture.exp Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/34777] uClibc-0.9.29 compilation error for sh4 arch with gcc-4.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34777 Oleg Endo changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #6 from Oleg Endo 2012-09-30 22:47:33 UTC --- (In reply to comment #5) > Created attachment 14973 [details] > reduced testcase > I have tried to reproduce the ICE with the reduced testcase on rev 191865 with the following options: -x c -m4 -mb -fschedule-insns -fPIC -mprefergot -x c -m4 -ml -fschedule-insns -fPIC -mprefergot and optimization levels -O0 -O1 -O2 -O3 -Os -Og. It seems the problem does not happen anymore.
[Bug target/34777] uClibc-0.9.29 compilation error for sh4 arch with gcc-4.x
-- kkojima at gcc dot gnu dot org changed: What|Removed |Added CC||kkojima at gcc dot gnu dot ||org Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-19 00:56:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34777
[Bug target/34777] uClibc-0.9.29 compilation error for sh4 arch with gcc-4.x
--- Comment #5 from kkojima at gcc dot gnu dot org 2008-01-19 00:54 ---
Created an attachment (id=14973)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14973&action=view)
reduced testcase
I think Richard's comment is the case. Here is a reduced testcase.
The PIC memory access on SH4 makes register pressure on R0 high
and sometimes can't use with asm register statement using R0.
It seems that there is no easy way to fix this issue. Currently,
it's a limitation of asm extensions on this target.
In the above testcase, the error will go away with adding
-fno-schedule-insns option, but the more complex cases like PR 34807
will fail even with that option. You could avoid this problem
completely with isolating PIC accesses and asm statements.
For example, if the above reduced testcase is changed so to use
noinline attribute, that program
static __attribute__ ((__noinline__)) void *
_dl_mmap (void * start, int length, int prot, int flags, int fd,
int offset)
{
register long __sc3 __asm__ ("r3") = 90;
register long __sc4 __asm__ ("r4") = (long) start;
register long __sc5 __asm__ ("r5") = (long) length;
register long __sc6 __asm__ ("r6") = (long) prot;
register long __sc7 __asm__ ("r7") = (long) flags;
register long __sc0 __asm__ ("r0") = (long) fd;
register long __sc1 __asm__ ("r1") = (long) offset;
__asm__ __volatile__ ("trapa %1"
: "=z" (__sc0)
: "i" (0x10 + 6), "0" (__sc0), "r" (__sc4),
"r" (__sc5), "r" (__sc6), "r" (__sc7),
"r" (__sc3), "r" (__sc1)
: "memory" );
}
extern int _dl_pagesize;
void _dl_dprintf(int fd, const char *fmt, ...)
{
static char *buf;
buf = _dl_mmap ((void *) 0, _dl_pagesize, 0x1 | 0x2, 0x02 | 0x20, -1, 0);
}
will never hit this problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34777
[Bug target/34777] uClibc-0.9.29 compilation error for sh4 arch with gcc-4.x
--- Comment #4 from kkojima at gcc dot gnu dot org 2008-01-19 00:50 --- *** Bug 34807 has been marked as a duplicate of this bug. *** -- kkojima at gcc dot gnu dot org changed: What|Removed |Added CC||chrbr at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34777
[Bug target/34777] uClibc-0.9.29 compilation error for sh4 arch with gcc-4.x
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34777
