[Bug target/43744] SH: Error: pcrel too far

[Bug target/43744] SH: Error: pcrel too far

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744

Kazumoto Kojima <kkojima at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |

--- Comment #13 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(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?

[Bug target/43744] SH: Error: pcrel too far

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744

--- Comment #14 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
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

[Bug target/43744] SH: Error: pcrel too far

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744

--- Comment #15 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
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

[Bug target/43744] SH: Error: pcrel too far

[giulio.benetti at benettiengineering dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744

Giulio Benetti <giulio.benetti at benettiengineering dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |giulio.benetti@benettiengin
                   |                            |eering.com

--- Comment #16 from Giulio Benetti <giulio.benetti at benettiengineering dot com> ---
When building package gnuradio on buildroot we get this error:
```
[ 82%] Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/correlate_access_code_bb_ts_impl.cc.o
/tmp/ccqgyzpD.s: Assembler messages:
/tmp/ccqgyzpD.s:4751: Error: pcrel too far
gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/build.make:312: recipe for target
'gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/dvb/dvb_bbheader_bb_impl.cc.o' failed
```

This happens with sh4 shared gcc 9/10/11.
I could not find a work-around for it.

To reproduce the bug:
'''
# git clone git://git.busybox.net/buildroot
# wget https://git.busybox.net/buildroot-test/tree/utils/br-reproduce-build

- modify BASE_GIT=... with your buildroot path in br-reproduce-build then:
# chmod a+x br-reproduce-build
# ./br-reproduce-build 1db6c59c98e3c09fa13277076ee2fbe7967f1f6b
'''

Preprocessed files follow.

[Bug target/43744] SH: Error: pcrel too far

[giulio.benetti at benettiengineering dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744

--- Comment #17 from Giulio Benetti <giulio.benetti at benettiengineering dot com> ---
Created attachment 51574
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51574&action=edit
Pre-processed dvb_bbheader_bb_impl.cc.cpp(dvb_bbheader_bb_impl.cc.ii)

[Bug target/43744] SH: Error: pcrel too far

[giulio.benetti at benettiengineering dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744

--- Comment #18 from Giulio Benetti <giulio.benetti at benettiengineering dot com> ---
Created attachment 51575
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51575&action=edit
Pre-processed dvb_bbheader_bb_impl.cc.cpp(dvb_bbheader_bb_impl.cc.s)

[Bug target/43744] SH: Error: pcrel too far

[giulio.benetti at benettiengineering dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744

--- Comment #19 from Giulio Benetti <giulio.benetti at benettiengineering dot com> ---
This bug still shows up with gcc 12.3.0. Can you please reopen it?

Thank you

[Bug target/43744] SH: Error: pcrel too far

[kkojima at gcc dot gnu dot org]

------- Comment #11 from kkojima at gcc dot gnu dot org  2010-05-05 22:46 -------
Fixed.


-- 

kkojima at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744

[Bug target/43744] SH: Error: pcrel too far

[kkojima at gcc dot gnu dot org]

------- Comment #10 from kkojima at gcc dot gnu dot org  2010-05-05 22:28 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744

[Bug target/43744] SH: Error: pcrel too far

[kkojima at gcc dot gnu dot org]

------- Comment #9 from kkojima at gcc dot gnu dot org  2010-05-05 22:12 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744

[Bug target/43744] SH: Error: pcrel too far

[kkojima at gcc dot gnu dot org]

------- Comment #8 from kkojima at gcc dot gnu dot org  2010-04-22 22:03 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744

[Bug target/43744] SH: Error: pcrel too far

[kkojima at gcc dot gnu dot org]

------- Comment #7 from kkojima at gcc dot gnu dot org  2010-04-16 22:34 -------
Created an attachment (id=20404)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20404&action=view)
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.  */


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744

[Bug target/43744] SH: Error: pcrel too far

[kkojima at gcc dot gnu dot org]

------- Comment #6 from kkojima at gcc dot gnu dot org  2010-04-15 11:55 -------
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.


-- 

kkojima at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|kkojima at rr dot iij4u dot |
                   |or dot jp                   |
             Status|RESOLVED                    |REOPENED
         Resolution|DUPLICATE                   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744

[Bug target/43744] SH: Error: pcrel too far

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2010-04-13 10:29 -------


*** This bug has been marked as a duplicate of 42841 ***


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744

[Bug target/43744] SH: Error: pcrel too far

[iwamatsu at nigauri dot org]

------- Comment #4 from iwamatsu at nigauri dot org  2010-04-13 08:09 -------
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?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744

[Bug target/43744] SH: Error: pcrel too far

[kkojima at gcc dot gnu dot org]

------- Comment #3 from kkojima at gcc dot gnu dot org  2010-04-13 06:56 -------
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?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744

[Bug target/43744] SH: Error: pcrel too far

[kkojima at gcc dot gnu dot org]

------- Comment #2 from kkojima at gcc dot gnu dot org  2010-04-13 06:34 -------
Confirmd.


-- 

kkojima at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
          Component|c                           |target
     Ever Confirmed|0                           |1
   GCC host triplet|sh4-unknown-linux-gnu       |
 GCC target triplet|                            |sh4-unknown-linux-gnu
      Known to fail|                            |4.4.3
      Known to work|                            |4.3.4 4.5.0 4.6.0
           Priority|P3                          |P4
   Last reconfirmed|0000-00-00 00:00:00         |2010-04-13 06:34:52
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744