aboutsummaryrefslogtreecommitdiff
path: root/libgcc
diff options
context:
space:
mode:
authorAldy Hernandez <aldyh@redhat.com>2023-02-02 18:08:44 +0100
committerAldy Hernandez <aldyh@redhat.com>2023-02-03 21:33:07 +0100
commite261fcefb71e1270673f0457fcc73711f13d3079 (patch)
treea63c6017ebeeeb2399abb409dc07ad3291534194 /libgcc
parent10bd26d6efe88a8cf03a6a325351bc470a910cab (diff)
downloadgcc-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