From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 0481C3858024; Sat, 4 Mar 2023 09:19:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0481C3858024 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1677921565; bh=/omO7mG6MeGOstllxHZ1ukZ9sWOWPs2sN7JGBNPoazE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=nZxLyW9xDDUOhm8EW7XZURBEQ3mUTdZI9r2PiK/zXJJRoLGoqNw45gAI8Vj259upH 1J03uFm9FKzudyEuba6vDbojPsi7cGcEqzjgDKBUYXWEYwW7JNHMjDdvww0slSJDRX KXkZPYCJYN3tktwBcKfdZa7F6BaCImiEkZKEWfys= From: "cvs-commit 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: Sat, 04 Mar 2023 09:19:22 +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: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.5 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107465 --- Comment #9 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:daaf74a714c41c8dbaf9954bcc58462c63062b4f commit r13-6475-gdaaf74a714c41c8dbaf9954bcc58462c63062b4f Author: Jakub Jelinek Date: Sat Mar 4 10:18:37 2023 +0100 c-family: Fix up -Wsign-compare BIT_NOT_EXPR handling [PR107465] The following patch fixes multiple bugs in warn_for_sign_compare relate= d to the BIT_NOT_EXPR related warnings. My understanding is that what those 3 warnings are meant to warn (since 1995 apparently) is the case where we have BIT_NOT_EXPR of a zero-extended value, so in result_type the value is something like: 0b11111111XXXXXXXX (e.g. ~ of a 8->16 bit zero extension) 0b000000000000000011111111XXXXXXXX (e.g. ~ of a 8->16 bit zero extension then zero extended to 32 bits) 0b111111111111111111111111XXXXXXXX (e.g. ~ of a 8->16 bit zero extension then sign extended to 32 bits) and the intention of the warning is to warn when this is compared again= st something that has some 0 bits at the place where the above has guarant= eed 1 bits, either ensured through comparison against constant where we know the bits exactly, or through zero extension from some narrower type whe= re again we know at least some upper bits are zero extended. The bugs in the warning code are: 1) misunderstanding of the {,c_common_}get_narrower APIs - the unsignedp it sets is only meaningful if the function actually returns something narrower (in that case it says whether the narrower value is then sign (0) or zero (1) extended to the originally passed value. Though op0 or op1 at this point might be already narrower than result_type, and if the function doesn't return anything narrower, it all depends on whether the passed in op{0,1} had TYPE_UNSIGNED type or not 2) the code didn't check at all whether the BIT_NOT_EXPR operand was actually zero extended (i.e. that it was narrower and unsignedp was set to 1 for it), all it did is check that unsignedp from the call was 1. But that isn't well defined thing, if the argument is returned as is, the function sets unsignedp to 0, but if there is e.g. a useless cast to the same or compatible type in between, it can return 1 if the cast is unsigned; now, if BIT_NOT_EXPR operand is not zero extended, we know nothing at all about any bits in the operand containing BIT_NOT_EXPR, so there is nothing to warn about 3) the code was actually testing both operands after calling c_common_get_narrower on them and on the one with BIT_NOT_EXPR again for constants; I think that is just wrong in case the BIT_NOT_= EXPR operand wouldn't be fully folded, the warning makes sense only if the other operand not having BIT_NOT_EXPR in it is constant 4) as can be seen from the above bit pattern examples, the upper bits a= bove (in the patch arg0) aren't always all 1s, there could be some zero extension above it and from it one would have 0s, so that needs to be taken in= to account for the choice which constant bits to test for being always = set otherwise warning is emitted, or for the zero extension guaranteed z= ero bits 5) the patch also simplifies the handling, we only do it if one but not both operands are BIT_NOT_EXPR after first {,c_common_}get_narrower, so we can just use std::swap to ensure it is the first one 6) the code compared bits against HOST_BITS_PER_LONG, which made sense back in 1995 when the values were stored into long, but now that they are HOST_WIDE_INT should test HOST_BITS_PER_WIDE_INT (or we could rewrite the stuff to wide_int, not done in the patch) 2023-03-04 Jakub Jelinek PR c/107465 * c-warn.cc (warn_for_sign_compare): If c_common_get_narrower doesn't return a narrower result, use TYPE_UNSIGNED to set unsignedp0 and unsignedp1. For the one BIT_NOT_EXPR case vs. one without, only check for constant in the non-BIT_NOT_EXPR operand, use std::swap to simplify the code, only warn if BIT_NOT_EXPR operand is exte= nded from narrower unsigned, fix up computation of mask for the cons= tant cases and for unsigned other operand case handle differently BIT_NOT_EXPR result being sign vs. zero extended. * c-c++-common/Wsign-compare-2.c: New test. * c-c++-common/pr107465.c: New test.=