[Bug tree-optimization/109778] [10/11/12/13 Regression] Wrong code at -O1 and above on x86_64-linux-gnu

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

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

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

https://gcc.gnu.org/g:817d1496e17806bdefab1e0fb06abdf56df58cbd

commit r11-10753-g817d1496e17806bdefab1e0fb06abdf56df58cbd
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue May 9 12:10:07 2023 +0200

    tree-ssa-ccp, wide-int: Fix up handling of [LR]ROTATE_EXPR in bitwise ccp
[PR109778]

    The following testcase is miscompiled, because bitwise ccp2 handles
    a rotate with a signed type incorrectly.
    Seems tree-ssa-ccp.cc has the only callers of wi::[lr]rotate with 3
    arguments, all other callers just rotate in the right precision and
    I think work correctly.  ccp works with widest_ints and so rotations
    by the excessive precision certainly don't match what it wants
    when it sees a rotate in some specific bitsize.  Still, if it is
    unsigned rotate and the widest_int is zero extended from width,
    the functions perform left shift and logical right shift on the value
    and then at the end zero extend the result of left shift and uselessly
    also the result of logical right shift and return | of that.
    On the testcase we the signed char rrotate by 4 argument is
    CONSTANT -75 i.e. 0xffffffff....fffffb5 with mask 2.
    The mask is correctly rotated to 0x20, but because the 8-bit constant
    is sign extended to 192-bit one, the logical right shift by 4 doesn't
    yield expected 0xb, but gives 0xfffffffffff....ffffb, and then
    return wi::zext (left, width) | wi::zext (right, width); where left is
    0xfffffff....fb50, so we return 0xfb instead of the expected
    0x5b.

    The following patch fixes that by doing the zero extension in case of
    the right variable before doing wi::lrshift rather than after it.

    Also, wi::[lr]rotate widht width < precision always zero extends
    the result.  I'm afraid it can't do better because it doesn't know
    if it is done for an unsigned or signed type, but the caller in this
    case knows that very well, so I've done the extension based on sgn
    in the caller.  E.g. 0x5b rotated right (or left) by 4 with width 8
    previously gave 0xb5, but sgn == SIGNED in widest_int it should be
    0xffffffff....fffb5 instead.

    2023-05-09  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/109778
            * wide-int.h (wi::lrotate, wi::rrotate): Call wi::lrshift on
            wi::zext (x, width) rather than x if width != precision, rather
            than using wi::zext (right, width) after the shift.
            * tree-ssa-ccp.c (bit_value_binop): Call wi::ext on the results
            of wi::lrotate or wi::rrotate.

            * gcc.c-torture/execute/pr109778.c: New test.

    (cherry picked from commit a8302d2a4669984c7c287d12ef5b37cde6699c80)