From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DB5923850408; Thu, 7 Jan 2021 23:16:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DB5923850408 From: "law at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/98594] New: [11 Regression] IPA modref codegen bug Date: Thu, 07 Jan 2021 23:16:38 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ipa X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: law at redhat dot 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 cc target_milestone cf_gcctarget 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: Thu, 07 Jan 2021 23:16:39 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D98594 Bug ID: 98594 Summary: [11 Regression] IPA modref codegen bug Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: law at redhat dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Target: s390x Created attachment 49917 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D49917&action=3Dedit Hacked up/reduced testcase The "glm" package on s390x fails to build on s390x due to what appears to b= e a bug in the IPA modref changes. Specifically: commit 67a5c215940f4b21bac1aa489ce1f2fb3d52a53a Author: Jan Hubicka Date: Sat Sep 26 00:01:57 2020 +0200 Fix gimple_clobber handling in ipa-modref 2020-09-25 Jan Hubicka * ipa-modref.c (analyze_stmt): Fix return value for gimple_clobber. But I suspect this is just exposing a bug elsewhere in the modref support. Before early inlining we have: int bitCount::test () { int _1; int _2; int _3; bool _4; int _7; int _8; : _1 =3D 1; _2 =3D 1; _7 =3D bitCount::bitCount_bitfield (_2); _3 =3D _7; _4 =3D _1 =3D=3D _3; _8 =3D (int) _4; return _8; } Nothing really interesting there. THe called function looks like: ;; Function bitCount::bitCount_bitfield (_ZN8bitCountL17bitCount_bitfieldIiEEiT_, funcdef_no=3D13, decl_uid=3D3087, cgraph_uid=3D2, symbol_order=3D4) Analyzing function body size: int bitCount::bitCount_bitfield(genType) [with genType =3D int]/4 int bitCount::bitCount_bitfield (int x) { struct vec D.3185; struct vec D.3199; int _5; : glm::vec<1, int, glm::packed_highp>::vec (&D.3185, x_2(D)); D.3199 =3D bitCount::bitCount_bitfield<1, int, glm::packed_highp> (&D.3185); [return slot optimization] _5 =3D D.3199.D.3097.x; D.3199 =3D{v} {CLOBBER}; D.3185 =3D{v} {CLOBBER}; return _5; } The most important thing to note here is that the local variable D.3185 and the parameter X get passed to the glm::vec constructor. D.3185 then gets passed to an overload of bitCount::bitCount_bitfield. The constructor looks like: ;; Function glm::vec<1, int, glm::packed_highp>::vec (_ZN3glm3vecILi1EiLNS_9qualifierE0EEC1Ei, funcdef_no=3D16, decl_uid=3D3159, cgraph_uid=3D5, symbol_order=3D7) void glm::vec<1, int, glm::packed_highp>::vec (struct vec * const this, int scalar) { : *this_2(D) =3D{v} {CLOBBER}; this_2(D)->D.3097.x =3D scalar_4(D); return; } So we take the 2nd argument and stuff it into a field within the first argument. This all looks good. Now we look at the bitCount::bitCount_bitfield overload (edited for brevity): ;; Function bitCount::bitCount_bitfield<1, int, glm::packed_highp> (_ZN8bitCountL17bitCount_bitfieldILi1EiLN3glm9qualifierE0EEENS1_3vecIXT_EiX= T1_EEERKNS3_IXT_ET0_XT1_EEE, funcdef_no=3D17, decl_uid=3D3197, cgraph_uid=3D6, symbol_order=3D8) struct vec bitCount::bitCount_bitfield<1, int, glm::packed_highp> (const struct vec & v) { struct vec x; : x =3D MEM[(const struct vec &)v_2(D)]; x =3D bitCount::compute_bitfieldBitCountStep::call<1, unsigned int, glm::packed_highp> (&x, 1431655765, 1); x =3D bitCount::compute_bitfieldBitCountStep::call<1, unsigned int, glm::packed_highp> (&x, 858993459, 2); x =3D bitCount::compute_bitfieldBitCountStep::call<1, unsigned int, glm::packed_highp> (&x, 252645135, 4); glm::vec<1, int, glm::packed_highp>::vec (&, &x); x =3D{v} {CLOBBER}; return ; } So note the first real statement. That's going to read the data that was put into the vec node by the constructor. All good. Now in the .einline dump things have gone to hell. ;; Function bitCount::test (_ZN8bitCount4testEv, funcdef_no=3D12, decl_uid=3D3085, cgraph_uid=3D1, symbol_order=3D3) Iterations: 1 Symbols to be put in SSA form { D.3471 D.3522 } Incremental SSA update started at block: 0 Number of blocks in CFG: 5 Number of blocks to update: 4 ( 80%) Merging blocks 2 and 4 Merging blocks 2 and 3 int bitCount::test () { struct vec D.3524; struct vec D.3523; int D.3522; int _1; int _2; int _3; bool _4; int _6; int _7; int _8; : _1 =3D 1; _2 =3D 1; D.3524 =3D bitCount::bitCount_bitfield<1, int, glm::packed_highp> (&D.3523); [return slot optimization] _6 =3D D.3524.D.3097.x; D.3524 =3D{v} {CLOBBER}; D.3523 =3D{v} {CLOBBER}; _12 =3D _6; _7 =3D _12; _3 =3D _7; _4 =3D _1 =3D=3D _3; _8 =3D (int) _4; return _8; } Note we pass D.3523 to the bitCount_bitfield overload, but we've lost the statement that initialized its data field. Naturally the overload still loads that (now uninitialized) field and we get garbage data and the testsuite fails miserably. FUrthermore, we get an uninitalized warning (perhaps your subsequent uninit changes were papering over this problem to some degree). You should be able to see this with an s390x cross compiler with -O2.=