]> git.ipfire.org Git - people/ms/gcc.git/commit
irange: Compare nonzero bits in irange with widest_int [PR108639]
authorAldy Hernandez <aldyh@redhat.com>
Thu, 2 Feb 2023 17:08:44 +0000 (18:08 +0100)
committerAldy Hernandez <aldyh@redhat.com>
Fri, 3 Feb 2023 20:33:07 +0000 (21:33 +0100)
commite261fcefb71e1270673f0457fcc73711f13d3079
treea63c6017ebeeeb2399abb409dc07ad3291534194
parent10bd26d6efe88a8cf03a6a325351bc470a910cab
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.
gcc/testsuite/gcc.c-torture/compile/pr108638.c [new file with mode: 0644]
gcc/testsuite/gcc.c-torture/compile/pr108639.c [new file with mode: 0644]
gcc/value-range.cc