[Bug c/107465] [10/11/12/13 Regression] Bogus warning: promoted bitwise complement of an unsigned value is always nonzero

["cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107465

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:3ec9a8728086ad86a2d421e067329f305f40e005

commit r13-6476-g3ec9a8728086ad86a2d421e067329f305f40e005
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.