From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5A25A3858C50; Tue, 28 Feb 2023 05:08:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5A25A3858C50 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1677560880; bh=ADY+L0r4Yjj9xJcnn1nmL8ZgCvp+EVPDlIBTpIdohqk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=GwYPkUpYLIwyDeUYoWW2yDIE4oBE5rdflLl4+Zj/OQW6mhqDWAtGjiEkUfVYF76k+ 8hGJN6g4l8GMl/IQsUyDR1JjTcGVsQWdr9vxFTi9Xwv6imABlI5MC88woDB6PCPlgc Vz4pwodPbpW4ryrjZGHbk1owrPh2pyJrdybboZ4s= From: "linkw at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/108315] -mcpu=power10 changes ABI Date: Tue, 28 Feb 2023 05:07:59 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: ABI, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: linkw at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108315 Kewen Lin changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |linkw at gcc dot gnu.org --- Comment #2 from Kewen Lin --- (In reply to Alexander Monakov from comment #0) > Created attachment 54202 [details] > testcase >=20 > At least the documentation should mention that if intentional. >=20 > In the attached example, the function bar is compiled to >=20 > bar: > .localentry bar,1 > mtctr 3 > mr 12,3 > bctr > .long 0 > .byte 0,0,0,0,0,0,0,0 >=20 > i.e. it does not preserve r2 (it's compiled with -mcpu=3Dpower10). If the > caller is not compiled with -mcpu=3Dpower10, it needs r2 preserved (bar h= as a > localentry, so the nop in the caller stays a nop after linking). My local 64bit-elfv2-abi spec v1.5 has the following description: 3.4.1. Symbol Values "The values of these three most significant bits of the st_other field have= the following meanings: ... 1 The local and global entry points are the same, and r2 should be treated = as caller-saved for local and global callers. " ... "The value of st_other is determined from the .localentry directive as foll= ows: If the .localentry value is 0, the value of st_other is 0. If the .localent= ry value is 1, the value of st_other is 1. Otherwise, the value of st_other is= the logarithm (base 2) of the .localentry value." The function bar is with st_other value 1, r2 should be treated as caller-saved, so it doesn't take action to preserve r2. >=20 > I verified the testcase misbehaves on Compile Farm's gcc135: as it does n= ot > use any power10-specific instructions, it's runnable there. I tried the attachment on one local machine (also ppc64le p9) and noticed t= he linker already did some fix-ups with long_branch.bar stub, Dump of assembler code for function main: 0x0000000010000540 <+0>: lis r2,4098 0x0000000010000544 <+4>: addi r2,r2,32512 0x0000000010000548 <+8>: mflr r0 0x000000001000054c <+12>: nop 0x0000000010000550 <+16>: ld r3,-32728(r2) 0x0000000010000554 <+20>: std r0,16(r1) 0x0000000010000558 <+24>: stdu r1,-32(r1) 0x000000001000055c <+28>: bl 0x10000510 <00000038.long_branch.ba= r> =3D> 0x0000000010000560 <+32>: ld r2,24(r1) 0x0000000010000564 <+36>: addis r3,r2,-2 0x0000000010000568 <+40>: addi r3,r3,-30328 Dump of assembler code for function 00000038.long_branch.bar: =3D> 0x0000000010000510 <+0>: std r2,24(r1) 0x0000000010000514 <+4>: b 0x10000710 which would save r2 onto the corresponding stack slot ahead, it runs well as expected. Not sure why it doesn't work on your side, maybe this inter-opera= tion requires some support in newer binutils? My local one is GNU ld 2.34 which = is for final linking (and 2.35 for power10 support, ie. bar.o generation).=