From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 7C1293853D6C; Mon, 21 Nov 2022 14:32:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7C1293853D6C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1669041157; bh=gx4CXXd7NsDRoMQ7Ixl8zjnVo9UwXgYW/Ulgt6AbvRI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=CLfE9bpKih1LyKCH2m9fT82HyB/zVEtcqC4LKP4MVdBuOcLf3P2dHKhr7fcijG668 JoabYgel94aH1JKBwTDgdlspONK4izjPIi0G3DxUF6em27XUTYk13xAOWc1o+Hqadx WnjJckJyYMobG2z0iZXWw/vy0P11ZC8cmKEPI8I8= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/107465] [10/11/12/13 Regression] Bogus warning: promoted bitwise complement of an unsigned value is always nonzero Date: Mon, 21 Nov 2022 14:32:36 +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.3.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: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107465 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- (In reply to Andrew Pinski from comment #3) > --- a/gcc/c-family/c-warn.cc > +++ b/gcc/c-family/c-warn.cc > @@ -2302,8 +2302,8 @@ warn_for_sign_compare (location_t location, > sop =3D fold_for_warn (sop); > uop =3D fold_for_warn (uop); >=20 > - STRIP_TYPE_NOPS (sop); > - STRIP_TYPE_NOPS (uop); > + STRIP_SIGN_NOPS (sop); > + STRIP_SIGN_NOPS (uop); > base_type =3D (TREE_CODE (result_type) =3D=3D COMPLEX_TYPE > ? TREE_TYPE (result_type) : result_type); >=20 >=20 No, this has nothing to do with it. The problem is purely in incorrect use of get_narrower/c_common_get_narrowe= r. op0 =3D c_common_get_narrower (op0, &unsignedp0); op1 =3D c_common_get_narrower (op1, &unsignedp1); if ((TREE_CODE (op0) =3D=3D BIT_NOT_EXPR) ^ (TREE_CODE (op1) =3D=3D BIT_NOT_EXPR)) { if (TREE_CODE (op0) =3D=3D BIT_NOT_EXPR) op0 =3D c_common_get_narrower (TREE_OPERAND (op0, 0), &unsignedp0); if (TREE_CODE (op1) =3D=3D BIT_NOT_EXPR) op1 =3D c_common_get_narrower (TREE_OPERAND (op1, 0), &unsignedp1); What get_narrower/c_common_get_narrower store into the integer pointed by t= he second argument doesn't mean anything at all if the function doesn't return something narrower, it is purely about whether if there needs to be some extension from what {,c_common_}get_narrower returns to what has been passe= d to it as the first argument needs to be a sign or zero extension. E.g. shorten_binary_op does it get right and uses: arg0 =3D c_common_get_narrower (op0, &unsigned0); arg1 =3D c_common_get_narrower (op1, &unsigned1); /* UNS is 1 if the operation to be done is an unsigned one. */ uns =3D TYPE_UNSIGNED (result_type); /* Handle the case that OP0 (or OP1) does not *contain* a conversion but it *requires* conversion to FINAL_TYPE. */ if ((TYPE_PRECISION (TREE_TYPE (op0)) =3D=3D TYPE_PRECISION (TREE_TYPE (arg0))) && TREE_TYPE (op0) !=3D result_type) unsigned0 =3D TYPE_UNSIGNED (TREE_TYPE (op0)); if ((TYPE_PRECISION (TREE_TYPE (op1)) =3D=3D TYPE_PRECISION (TREE_TYPE (arg1))) && TREE_TYPE (op1) !=3D result_type) unsigned1 =3D TYPE_UNSIGNED (TREE_TYPE (op1)); I guess for the first pair of c_common_get_narrower we can do something similar. The problem is that there is another pair of them. For those one can surely do that as well, but there is a further problem. If the precision changes in both the c_common_get_narrower (op{0,1}, &unsignedp{0,1}) and c_common_get_narrower (TREE_OPERAND (op{0,1}, 0), &unsignedp{0,1}) calls, we need to take into account also what actually it means. Note, this has been introduced already in r0-9641-g64c01f8071113aff84414204e9d63cff3701bfb7 And, the bits < HOST_BITS_PER_LONG && part made sense in 1995 when it was u= sing long, but it doesn't make any sense to me now (we check tree_fits_shwi_p and that verifies it fits into HOST_WIDE_INT).=