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)
