Bug 43744 - SH: Error: pcrel too far
Summary: SH: Error: pcrel too far
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.4.3
: P4 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-13 06:10 UTC by Nobuhiro Iwamatsu
Modified: 2014-09-23 18:50 UTC (History)
6 users (show)

See Also:
Host:
Target: sh4-unknown-linux-gnu
Build:
Known to work: 4.3.4, 4.5.0, 4.6.0
Known to fail: 4.4.3
Last reconfirmed: 2010-04-13 06:34:52


Attachments
source code that can reproduce problem (47.18 KB, text/plain)
2010-04-13 06:12 UTC, Nobuhiro Iwamatsu
Details
A bit reduced test case (1.86 KB, text/plain)
2010-04-16 22:34 UTC, Kazumoto Kojima
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nobuhiro Iwamatsu 2010-04-13 06:10:20 UTC
$ gcc-4.4 -c  -D_GNU_SOURCE -D_REENTRANT  -Wall -g -O2 -fPIC -DPIC db4.8-x.c
../dist/../lock/lock_deadlock.c: In function '__lock_detect':
../dist/../lock/lock_deadlock.c:123: warning: 'idmap' may be used uninitialized in this function
../dist/../lock/lock_deadlock.c:124: warning: 'bitmap' may be used uninitialized in this function
../dist/../lock/lock_deadlock.c:125: warning: 'nalloc' may be used uninitialized in this function
../dist/../lock/lock_deadlock.c:125: warning: 'nlockers' may be used uninitialized in this function
/tmp/cc8awAVe.s: Assembler messages:
/tmp/cc8awAVe.s:3023: Error: pcrel too far

gcc-4.1 and gcc-4.3 work fine.

$ gcc-4.4 -v
Using built-in specs.
Target: sh4-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.3-7' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc --with-multilib-list=m4,m4-nofpu --with-cpu=sh4 --enable-checking=release --build=sh4-linux-gnu --host=sh4-linux-gnu --target=sh4-linux-gnu
Thread model: posix
gcc version 4.4.3 (Debian 4.4.3-7)

 gcc-4.4 (4.4.3-7) unstable; urgency=low
 .
   * Update to SVN 20100401 from the gcc-4_4-branch (r157925).
     - Fix PR libfortran/43517, PR tree-optimization/43528, PR target/43524,
       PR middle-end/43600, PR other/43562, PR target/39254,
       PR target/42113, PR c/43381, PR c++/41185, PR c++/41786,
       PR fortran/43409, PR fortran/43409, PR libfortran/43265,
       PR fortran/43551, PR libfortran/43605.
Comment 1 Nobuhiro Iwamatsu 2010-04-13 06:12:42 UTC
Created attachment 20376 [details]
source code that can reproduce problem

This is the source code that can reproduce a problem.
Comment 2 Kazumoto Kojima 2010-04-13 06:34:52 UTC
Confirmd.
Comment 3 Kazumoto Kojima 2010-04-13 06:56:22 UTC
Looks that Christian's patch pic-cp.patch

http://gcc.gnu.org/bugzilla/attachment.cgi?id=19794

