https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (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. Your patch is changing it to 1), in that case no change would be needed in the particular lh == rh user, but are we sure that everywhere where non-compatible types could appear we don't imply from operator== returning true that the types are actually the same? If we did 2) e.g. by adding a types_compatible_p (type (), b.type ()) check, then we'd need to change this lh == rh user too, because for the shifts we really just care about values and not the exact types which can differ.
