From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id EB56A3858C60; Fri, 27 Aug 2021 20:54:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EB56A3858C60 From: "pc at us dot ibm.com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/102107] New: protocol register (r12) corrupted before a tail call Date: Fri, 27 Aug 2021 20:54:27 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 11.2.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: pc at us dot ibm.com 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created Message-ID: 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: Fri, 27 Aug 2021 20:54:28 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102107 Bug ID: 102107 Summary: protocol register (r12) corrupted before a tail call Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pc at us dot ibm.com Target Milestone: --- Created attachment 51367 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D51367&action=3Dedit preprocessed source (large) I've been working on an effort to improve Python performance, and hit an is= sue when running with a libpython.so that was built with "-mcpu=3Dpower10". The problem appears to be not correctly setting up (and preserving) register 12 before calling into a dynamically loaded, non-PCrel Python module in the fo= rm of a shared object. GDB shows the following instruction stream: =3D> 0x7ffff7d25014 : ld r12,0(r9) =3D> 0x7ffff7d25018 : addi r1,r1,112 r12 0x7fffe921af60 140737104686944 =3D> 0x7ffff7d2501c : std r10,0(r30) =3D> 0x7ffff7d25020 : ld r3,8(r9) =3D> 0x7ffff7d25024 : ld r9,0(r31) =3D> 0x7ffff7d25028 : ld r29,-24(r1) =3D> 0x7ffff7d2502c : ld r30,-16(r1) =3D> 0x7ffff7d25030 : mtctr r12 =3D> 0x7ffff7d25034 : lwz r12,8(r1) r12 0x4000 16384 =3D> 0x7ffff7d25038 : addi r9,r9,1 =3D> 0x7ffff7d2503c : std r9,0(r31) =3D> 0x7ffff7d25040 : ld r31,-8(r1) =3D> 0x7ffff7d25044 : mtocrf 8,r12 =3D> 0x7ffff7d25048 : bctr =3D> 0x7fffe921af60 : addis r2,r12,4=20=20 =3D> 0x7fffe921af64 : addi r2,r2,-12384 =3D> 0x7fffe921af68 : nop =3D> 0x7fffe921af6c : ld r3,-32728(r2) Program received signal SIGSEGV, Segmentation fault. 0x00007fffe921af6c in _Py_INCREF (op=3D) at ../Python-3.9.6/Include/object.h:408 408 op->ob_refcnt++; After setting r12 to the address of the caller (0x7ffff7d25014), the load at 0x7ffff7d25034 overwrites it with the CR save value just before the tail ca= ll (bctr) at 0x7ffff7d25048, resulting in the badness when setting up and using the TOC. I suspect some sort of instruction scheduling issue? I've attached a rather large pre-processed C file. It's complicated to redu= ce because of functions calling other functions. I gave "creduce" a shot at it, but it's challenging (for me, at least) to craft a script that knows what to look for. I'll also attach the best I could get from creduce, but shield yo= ur eyes before looking at it.=