From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E1E04385780C; Tue, 26 Apr 2022 13:18:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E1E04385780C From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/105394] [12 Regression] ICE: verify_gimple failed with MVE during GIMPLE pass: veclower2 Date: Tue, 26 Apr 2022 13:18:52 +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: 12.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: --- 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: Tue, 26 Apr 2022 13:18:53 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105394 --- Comment #3 from Richard Biener --- We are calling tree_vec_extract with bitsize 32 but a QImode boolean type. ICK. (gdb) p debug_gimple_stmt (stmt) _8 =3D VEC_COND_EXPR <_6, _7, { 3.0e+0, 3.0e+0, 3.0e+0, 3.0e+0 }>; $15 =3D void (gdb) p debug_tree (a) unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7ffff6630930 precision:4 min max > V4BI size unit-size align:16 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7ffff66309d8 nunits:4> visited def_stmt _6 =3D _27; version:6> so we have a non 1-precision BImode bool. That's something we assume doesn't happen (here). I see V4BImode is 2 bytes in size, are there really 4 bits used for each element? The patch below assumes that and generates _40 =3D VIEW_CONVERT_EXPR(_6); _41 =3D _40 & 15; _42 =3D _41 !=3D 0 ? _30 : 3.0e+0; _43 =3D _40 & 240; _44 =3D _43 !=3D 0 ? _33 : 3.0e+0; _45 =3D _40 & 3840; _46 =3D _45 !=3D 0 ? _36 : 3.0e+0; _47 =3D _40 & 61440; _48 =3D _47 !=3D 0 ? _39 : 3.0e+0; _8 =3D {_42, _44, _46, _48}; for the unsupported VEC_COND_EXPR. The approach won't work for variable-le= ngth vectors since we cannot pun that to an integer type (precision is always constant). So eventually using an adjusted BIT_FIELD_REF for the vector BImode case is better - as said the current code simply assumes a classical mask. I suppose for SVE we never run into unsupported conds?=