diff options
author | Aldy Hernandez <aldyh@redhat.com> | 2023-02-02 18:08:44 +0100 |
---|---|---|
committer | Aldy Hernandez <aldyh@redhat.com> | 2023-02-03 21:33:07 +0100 |
commit | e261fcefb71e1270673f0457fcc73711f13d3079 (patch) | |
tree | a63c6017ebeeeb2399abb409dc07ad3291534194 /libgcc | |
parent | 10bd26d6efe88a8cf03a6a325351bc470a910cab (diff) | |
download | gcc-e261fcefb71e1270673f0457fcc73711f13d3079.zip gcc-e261fcefb71e1270673f0457fcc73711f13d3079.tar.gz gcc-e261fcefb71e1270673f0457fcc73711f13d3079.tar.bz2 |
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.
Diffstat (limited to 'libgcc')
0 files changed, 0 insertions, 0 deletions