From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 46CEC383801C; Mon, 17 May 2021 09:56:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 46CEC383801C From: "jvb at cyberscience dot com" 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 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: build X-Bugzilla-Severity: major X-Bugzilla-Who: jvb at cyberscience dot com X-Bugzilla-Status: WAITING X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2021 09:56:33 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D61577 John Buddery changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jvb at cyberscience dot com --- Comment #215 from John Buddery --- I recently upgraded my hp-ix ia64 gcc build to 11.1.0, and I thought I'd sh= are 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.6513073= 62 +0100 @@ -6892,7 +6892,13 @@ for (j =3D 0; j < md.slot[curr].num_fixups; ++j) { ifix =3D md.slot[curr].fixup + j; - fix =3D fix_new_exp (frag_now, frag_now_fix () - 16 + i, 8, +=20=20=20=20=20=20=20=20=20=20 + unsigned long where =3D frag_now_fix () - 16 + i; +#ifdef TE_HPUX + if ( ifix->code =3D=3D BFD_RELOC_IA64_PCREL60B ) where++; +#endif +=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 + fix =3D fix_new_exp (frag_now, where, 8, &ifix->expr, ifix->is_pcrel, ifix->code); fix->tc_fix_data.opnd =3D ifix->opnd; fix->fx_file =3D md.slot[curr].src_file; This fixes, for HP only, the PCTEL60B offset to be what the HP linker expec= ts. 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 wel= l, 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, inclu= ding 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.0000000= 00 +0100 @@ -4410,7 +4410,9 @@ (const_int 0)) (clobber (match_operand:DI 1 "register_operand" "=3Db,b"))] "" - "br.call%+.many %1 =3D %0" + "@ + br.call%+.many %1 =3D %0 + brl.call%+.many %1 =3D %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" "=3Db,b"))] "" - "br.call%+.many %2 =3D %1" + "@ + br.call%+.many %2 =3D %1 + brl.call%+.many %2 =3D %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 do= es not accept brl with registers. The above unconditionally uses brl - on hp-ux and other platforms. This wou= ld 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 a= nd 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=