https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90240
--- Comment #4 from bin cheng <amker at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #3) > Graphite, so IMHO not a release blocker. but the issue is critical, it could happen with general optimization level for loop nest with huge scaling factor. So, find_optimal_iv_set_1 first chooses a candidate set, then makes different tries to do cost descent by modifying the candidate set. The facts are: 1) algorithm uses a global variable of following structure and keeps track of cost in place during computation. struct iv_ca { //... comp_cost cand_use_cost; //... comp_cost cost; }; 2) algorithm is heuristic, so it's possible to reach an intermediate state with higher cost. 3) as in previous comment, loop nest with huge scaling factor can easily result in infinite_cost. 4) once the global variable of iv_ca.{cand_use_cost, cost} reaches infinite_cost, ICE is the best thing could happen. We could replace gcc_assert with algorithm failure then give up ivopts, but IMHO that would miss quite lot of optimizations. The conclusion, candidate choosing algorithm doesn't work well with infinite_cost. I Don't know how to fix this trivially. For now, even restricting scaling factor is a practical change now. Will give it a try.