[Bug c/103451] New: crash at gcc/range-op.cc:1836

[Bug c/103451] New: crash at gcc/range-op.cc:1836

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451

            Bug ID: 103451
           Summary: crash at gcc/range-op.cc:1836
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C code:

int func_10_ptr_12;

void func_10(long li_8) 
{
  long *ptr_9 = &li_8;
  li_8 &= *ptr_9 / 0 ?: li_8;
  for (;;)
    func_10_ptr_12 &= 4 ? *ptr_9 : 4;
}

void func_9_s_8() 
{ 
  func_10(func_9_s_8); 
}

on recent gcc, does this:

$ /home/dcb/gcc/results/bin/gcc -c -O2 bug775.c
during IPA pass: inline
bug775.c: At top level:
bug775.c:14:1: internal compiler error: Segmentation fault
   14 | }
      | ^
0xdabcb9 crash_signal(int)
        ../../trunk.git/gcc/toplev.c:322
0x1c98f2f operator_div::wi_fold(irange&, tree_node*,
generic_wide_int<wide_int_storage> const&, generic_wide_int<wide_int_storage>
const&, generic_wide_int<wide_int_storage> const&,
generic_wide_int<wide_int_storage> const&) const
        ../../trunk.git/gcc/range-op.cc:1836

The bug first seems to occur sometime between git hash 415f9ee404dc9e8a
and 4a2007594cff78fb, a distance of 22 commits.

[Bug ipa/103451] [12 Regression] crash at gcc/range-op.cc:1836 since r12-5531-g1b0acc4b800b589a

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |ipa
   Target Milestone|---                         |12.0
           Priority|P3                          |P1
     Ever confirmed|0                           |1
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |marxin at gcc dot gnu.org
            Summary|crash at                    |[12 Regression] crash at
                   |gcc/range-op.cc:1836        |gcc/range-op.cc:1836 since
                   |                            |r12-5531-g1b0acc4b800b589a
   Last reconfirmed|                            |2021-11-27
             Status|UNCONFIRMED                 |NEW
      Known to fail|                            |12.0

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r12-5531-g1b0acc4b800b589a.

[Bug ipa/103451] [12 Regression] crash at gcc/range-op.cc:1836 since r12-5531-g1b0acc4b800b589a

[rguenth at gcc dot gnu.org]

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)

[Bug ipa/103451] [12 Regression] crash at gcc/range-op.cc:1836 since r12-5531-g1b0acc4b800b589a

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
>   // If flag_non_call_exceptions, we must not eliminate a division by zero.
>   if (cfun->can_throw_non_call_exceptions)

Note the check is too restrictive anyways, it should be:
  return (fun->can_throw_non_call_exceptions
          && !fun->can_delete_dead_exceptions

Like what is done in stmt_unremovable_because_of_non_call_eh_p. And yes go
defines can_delete_dead_exceptions to false.

[Bug ipa/103451] [12 Regression] crash at gcc/range-op.cc:1836 since r12-5531-g1b0acc4b800b589a

[aldyh at gcc dot gnu.org]

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.

> 
> 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 ;-)

commit 46dfa8ad6c18feb45d35734eae38798edb7c38cd
Author: Richard Biener <rguenther@suse.de>
Date:   Wed Sep 11 11:16:54 2019 +0000

    re PR tree-optimization/90387 (__builtin_constant_p and -Warray-bounds
warnings)

    2019-09-11  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/90387
            * vr-values.c (vr_values::extract_range_basic): After inlining
            simplify non-constant __builtin_constant_p to false.

            * gcc.dg/Warray-bounds-44.c: New testcase.

    From-SVN: r275639

[Bug ipa/103451] [12 Regression] crash at gcc/range-op.cc:1836 since r12-5531-g1b0acc4b800b589a

[rguenther at suse dot de]

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!)

[Bug ipa/103451] [12 Regression] crash at gcc/range-op.cc:1836 since r12-5531-g1b0acc4b800b589a

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |aldyh at gcc dot gnu.org

--- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---

> 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!)

Heh heh.  I wasn't blaming you.  It was just a coy way of saying "I don't know"
:-).

I'll investigate by first removing the code.

Thanks for your analysis.

[Bug ipa/103451] [12 Regression] crash at gcc/range-op.cc:1836 since r12-5531-g1b0acc4b800b589a

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zhendong.su at inf dot ethz.ch

--- Comment #7 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
*** Bug 103486 has been marked as a duplicate of this bug. ***

[Bug ipa/103451] [12 Regression] crash at gcc/range-op.cc:1836 since r12-5531-g1b0acc4b800b589a

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Aldy Hernandez <aldyh@gcc.gnu.org>:

https://gcc.gnu.org/g:f33fdda0b805ff6097f9f325d73a4b07e72170b0

commit r12-5615-gf33fdda0b805ff6097f9f325d73a4b07e72170b0
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Mon Nov 29 12:52:45 2021 +0100

    Remove can_throw_non_call_exceptions special case from
operator_div::wi_fold.

            PR tree-optimization/103451

    gcc/ChangeLog:

            * range-op.cc (operator_div::wi_fold): Remove
            can_throw_non_call_exceptions special case.
            * tree-ssa-sink.c (sink_code_in_bb): Same.

    gcc/testsuite/ChangeLog:

            * gcc.dg/pr103451.c: New test.

[Bug ipa/103451] [12 Regression] crash at gcc/range-op.cc:1836 since r12-5531-g1b0acc4b800b589a

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #9 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
fixed

[Bug ipa/103451] [12 Regression] crash at gcc/range-op.cc:1836 since r12-5531-g1b0acc4b800b589a

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451

--- Comment #10 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
*** Bug 103461 has been marked as a duplicate of this bug. ***