public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c/107465] [10/11/12 Regression] Bogus warning: promoted bitwise complement of an unsigned value is always nonzero Date: Sun, 19 Mar 2023 05:30:39 +0000 [thread overview] Message-ID: <bug-107465-4-cR7iAlmqoq@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-107465-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107465 --- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-12 branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:93aafc14410388875313719a76b92812911a861a commit r12-9286-g93aafc14410388875313719a76b92812911a861a Author: Jakub Jelinek <jakub@redhat.com> Date: Sat Mar 4 10:21:45 2023 +0100 c-family: Incremental fix for -Wsign-compare BIT_NOT_EXPR handling [PR107465] There can be too many extensions and seems I didn't get everything right in the previously posted patch. The following incremental patch ought to fix that. The code can deal with quite a few sign/zero extensions at various spots and it is important to deal with all of them right. On the argument that contains BIT_NOT_EXPR we have: MSB bits#4 bits#3 BIT_NOT_EXPR bits#2 bits#1 LSB where bits#1 is one or more bits (TYPE_PRECISION (TREE_TYPE (arg0)) at the end of the function) we don't know anything about, for the purposes of this warning it is VARYING that is inverted with BIT_NOT_EXPR to some other VARYING bits; bits#2 is one or more bits (TYPE_PRECISION (TREE_TYPE (op0)) - TYPE_PRECISION (TREE_TYPE (arg0)) at the end of the function) which are known to be 0 before the BIT_NOT_EXPR and 1 after it. bits#3 is zero or more bits from the TYPE_PRECISION (TREE_TYPE (op0)) at the end of function to the TYPE_PRECISION (TREE_TYPE (op0)) at the end of the function to TYPE_PRECISION (TREE_TYPE (op0)) at the start of the function, which are either zero extension or sign extension. And bits#4 is zero or more bits from the TYPE_PRECISION (TREE_TYPE (op0)) at the start of the function to TYPE_PRECISION (result_type), which again can be zero or sign extension. Now, vanilla trunk as well as the previously posted patch mishandles the case where bits#3 are sign extended (as bits#2 are known to be all set, that means bits#3 are all set too) but bits#4 are zero extended and are thus all 0. The patch fixes it by tracking the lowest bit which is known to be clear above the known to be set bits (if any, otherwise it is precision of result_type). 2023-03-04 Jakub Jelinek <jakub@redhat.com> PR c/107465 * c-warn.cc (warn_for_sign_compare): Don't warn for unset bits above innermost zero extension of BIT_NOT_EXPR result. * c-c++-common/Wsign-compare-2.c (f18): New test. (cherry picked from commit 3ec9a8728086ad86a2d421e067329f305f40e005)
next prev parent reply other threads:[~2023-03-19 5:30 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-10-30 17:59 [Bug c/107465] New: " lavr at ncbi dot nlm.nih.gov 2022-10-31 1:51 ` [Bug c/107465] " pinskia at gcc dot gnu.org 2022-10-31 1:59 ` [Bug c/107465] [10/11/12/13 Regression] " pinskia at gcc dot gnu.org 2022-10-31 2:03 ` pinskia at gcc dot gnu.org 2022-10-31 2:03 ` pinskia at gcc dot gnu.org 2022-11-05 10:25 ` rguenth at gcc dot gnu.org 2022-11-21 14:32 ` jakub at gcc dot gnu.org 2022-11-21 14:51 ` jakub at gcc dot gnu.org 2022-11-21 15:28 ` jakub at gcc dot gnu.org 2022-11-21 19:22 ` jakub at gcc dot gnu.org 2023-03-04 9:19 ` cvs-commit at gcc dot gnu.org 2023-03-04 9:22 ` cvs-commit at gcc dot gnu.org 2023-03-04 9:25 ` [Bug c/107465] [10/11/12 " jakub at gcc dot gnu.org 2023-03-19 5:30 ` cvs-commit at gcc dot gnu.org 2023-03-19 5:30 ` cvs-commit at gcc dot gnu.org [this message] 2023-03-20 10:28 ` [Bug c/107465] [10/11 " jakub at gcc dot gnu.org 2023-05-02 20:15 ` cvs-commit at gcc dot gnu.org 2023-05-02 20:15 ` cvs-commit at gcc dot gnu.org 2023-05-03 9:30 ` [Bug c/107465] [10 " jakub at gcc dot gnu.org 2023-05-03 15:22 ` cvs-commit at gcc dot gnu.org 2023-05-03 15:22 ` cvs-commit at gcc dot gnu.org 2023-05-04 7:21 ` jakub at gcc dot gnu.org 2023-05-20 4:26 ` pinskia at gcc dot gnu.org 2023-05-20 4:33 ` pinskia at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-107465-4-cR7iAlmqoq@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).