https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
--- Comment #9 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Jakub Jelinek from comment #8) > (In reply to Aldy Hernandez from comment #5) > > (In reply to Jakub Jelinek from comment #3) > > > Created attachment 54391 [details] > > > gcc13-pr108639.patch > > > > > > Untested fix. > > > > I think the problem is more fundamental than that. The equality operator > > for irange is not ICEing for the sub-range comparison (which also have > > different precision), but is dying in the nonzero mask comparison. > > Well, that is obvious, because for the actual range boundaries you compare > trees, not wide_ints. And operand_equal_p does allow comparing of trees > with different types. > It in that case calls tree_int_cst_equal. But when you switch the > boundaries from trees to wide_ints, they will ICE again as well. > > I think for the operator==, the important question is, shall ranges with > same values but non-compatible types compare > 1) equal > 2) non-equal > 3) be an ICE (e.g. gcc_checking_assert) > The current state is 3) without the assert and my patch was trying to fix > the caller. 3) is not a desired result for sure. I think 1) is our desired outcome... I initially considered 2) as desirable as we could simply check the types before doing any other work. As I thought about it tho, I can't think of any good reason why we would want them to be unequal. If they compare equal this way (ignoring type), then performing a cast on either of them to the same type as the other would also compare equal... its symmetrical so that actually makes them equal in my book.
