From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id CEA363896C28; Wed, 9 Dec 2020 09:41:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CEA363896C28 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/98190] [11 Regression] GCC11 miscompiles code using _Bool when inlining: bfxil instruction misused since r11-165 Date: Wed, 09 Dec 2020 09:41:18 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned 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, 09 Dec 2020 09:41:18 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D98190 --- Comment #12 from Jakub Jelinek --- (In reply to rsandifo@gcc.gnu.org from comment #10) > If we can't assert, I guess the rule is that we need to extend > whenever we're storing to the MSB of the inner register. We can > do that either by extending the source value and the range to > the outer register, or by assigning to the inner register and > then extending it separately. So perhaps: --- gcc/expr.c.jj 2020-12-09 00:00:08.622548080 +0100 +++ gcc/expr.c 2020-12-09 10:36:12.198801940 +0100 @@ -5451,6 +5451,33 @@ expand_assignment (tree to, tree from, b mode1, to_rtx, to, from, reversep)) result =3D NULL; + else if (SUBREG_P (to_rtx) + && SUBREG_PROMOTED_VAR_P (to_rtx)) + { + /* If to_rtx is a promoted subreg, this must be a store to the + whole variable, otherwise to_rtx would need to be MEM. + We need to zero or sign extend the value afterwards. */ + gcc_assert (known_eq (bitpos, 0) + && known_eq (bitsize, + GET_MODE_BITSIZE (GET_MODE (to_rtx))= )); + if (TREE_CODE (to) =3D=3D MEM_REF && !REF_REVERSE_STORAGE_ORD= ER (to)) + result =3D store_expr (from, to_rtx, 0, nontemporal, false); + else + { + result =3D store_field (to_rtx, bitsize, bitpos, + bitregion_start, bitregion_end, + mode1, from, get_alias_set (to), + nontemporal, reversep); + rtx to_rtx1 + =3D lowpart_subreg (subreg_unpromoted_mode (to_rtx), + SUBREG_REG (to_rtx), + subreg_promoted_mode (to_rtx)); + to_rtx1 =3D convert_to_mode (subreg_promoted_mode (to_rtx= ), + to_rtx1, + SUBREG_PROMOTED_SIGN (to_rtx)); + emit_move_insn (SUBREG_REG (to_rtx), to_rtx1); + } + } else result =3D store_field (to_rtx, bitsize, bitpos, bitregion_start, bitregion_end, then? As in, if store_expr can handle it, use that, otherwise perform the extension at the end. As for BIT_INSERT_EXPR, I'm not sure if SSA_NAMEs can get promoted SUBREGs = or not, but in any case it wouldn't be this code path, it would be store_expr which handles the promoted SUBREGs already, because destination would not b= e a MEM_REF with non-mem decl or reversed order, nor handled_component_p, nor ARRAY_TYPE destination.=