I suppose ldso/ldso/dl-elf.c:803 is an asm() statement.  How does it look like?
Can you attach preprocessed source?

Created attachment 14941 [details]
Preprocessed source of ldso.c

(In reply to comment #1)
> I suppose ldso/ldso/dl-elf.c:803 is an asm() statement.  How does it look like?
> Can you attach preprocessed source?
> 

No, dl-elf.c:803 is the closing of _dl_dprintf, preprocessed source as required with -save-temps attached.

*** Bug 34807 has been marked as a duplicate of this bug. ***

Created attachment 14973 [details]
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.

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

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

Since this doesn't seem to be an issue on current trunk (4.8), can we close this PR?

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

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

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);
 }

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

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

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

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