public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jvb at cyberscience dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
Date: Mon, 17 May 2021 09:56:31 +0000	[thread overview]
Message-ID: <bug-61577-4-9NCORw2v8x@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-61577-4@http.gcc.gnu.org/bugzilla/>

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

  parent reply	other threads:[~2021-05-17  9:56 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-61577-4@http.gcc.gnu.org/bugzilla/>
2014-06-21 11:01 ` [Bug c++/61577] [4.9.0] " FBergemann at web dot de
2015-10-15 11:04 ` [Bug target/61577] " josephpattara at gmail dot com
2015-10-19 11:34 ` josephpattara at gmail dot com
2019-07-05  1:51 ` dave.anglin at bell dot net
2020-02-25 14:55 ` [Bug middle-end/61577] [4.9.0 Regression] " peter.bisroev at groundlabs dot com
2020-04-18  1:11 ` dave.anglin at bell dot net
2020-04-23 15:48 ` peter.bisroev at groundlabs dot com
2020-04-23 16:50 ` dave.anglin at bell dot net
2020-05-02  4:14 ` peter.bisroev at groundlabs dot com
2020-05-02 14:30 ` dave.anglin at bell dot net
2020-05-13 18:03 ` jared.martinsen at fiserv dot com
2020-05-13 19:04 ` dave.anglin at bell dot net
2021-04-16 21:30 ` pinskia at gcc dot gnu.org
2021-04-24 22:21 ` peter at int19h dot net
2021-05-17  9:56 ` jvb at cyberscience dot com [this message]
2021-05-19 16:23 ` dave.anglin at bell dot net
2021-05-20  9:19 ` jvb at cyberscience dot com
2021-05-20 13:25 ` dave.anglin at bell dot net
2021-05-20 13:37 ` jvb at cyberscience dot com
2021-05-20 14:02 ` dave.anglin at bell dot net
2021-05-20 14:59 ` jvb at cyberscience dot com
2021-05-20 15:03 ` dave.anglin at bell dot net
2021-05-20 15:16 ` dave.anglin at bell dot net
2021-05-20 17:00 ` dave.anglin at bell dot net
2021-05-20 17:22 ` jvb at cyberscience dot com
2021-06-03 17:19 ` dave.anglin at bell dot net
2021-06-09  9:51 ` jvb at cyberscience dot com
2021-06-09 10:12 ` jvb at cyberscience dot com
2021-07-04 21:56 ` me at larbob dot org
2021-07-05  8:56 ` jvb at cyberscience dot com
2021-07-14  2:51 ` bugzilla-gcc at thewrittenword dot com
2021-07-14  8:35 ` jvb at cyberscience dot com
2021-07-14 15:43 ` jvb at cyberscience dot com
2021-07-14 16:10 ` bugzilla-gcc at thewrittenword dot com
2021-07-14 16:13 ` jvb at cyberscience dot com
2021-07-14 16:37 ` bugzilla-gcc at thewrittenword dot com
2021-07-15 12:09 ` bugzilla-gcc at thewrittenword dot com
2021-07-15 14:22 ` jvb at cyberscience dot com
2021-07-15 14:39 ` bugzilla-gcc at thewrittenword dot com
2021-07-15 14:58 ` jvb at cyberscience dot com
2021-07-15 15:01 ` bugzilla-gcc at thewrittenword dot com
2021-07-15 15:24 ` dave.anglin at bell dot net
2021-07-15 18:48 ` bugzilla-gcc at thewrittenword dot com
2021-07-16 11:33 ` jvb at cyberscience dot com
2021-07-16 12:48 ` bugzilla-gcc at thewrittenword dot com
2021-07-16 12:51 ` bugzilla-gcc at thewrittenword dot com
2021-07-16 13:27 ` jvb at cyberscience dot com
2021-07-16 13:29 ` bugzilla-gcc at thewrittenword dot com
2021-07-17 17:14 ` me at larbob dot org
2021-07-17 17:39 ` me at larbob dot org
2021-07-17 18:38 ` dave.anglin at bell dot net
2021-07-18  2:02 ` bugzilla-gcc at thewrittenword dot com
2021-07-18 12:39 ` bugzilla-gcc at thewrittenword dot com
2021-07-19 21:00 ` me at larbob dot org
2021-07-19 22:43 ` me at larbob dot org
2021-07-20 16:06 ` me at larbob dot org
2021-07-20 16:07 ` me at larbob dot org
2021-07-20 16:08 ` me at larbob dot org
2021-07-20 17:04 ` dave.anglin at bell dot net
2021-07-20 17:05 ` me at larbob dot org
2021-07-20 17:58 ` me at larbob dot org
2021-07-20 18:24 ` me at larbob dot org
2021-07-20 23:58 ` me at larbob dot org
2021-07-21  0:01 ` me at larbob dot org
2021-07-21  2:32 ` bugzilla-gcc at thewrittenword dot com
2021-07-21  2:38 ` me at larbob dot org
2021-07-21  2:59 ` bugzilla-gcc at thewrittenword dot com
2021-07-21  4:36 ` bugzilla-gcc at thewrittenword dot com
2021-07-21  5:13 ` me at larbob dot org
2021-07-21  6:32 ` me at larbob dot org
2021-07-21 15:15 ` dave.anglin at bell dot net
2021-07-21 16:19 ` me at larbob dot org
2021-07-21 16:43 ` jvb at cyberscience dot com
2021-07-21 16:55 ` me at larbob dot org
2021-07-21 17:26 ` dave.anglin at bell dot net
2021-07-27 22:09 ` me at larbob dot org
2021-11-16 13:01 ` [Bug middle-end/61577] [9/10/11/12 " rguenth at gcc dot gnu.org
2022-05-27  9:35 ` [Bug middle-end/61577] [10/11/12/13 " rguenth at gcc dot gnu.org
2022-06-28 10:31 ` jakub at gcc dot gnu.org
2023-07-07 10:30 ` [Bug middle-end/61577] [11/12/13/14 " rguenth at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-61577-4-9NCORw2v8x@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).