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

John Buddery <jvb at cyberscience dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvb at cyberscience dot com

--- Comment #215 from John Buddery <jvb at cyberscience dot com> ---
I recently upgraded my hp-ix ia64 gcc build to 11.1.0, and I thought I'd share
what I did in case it's useful for anyone still following this thread.

I started with the patches in this thread, and soon got to the 21 bit
relocation errors.

Thanks to the excellent PCREL60B analysis above, I applied this simple edit to
binutils 2.36 (you have to enable obsoletes to get a build):

--- binutils-2.36/gas/config/tc-ia64.c  2021-01-09 10:47:33.000000000 +0000
+++ binutils-2.36-snake/gas/config/tc-ia64.c    2021-05-17 10:21:40.651307362
+0100
@@ -6892,7 +6892,13 @@
       for (j = 0; j < md.slot[curr].num_fixups; ++j)
        {
          ifix = md.slot[curr].fixup + j;
-         fix = fix_new_exp (frag_now, frag_now_fix () - 16 + i, 8,
+          
+          unsigned long where = frag_now_fix () - 16 + i;
+#ifdef TE_HPUX
+          if ( ifix->code == BFD_RELOC_IA64_PCREL60B ) where++;
+#endif
+                   
+         fix = fix_new_exp (frag_now, where, 8,
                             &ifix->expr, ifix->is_pcrel, ifix->code);
          fix->tc_fix_data.opnd = ifix->opnd;
          fix->fx_file = md.slot[curr].src_file;

This fixes, for HP only, the PCTEL60B offset to be what the HP linker expects.
I don't know if the same is appropriate for Linux ia-64 or not, as I don't have
access to that environment. I'll add that to the binutils bug report as well,
but I've included it here so people can find it for gcc more easily.

With the working as, I changed gcc to use brl instructions for calls, including
tail calls:

--- gcc-11.1.0/gcc/config/ia64/ia64.md  2021-04-27 11:00:13.000000000 +0100
+++ gcc-11.1.0-snake/gcc/config/ia64/ia64.md    2021-05-13 14:49:21.000000000
+0100
@@ -4410,7 +4410,9 @@
         (const_int 0))
    (clobber (match_operand:DI 1 "register_operand" "=b,b"))]
   ""
-  "br.call%+.many %1 = %0"
+  "@
+   br.call%+.many %1 = %0
+   brl.call%+.many %1 = %0"
   [(set_attr "itanium_class" "br,scall")])

 (define_insn "call_value_nogp"
@@ -4419,14 +4421,18 @@
              (const_int 0)))
    (clobber (match_operand:DI 2 "register_operand" "=b,b"))]
   ""
-  "br.call%+.many %2 = %1"
+  "@
+   br.call%+.many %2 = %1
+   brl.call%+.many %2 = %1"
   [(set_attr "itanium_class" "br,scall")])

 (define_insn "sibcall_nogp"
   [(call (mem:DI (match_operand:DI 0 "call_operand" "?b,s"))
         (const_int 0))]
   ""
-  "br%+.many %0"
+  "@
+   br%+.many %0
+   brl%+.many %0"
   [(set_attr "itanium_class" "br,scall")])

 (define_insn "call_gp"

You have to be careful only to use brl on immediate calls, the assembler does
not accept brl with registers.

The above unconditionally uses brl - on hp-ux and other platforms. This would
work very badly (if at all) on an Itanium 1 (but I'm not sure they are still
around), and is slightly less efficient even on Itanium 2. So, possibly this
should be more limited, maybe using -mlong-call as requesting in Bug 20819 ?

Anyway, with the assembler patch and the brl patch, along with the other
patches in this thread, gcc 11.1.0 will successfully bootstrap in both 32 and
64 bits, and seems to work well - I've built a large 64 bit project with no
problems so far.

There are a lot of fails from the testsuite, but I suspect that's normal for
this os (I'll post results to the testresults list).

---
John

Reply via email to