[Bug tree-optimization/84353] [8/9 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206

[rguenth at gcc dot gnu.org]

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.