From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 90A313857C4C; Wed, 23 Sep 2020 08:42:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 90A313857C4C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1600850567; bh=kr2Tbm3P5+DBRbrDdQ5byL/RS9h7i60I4svd6MVpudw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=UaKAS7Uxmm7gxGRpQRQjwHkZGoxHw8/AzAFugJdfEcjcbjCmirtgJ0lJDxuek8hbv 6S8VPjYSrnnXBbSZOMPz/kxI/n/Lx1VXGC8burV7SPkNCeoNTMDVgp2DKNXI1cu8wd HFiRDt+tDEL35xdnzKgihpB3vI8DtySu50zDL1pY= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/97173] [11 Regression] ICE in vectorizable_live_operation, at tree-vect-loop.c:8324 since r11-3025-g095d42feed09f880 Date: Wed, 23 Sep 2020 08:42:47 +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.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.0 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 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: Wed, 23 Sep 2020 08:42:47 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D97173 --- Comment #2 from Richard Biener --- t.i:12:29: note: node 0x53dcd70 (max_nunits=3D2, refcnt=3D2) t.i:12:29: note: stmt 0 _4 =3D _1 + _3; t.i:12:29: note: stmt 1 _4 =3D _1 + _3; t.i:12:29: note: stmt 2 _5 =3D _4 + _3; t.i:12:29: note: stmt 3 _5 =3D _4 + _3; t.i:12:29: note: children 0x5578e20 0x53de920 t.i:12:29: note: node (external) 0x5578e20 (max_nunits=3D1, refcnt=3D1) t.i:12:29: note: { _1, _1, _4, _4 } t.i:12:29: note: node (external) 0x53de920 (max_nunits=3D1, refcnt=3D1) t.i:12:29: note: { _3, _3, _3, _3 } hmm, another case of a "weird" SLP grouping (the 0x53dcd70 node computes some operand lanes itself, _4 =3D _1 + 3). We're also getting the costing wrong here and think _1 + _3 can be eliminated. Now the code tries to exac= tly catch this case: /* ??? This can happen when the live lane ends up being used in a vector construction code-generated by an external SLP node (and code-generation for that already happened). See gcc.dg/vect/bb-slp-47.c. Doing this is what would happen if that vector CTOR were not code-generated yet so it is not too bad. ??? In fact we'd likely want to avoid this situation in the first place. */ if (gimple_code (use_stmt) !=3D GIMPLE_PHI && !vect_stmt_dominates_stmt_p (gsi_stmt (*gsi), use_stmt)) { gcc_assert (is_gimple_assign (use_stmt) && gimple_assign_rhs_code (use_stmt) =3D=3D CONSTRUCTOR) but the assert fails to consider the case where the CTOR elements need to be converted (here pointer to unsigned long) and thus the use_stmts are not the CTOR but the conversion. Of course as the comment says we likely want to avoid this situation and instead elide 0x53dcd70 to be external itself. For now I'm going to adjust the assert.=