[Bug tree-optimization/107312] [13 Regression] ICE in verify_range, at value-range.cc:1172, called from range_true_and_false since r13-3193-g8b6bcedc88d54415

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

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Aldy Hernandez <aldyh@gcc.gnu.org>:

https://gcc.gnu.org/g:d32969898e113e86e1c42b0c6f096f8228cbf1ff

commit r13-3382-gd32969898e113e86e1c42b0c6f096f8228cbf1ff
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Wed Oct 19 14:27:46 2022 +0200

    [PR tree-optimization/107312] Make range_true_and_false work with 1-bit
signed types.

    range_true_and_false() returns a range of [0,1], which for a 1-bit
    signed integer gets passed to the irange setter as [0, -1].  These
    endpoints are out of order and cause an ICE.  Through some dumb luck,
    the legacy code swaps out of order endpoints, because old VRP would
    sometimes pass endpoints reversed, depending on the setter to fix
    them.  This swapping does not happen for non-legacy, hence the ICE.

    The right thing to do (apart from killing legacy and 1-bit signed
    integers ;-)), is to avoid passing out of order endpoints for 1-bit
    signed integers.  For that matter, a range of [-1, 0] (signed) or
    [0, 1] (unsigned) is just varying.

            PR tree-optimization/107312

    gcc/ChangeLog:

            * range.h (range_true_and_false): Special case 1-bit signed types.
            * value-range.cc (range_tests_misc): New test.

    gcc/testsuite/ChangeLog:

            * gcc.target/i386/pr107312.c: New test.