From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 644163858D28; Mon, 6 Dec 2021 14:07:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 644163858D28 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/102291] [9/10/11/12 Regression] wrong overflow warning for compound expression conversion and bit_and expressions Date: Mon, 06 Dec 2021 14:07:58 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 11.2.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 9.5 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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: Mon, 06 Dec 2021 14:07:58 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102291 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jason at gcc dot gnu.org, | |jsm28 at gcc dot gnu.org, | |mpolacek at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- I'm afraid I'm getting lost in what convert does though with the TREE_OVERF= LOW flag. In the testcase, we have a cast of BIT_IOR_EXPR with (whatever, 0x80) and 0= int arguments to unsigned char. do_narrow is called and does: /* Don't do unsigned arithmetic where signed was wanted, or vice versa. Exception: if both of the original operands were unsigned then we can safely do the work as unsigned. Exception: shift operations take their type solely from the first argument. Exception: the LSHIFT_EXPR case above requires that we perform this operation unsigned lest we produce signed-overflow undefinedness. And we may need to do it as unsigned if we truncate to the original size. */ and as BIT_IOR_EXPR isn't listed, type =3D=3D typex is unsigned and TREE_TY= PE (arg0) and TREE_TYPE (arg1) are signed goes the: if (TYPE_UNSIGNED (typex)) typex =3D signed_type_for (typex); way. Those conversions create TYPE_OVERFLOW constant, even when there was nothing wrong in the source and because of the COMPOUND_EXPRs in there we d= on't manage to optimize those TYPE_OVERFLOW constants away and warn on it. For BIT_AND_EXPR/BIT_IOR_EXPR/BIT_XOR_EXPR, I must say I miss the reason why it would be ever a good idea to use typex =3D signed_type_for (typex), when= we want unsigned result, just converting to that right away doesn't have any downsides I can come up with. But I wonder even about the other operations, do we really want to introduce TYPE_OVERFLOWs in such cases where the operations are originally on wider signed operands and are cast to some narrower unsigned type?=