[Bug tree-optimization/108639] [13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578

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

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

--- Comment #13 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:e261fcefb71e1270673f0457fcc73711f13d3079

commit r13-5696-ge261fcefb71e1270673f0457fcc73711f13d3079
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Thu Feb 2 18:08:44 2023 +0100

    irange: Compare nonzero bits in irange with widest_int [PR108639]

    The problem here is we are trying to compare two ranges with different
    precisions and the == operator in wide_int is complaining.

    Interestingly, the problem is not the nonzero bits, but the fact that
    the entire ranges have different precisions.  The reason we don't ICE
    when comparing the sub-ranges, is because the code in
    irange::operator== works on trees, and tree_int_cst_equal is
    promoting the comparison to a widest int:

      if (TREE_CODE (t1) == INTEGER_CST
          && TREE_CODE (t2) == INTEGER_CST
          && wi::to_widest (t1) == wi::to_widest (t2))
        return 1;

    This is why we don't see the ICE until the nonzero bits comparison is
    done on wide ints.  I think we should maintain the current equality
    behavior, and follow suit in the nonzero bit comparison.

    I have also fixed the legacy equality code, even though technically
    nonzero bits shouldn't appear in legacy.  But better safe than sorry.

            PR tree-optimization/108639

    gcc/ChangeLog:

            * value-range.cc (irange::legacy_equal_p): Compare nonzero bits as
            widest_int.
            (irange::operator==): Same.