https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84353
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> --- I'm testing a cleanup/fix in this area but ultimatively we have no way of code-generating this 1:1 so unless we invent more magic pattern-matching a code-generating failure and thus late abort is the correct thing to do. We might want to revisit the fact that we punt on this by ICEing with -fchecking... Getting more testcase for this is nice though. Getting some brains inventing patterns we could detect to code-generate expressions like if (((-P_9 + 18446744073709551615) % 18446744073709551616) + P_1 <= 18446744073709551614 || ((-P_9 + 18446744073709551615) % 18446744073709551616) + P_1 >= 18446744073709551616) with a data type that cannot represent the above would be nice as well. Note that even a simple P_9 + P_9 might not be representable but wrap/overflow in the type we code-generate in (which is fixed! to be the "largest" integer type the target supports). So in reality some range information is needed which we _may_ be able to recover. Still there will be obviously corner-cases where we have to give up unless ISL can make guarantees on the value-space of IVs and parameter expressions it generates.
