https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aldyh at gcc dot gnu.org, | |amacleod at redhat dot com, | |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> --- So range-op.cc eventually wants to look at 'cfun' which of course is a non-go in IPA context. void operator_div::wi_fold (irange &r, tree type, const wide_int &lh_lb, const wide_int &lh_ub, const wide_int &rh_lb, const wide_int &rh_ub) const { ... // If flag_non_call_exceptions, we must not eliminate a division by zero. if (cfun->can_throw_non_call_exceptions) { r.set_varying (type); return; I'm not sure wi_fold should care about "eliminating a division", but surely even for non-call EH the actual range of the result doesn't need to care. So if sth goes wrong when eliding the above it needs to be fixed upthread instead? Otherwise a "quick" workaround for the ICE is to check !cfun || ... and be conservative. I see there's no state associated with range_fold_binary_expr where the IPA context could pass down relevant can_throw_non_call_exceptions. I also see bool fold_using_range::range_of_builtin_call (irange &r, gcall *call, fur_source &src) ... if (cfun->after_inlining) { r.set_zero (type); which might have similar problems (!cfun || ... looks quite reasonable there)