https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451
--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 29 Nov 2021, aldyh at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451 > > --- Comment #4 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #2) > > 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 honestly can't remember what the rationale was for checking > can_throw_non_call_exceptions. Perhaps this got added to catch some > testcase? > My gut feeling is that we should be fixing whatever issue upstream, but !cfun > || ... seems quite harmless. Yes, I'd try just removing the code first ... > > > > 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) > > This one came from the old vr-values.c code, so you may have better insight > here ;-) Well, yeah - but at that point it wasn't exposed as API to IPA passes. As said, !cfun || ... looks correct here (if in IPA context inlining hasn't completed!)
