From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BB8573858C52; Tue, 17 Jan 2023 12:27:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BB8573858C52 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1673958473; bh=N63wYxNDDKMm9U1qsLXT3BMMG0UFdwlCutfe1b/+Cgk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=q+iZ9HSRoS79mTRixqFeGd6Cj6XAoQ7woJ7P6yndWK6UcROUtLqlqYz7WWTfXfZwn iQghKVxHfbpSLhZRahrdmHi77W/LWXu/gg2vGn6GlsHVyXJabx2Tfk3ktQ+l1gZXoI spuRrDEtBT/GwsD2ucbBSibdiJxj/tXAaTRFeP0o= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/105769] [11/12/13 Regression] program segmentation fault with -ftree-vectorize and nested lambdas Date: Tue, 17 Jan 2023 12:27:53 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 11.2.1 X-Bugzilla-Keywords: needs-bisection, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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=3D105769 --- Comment #10 from Richard Biener --- (In reply to Jakub Jelinek from comment #9) > And just statements that refer to those 3 variables that (incorrectly) sh= are > the stack slot + basic block boundaries. > grep 'bias\|D.5698\|D.5681\|:' /tmp/00 > struct struct void D.5698; > struct map_t D.5681; > struct vec bias; > [local count: 1073741829]: > _12 =3D (long unsigned int) &bias; > bias =3D{v} {CLOBBER}; > __ct_comp (&D.5698.__est, &D.5682); > [local count: 1073741824]: > MEM [(void *)&D.5698 + 32B] =3D _21; > [local count: 1073741824]: > __ct_comp (_14, &D.5698.__est); > [local count: 1073741824]: > vect__16.52_79 =3D MEM [(void *)&D.5698 += 32B]; > __dt_base (&MEM[(struct function *)&D.5698].D.5235); > D.5698 =3D{v} {CLOBBER}; > D.5698 =3D{v} {CLOBBER(eol)}; > MEM [(struct _Function_base *)&D.5681] =3D {}; > MEM [(bool (*) (union _Any_data & > {ref-all}, const union _Any_data & {ref-all}, _Manager_operation) *)&D.56= 81 > + 16B] =3D _84; > [count: 0]: > : > [count: 0]: > : > __dt_base (&MEM[(struct function *)&D.5698].D.5235); > D.5698 =3D{v} {CLOBBER}; > [local count: 429496]: > [local count: 1073312328]: > _19 (&D.5683.D.5217._M_functor, &D.5681); > [local count: 1073312328]: > __dt_base (&D.5681.D.5223); > D.5681 =3D{v} {CLOBBER}; > D.5681 =3D{v} {CLOBBER(eol)}; > bias =3D{v} {CLOBBER(eol)}; > [count: 0]: > : > __dt_base (&D.5681.D.5223); > D.5681 =3D{v} {CLOBBER}; > D.5681 =3D{v} {CLOBBER(eol)}; > [count: 0]: > : > D.5698 =3D{v} {CLOBBER}; >=20 > Now, perhaps the sharing of stack slot between D.5681 and D.5698 is fine, > seems > D.5698 is destructed before D.5681 is constructed: > D.5698 =3D{v} {CLOBBER}; > D.5698 =3D{v} {CLOBBER(eol)}; > MEM [(struct _Function_base *)&D.5681] =3D {}; > and D.5698 is later used just in EH block reachable only from earlier bas= ic > blocks > or just as > D.5698 =3D{v} {CLOBBER}; > in the last EH bb. But the sharing of the stack slot in between bias and > D.5698 looks wrong. What can be seen in the IL is: > _12 =3D (long unsigned int) &bias; > which has been hoisted before the > bias =3D{v} {CLOBBER}; > statement by the slp1 pass. > From: > ;; basic block 2, loop depth 0 > ;; pred: ENTRY > _3 =3D operator<< (&cout, "will do (ab)"); > endl (_3); > MEM[(struct vec *)&cov_jn] =3D{v} {CLOBBER}; > bias =3D{v} {CLOBBER}; > MEM[(struct function *)&D.5682] =3D{v} {CLOBBER}; > MEM [(struct _Function_base *)&D.5682] =3D {}; > MEM[(struct function *)&D.5682]._M_invoker =3D _M_invoke; > MEM[(struct function *)&D.5682].D.5235._M_manager =3D _M_manager; > __ct_comp (&D.5698.__est, &D.5682); > ;; succ: 5 > ;; 18 >=20 > ;; basic block 5, loop depth 0 > ;; pred: 2 > D.5698.__cov =3D &cov_jn; > D.5698.__bias =3D &bias; > in dse4 to: > ;; basic block 2, loop depth 0 > ;; pred: ENTRY > _12 =3D VIEW_CONVERT_EXPR(&bias); > _15 =3D VIEW_CONVERT_EXPR(&cov_jn); > _21 =3D {_15, _12}; > _9 =3D VIEW_CONVERT_EXPR(_M_invoke); > _10 =3D VIEW_CONVERT_EXPR(_M_manager); > _8 =3D {_10, _9}; > _3 =3D operator<< (&cout, "will do (ab)"); > endl (_3); > MEM[(struct vec *)&cov_jn] =3D{v} {CLOBBER}; > bias =3D{v} {CLOBBER}; > MEM[(struct function *)&D.5682] =3D{v} {CLOBBER}; > MEM [(struct _Function_base *)&D.5682] =3D {}; > MEM [(bool (*) (union _Any_data & > {ref-all}, const union _Any_data & {ref-all}, _Manager_operation) *)&D.56= 82 > + 16B] =3D _8; > __ct_comp (&D.5698.__est, &D.5682); > ;; succ: 5 > ;; 18 >=20=20=20 > ;; basic block 5, loop depth 0 > ;; pred: 2 > MEM [(void *)&D.5698 + 32B] =3D _21; > in slp1. >=20 > Is that what is incorrect? And we should never hoist taking of addresses > before a clobber on that var? I think that's the usual pattern for the two other stack-slot sharing PRs we have. The liveness analysis makes wrong assumptions about CLOBBER and CLOB= BER isn't a barrier for address-takens (and we don't have birth CLOBBERs). But why does -fstack-reuse=3Dnone not help?=