in PR target/42841 can fix the problem.  Could you
please try it?
Comment 4 Nobuhiro Iwamatsu 2010-04-13 08:09:01 UTC
Hi,
(In reply to comment #3)
> Looks that Christian's patch pic-cp.patch
> 
> http://gcc.gnu.org/bugzilla/attachment.cgi?id=19794
> 
> in PR target/42841 can fix the problem.  Could you
> please try it?
> 
I confirmed that this problem was revised.

Do you have the plan applying this patch?

Comment 5 Richard Biener 2010-04-13 10:29:40 UTC

*** This bug has been marked as a duplicate of 42841 ***
Comment 6 Kazumoto Kojima 2010-04-15 11:55:13 UTC
I've tried 4.4 head & 42841 pic-cp.patch and got "pcrel too far"
for the test case db4.8-x.c.  So unfortunately, there is still
a different issue from 42841.  I'd like to reopen this bug.
Comment 7 Kazumoto Kojima 2010-04-16 22:34:07 UTC
Created attachment 20404 [details]
A bit reduced test case

It seems that we see a yet another corner case for find_barrier.
Also it looks latent on the trunk and 4.5.  Here is what is going
on, I guess.

For PIC, sh.c:fixup_mova replaces casesi_worker_1 insn with
casesi_worker_2 insn and a constant table entry is added to
a constant pool.  In the problematic case, find_barrier inserts
this constant pool in the middle of insns for casesi_worker_2.
Then the constant pool including the above constant table entry
is put before some of those insns.
This results a code sequence like

	mov.l	.L94,r0		! insn for casesi_worker_2
	...
CP:
	.long	bar
	...
.L94:
	.long	.L24-.L86
	.align 5
.L87:
	add	r0,r1		! insn for casesi_worker_2
	mova	.L86,r0		! insn for casesi_worker_2
	mov.b	@(r0,r1),r1	! insn for casesi_worker_2

	...
.L24:
	.byte	.L22-.L25
	.byte	.L23-.L25
	...

otherCP:
.L86:

which looks unexpected to the range computation in find_barrier.
It seems that the constant entry .long .L24-.L86 was assumed to
be put after the label .L86.  The patch below is an experimental
one to avoid the issue, though there would be better ways.

--- ORIG/gcc-4_4-branch/gcc/config/sh/sh.c	2010-04-15 19:59:21.000000000 +0900
+++ gcc-4_4-branch/gcc/config/sh/sh.c	2010-04-16 19:46:26.000000000 +0900
@@ -3884,6 +3884,7 @@ find_barrier (int num_mova, rtx mova, rt
   int si_limit;
   int hi_limit;
   rtx orig = from;
+  rtx last_symoff = NULL_RTX;
 
   /* For HImode: range is 510, add 4 because pc counts from address of
      second instruction after this one, subtract 2 for the jump instruction
@@ -4013,8 +4014,17 @@ find_barrier (int num_mova, rtx mova, rt
 
       if (mova_p (from))
 	{
+	  rtx src;
+
 	  switch (untangle_mova (&num_mova, &mova, from))
 	    {
+	      case 1:
+		src = SET_SRC (PATTERN (from));
+		if (GET_CODE (src) == CONST
+		    && GET_CODE (XEXP (src, 0)) == UNSPEC
+		    && XINT (XEXP (src, 0), 1) == UNSPEC_SYMOFF)
+		  last_symoff = from;
+		break;
 	      case 0:	return find_barrier (0, 0, mova);
 	      case 2:
 		{
@@ -4120,6 +4130,9 @@ find_barrier (int num_mova, rtx mova, rt
 	 so we'll make one.  */
       rtx label = gen_label_rtx ();
 
+      if (last_symoff)
+	from = last_symoff;
+
       /* If we exceeded the range, then we must back up over the last
 	 instruction we looked at.  Otherwise, we just need to undo the
 	 NEXT_INSN at the end of the loop.  */
Comment 8 Kazumoto Kojima 2010-04-22 22:03:10 UTC
Subject: Bug 43744

Author: kkojima
Date: Thu Apr 22 22:02:55 2010
New Revision: 158655

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158655
Log:
	PR target/43744
	* config/sh/sh.c (find_barrier): Don't emit a constant pool
	in the middle of insns for casesi_worker_2.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/sh/sh.c

Comment 9 Kazumoto Kojima 2010-05-05 22:12:30 UTC
Subject: Bug 43744

Author: kkojima
Date: Wed May  5 22:12:17 2010
New Revision: 159087

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159087
Log:
	Backport from mainline:
	2010-04-22  Kaz Kojima  <kkojima@gcc.gnu.org>

	PR target/43744
	* config/sh/sh.c (find_barrier): Don't emit a constant pool
	in the middle of insns for casesi_worker_2.


Modified:
    branches/gcc-4_5-branch/gcc/ChangeLog
    branches/gcc-4_5-branch/gcc/config/sh/sh.c

Comment 10 Kazumoto Kojima 2010-05-05 22:28:08 UTC
Subject: Bug 43744

Author: kkojima
Date: Wed May  5 22:27:57 2010
New Revision: 159088

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159088
Log:
	Backport from mainline:
	2010-04-22  Kaz Kojima  <kkojima@gcc.gnu.org>

	PR target/43744
	* config/sh/sh.c (find_barrier): Don't emit a constant pool
	in the middle of insns for casesi_worker_2.


Modified:
    branches/gcc-4_4-branch/gcc/ChangeLog
    branches/gcc-4_4-branch/gcc/config/sh/sh.c

Comment 11 Kazumoto Kojima 2010-05-05 22:46:20 UTC
Fixed.
Comment 12 John Paul Adrian Glaubitz 2014-08-29 20:04:27 UTC
I'm seeing this issue again when compiling binutils-2.24.51.20140818 with gcc-4.9.1, but I am not sure whether the issues are related.

The tail of the build log is:

/bin/sh ./libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../opcodes  -I. -I../../opcodes -I../bfd -I../../opcodes/../include -I../../opcodes/../bfd    -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -g -O2 -MT hppa-dis.lo -MD -MP -MF .deps/hppa-dis.Tpo -c -o hppa-dis.lo ../../opcodes/hppa-dis.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../opcodes -I. -I../../opcodes -I../bfd -I../../opcodes/../include -I../../opcodes/../bfd -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -g -O2 -MT hppa-dis.lo -MD -MP -MF .deps/hppa-dis.Tpo -c ../../opcodes/hppa-dis.c  -fPIC -DPIC -o .libs/hppa-dis.o
/tmp/ccZrwibi.s: Assembler messages:
/tmp/ccZrwibi.s:1903: Error: pcrel too far
make[5]: *** [hppa-dis.lo] Error 1

The full buildlog can be found here [1].

Cheers,
Adrian

> [1] http://buildd.debian-ports.org/status/fetch.php?pkg=binutils&arch=sh4&ver=2.24.51.20140818-1&stamp=1408638991
Comment 13 Kazumoto Kojima 2014-08-30 00:22:38 UTC
(In reply to John Paul Adrian Glaubitz from comment #12)
> I'm seeing this issue again when compiling binutils-2.24.51.20140818 with
> gcc-4.9.1, but I am not sure whether the issues are related.

I can't reproduce it in my environment.  Could you please
attach the preprocessed .i file for the problematic case?
Comment 14 John Paul Adrian Glaubitz 2014-08-30 05:01:18 UTC
Hi Kazumoto!

(In reply to Kazumoto Kojima from comment #13)
> (In reply to John Paul Adrian Glaubitz from comment #12)
> > I'm seeing this issue again when compiling binutils-2.24.51.20140818 with
> > gcc-4.9.1, but I am not sure whether the issues are related.
> 
> I can't reproduce it in my environment.  Could you please
> attach the preprocessed .i file for the problematic case?

Thanks a lot for your quick reply. I will do a manual rebuild as soon as possible and include the "--save-temps" flag to gcc to produce the .i file(s) you requested.

I am currently at DebConf, so my time is a bit short, but I will get back to you as soon as possible, around next week.

Cheers,
Adrian
Comment 15 John Paul Adrian Glaubitz 2014-09-23 18:50:18 UTC
Hmm, so for whatever reason, the problem does not occur again anymore and binutils just builds fine [1].

I did not upgrade the compiler, however it might be that the any dependencies were updated before the second (automated) build attempt.

Will keep an eye on the problem.

Adrian

> [1] http://buildd.debian-ports.org/status/fetch.php?pkg=binutils&arch=sh4&ver=2.24.51.20140918-1&stamp=1411252127