[Bug tree-optimization/106967] New: [13 Regression] ICE in upper_bound, at value-range.h:348

[Bug tree-optimization/106967] New: [13 Regression] ICE in upper_bound, at value-range.h:348

[asolokha at gmx dot com]

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

            Bug ID: 106967
           Summary: [13 Regression] ICE in upper_bound, at
                    value-range.h:348
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc 13.0.0 20220918 snapshot (g:313879d8768d08dea035efd7fd62b753dc91c364) ICEs
when compiling the following testcase, reduced from
gcc/testsuite/gcc.dg/pr29921-2.c, w/ -O2 -ffinite-math-only -fno-trapping-math
-fno-tree-dominator-opts:

void
foo (float x, int *y)
{
  int i;
  float sum2 = 0.0;

  for (i = 0; i < *y; ++i)
    sum2 += x;

  sum2 = 1.0 / sum2;
  if (sum2 * 0.0 < 5.E-5)
    *y = 0;
}

% gcc-13.0.0 -O2 -ffinite-math-only -fno-trapping-math -fno-tree-dominator-opts
-c skavkcop.c
during GIMPLE pass: thread
skavkcop.c: In function 'foo':
skavkcop.c:2:1: internal compiler error: in upper_bound, at value-range.h:348
    2 | foo (float x, int *y)
      | ^~~
0x86077a frange::upper_bound() const
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/value-range.h:348
0x86089c frange::upper_bound() const
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/tree.h:3643
0x86089c foperator_lt::fold_range(irange&, tree_node*, frange const&, frange
const&, relation_kind_t) const
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/range-op-float.cc:550
0x86089c foperator_lt::fold_range(irange&, tree_node*, frange const&, frange
const&, relation_kind_t) const
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/range-op-float.cc:541
0x1d407b7 fold_using_range::range_of_range_op(vrange&, gimple*, fur_source&)
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/gimple-range-fold.cc:634
0x1d438d0 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/gimple-range-fold.cc:555
0x1d43c9c fold_range(vrange&, gimple*, range_query*)
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/gimple-range-fold.cc:316
0x10a647d path_range_query::range_of_stmt(vrange&, gimple*, tree_node*)
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/gimple-range-path.cc:725
0x1130994 back_threader::find_taken_edge_cond(vec<basic_block_def*, va_heap,
vl_ptr> const&, gcond*)
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/tree-ssa-threadbackward.cc:334
0x1130b82 back_threader::maybe_register_path(back_threader_profitability&)
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/tree-ssa-threadbackward.cc:248
0x1131098 back_threader::find_paths_to_names(basic_block_def*, bitmap_head*,
unsigned int, back_threader_profitability&)
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/tree-ssa-threadbackward.cc:380
0x1131614 back_threader::find_paths_to_names(basic_block_def*, bitmap_head*,
unsigned int, back_threader_profitability&)
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/tree-ssa-threadbackward.cc:502
0x11320af back_threader::maybe_thread_block(basic_block_def*)
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/tree-ssa-threadbackward.cc:574
0x1132161 back_threader::thread_blocks()
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/tree-ssa-threadbackward.cc:1002
0x11321d3 execute
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/tree-ssa-threadbackward.cc:1104

[Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0

[Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348

[asolokha at gmx dot com]

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

--- Comment #1 from Arseny Solokha <asolokha at gmx dot com> ---
JFTH, a similar ICE in lower_bound is also possible. I currently have an F77
testcase, will try to get a C one.

[Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-09-20
                 CC|                            |aldyh at gcc dot gnu.org,
                   |                            |amacleod at redhat dot com,
                   |                            |marxin at gcc dot gnu.org
            Summary|[13 Regression] ICE in      |[13 Regression] ICE in
                   |upper_bound, at             |upper_bound, at
                   |value-range.h:348           |value-range.h:348 since
                   |                            |r13-2713-g917461478d3bb733
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r13-2713-g917461478d3bb733.

[Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733

[aldyh at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #3 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Hmmm, I haven't dug deep into this, but it seems PRE is creating a NAN, even
though -ffinite-math-only.  Is that right?

Created phi prephitmp_29 = PHI <_28(10),  Nan(9)>

This causes us to return TRUE for this, even though we could have a NAN.

static inline bool
finite_operands_p (const frange &op1, const frange &op2)
{
  return flag_finite_math_only || (!op1.maybe_isnan () && !op2.maybe_isnan ());
}

finite_operands_p() must be adjusted for the case where there is a NAN in the
source...but still.. is PRE supposed to be adding NANs?

[Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Dunno about PRE, but generally, one can't rule out NaNs or infinities in the IL
when -ffinite-math-only, all we can say is if those appear, it is undefined
behavior.  So, we can't ICE on those, but we are free to optimize as if those
paths weren't there.

[Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733

[aldyh at gcc dot gnu.org]

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

--- Comment #5 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Does that mean we can assume the incoming edge from BB9 as unreachable?

[Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733

[aldyh at gcc dot gnu.org]

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

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

> 
> finite_operands_p() must be adjusted for the case where there is a NAN in
> the source...but still.. is PRE supposed to be adding NANs?

What i meant to say here was the users of finite operands p must not assume
they have bounds even if this returned true. Users of lower and upper bound
must first very !undefined and !known_isnan.

[Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Yes.  Just treat the range from that edge as UNDEFINED.
If one says -ffinite-math-only and divides by zero, that isn't finite...

[Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733

[aldyh at gcc dot gnu.org]

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

--- Comment #8 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Created attachment 53595
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53595&action=edit
patch in testing

This was painful.  I had audit all the relational code to make sure we're
handling NANs before anything else.

[Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733

[aldyh at gcc dot gnu.org]

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

--- Comment #9 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Created attachment 53596
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53596&action=edit
another patch in testing

This one may be needed as well.

[Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733

[aldyh at gcc dot gnu.org]

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

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

[Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw,

static inline bool
finite_operands_p (const frange &op1, const frange &op2)
{
  return flag_finite_math_only || (!op1.maybe_isnan () && !op2.maybe_isnan
());
}

is wrong, you should either test HONOR_NANS on the range type or even
better, do this check in maybe_isnan ().

Btw, since you are "sanitizing" ranges at _set () time for other flag_*,
it might be good to simply do that for HONOR_NANS as well so we have a
single flag here and always ranges that do not need extra treatment?

[Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733

[aldyh at gcc dot gnu.org]

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

--- Comment #12 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #11)
> Btw,
> 
> static inline bool
> finite_operands_p (const frange &op1, const frange &op2)
> {
>   return flag_finite_math_only || (!op1.maybe_isnan () && !op2.maybe_isnan
> ());
> }
> 
> is wrong, you should either test HONOR_NANS on the range type or even
> better, do this check in maybe_isnan ().


Yeah, I need to revisit this.  My patch still stands though, as we need to
correctly handle definite NANs everywhere.  I'll come back to finite_operands_p
though.

> 
> Btw, since you are "sanitizing" ranges at _set () time for other flag_*,
> it might be good to simply do that for HONOR_NANS as well so we have a
> single flag here and always ranges that do not need extra treatment?

The problem here is that the NAN was explicitly set by a pass (i.e. it's in the
IL).  Although perhaps frange::set_nan() should just set UNDEFINED?  Is that
what you had in mind?

[Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733

[rguenther at suse dot de]

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

--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 21 Sep 2022, aldyh at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106967
> 
> --- Comment #12 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #11)
> > Btw,
> > 
> > static inline bool
> > finite_operands_p (const frange &op1, const frange &op2)
> > {
> >   return flag_finite_math_only || (!op1.maybe_isnan () && !op2.maybe_isnan
> > ());
> > }
> > 
> > is wrong, you should either test HONOR_NANS on the range type or even
> > better, do this check in maybe_isnan ().
> 
> 
> Yeah, I need to revisit this.  My patch still stands though, as we need to
> correctly handle definite NANs everywhere.  I'll come back to finite_operands_p
> though.
> 
> > 
> > Btw, since you are "sanitizing" ranges at _set () time for other flag_*,
> > it might be good to simply do that for HONOR_NANS as well so we have a
> > single flag here and always ranges that do not need extra treatment?
> 
> The problem here is that the NAN was explicitly set by a pass (i.e. it's in the
> IL).  Although perhaps frange::set_nan() should just set UNDEFINED?  Is that
> what you had in mind?

Yes.

[Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r13-2756-gd2278da1c3cb7bf8b3d96c86dbef2982bf4cc54a
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Tue Sep 20 16:19:14 2022 +0200

    [PR106967] frange: revamp relational operators for NANs.

    Since NANs can be inserted by other passes even for -ffinite-math-only,
    we can't depend on the flag to determine if a NAN is a possiblity.
    Instead, we must explicitly check for them.

    In the case of -ffinite-math-only, paths leading up to a NAN are
    undefined and can be considered unreachable.  I have audited all the
    relational code and made sure we're handling the known NAN case before
    anything else, setting undefined when appropriate.

    In the process, I revamped all the relational code handling NANs to
    correctly notice paths that are unreachable.

    The basic structure for ordered relational operators (except != of
    course) is this:

            If either operand is a known NAN, return FALSE.

            The true side of a relop when one operand is a NAN is
            unreachable.

            On the false side of a relop when one operand is a NAN, we
            know nothing about the other operand.

    Regstrapped on x86-64 and ppc64le Linux.
    lapack testing on x86-64 with and without -ffinite-math-only.

            PR tree-optimization/106967

    gcc/ChangeLog:

            * range-op-float.cc (foperator_equal::fold_range): Adjust for NAN.
            (foperator_equal::op1_range): Same.
            (foperator_not_equal::fold_range): Same.
            (foperator_not_equal::op1_range): Same.
            (foperator_lt::fold_range): Same.
            (foperator_lt::op1_range): Same.
            (foperator_lt::op2_range): Same.
            (foperator_le::fold_range): Same.
            (foperator_le::op1_range): Same.
            (foperator_le::op2_range): Same.
            (foperator_gt::fold_range): Same.
            (foperator_gt::op1_range): Same.
            (foperator_gt::op2_range): Same.
            (foperator_ge::fold_range): Same.
            (foperator_ge::op1_range): Same.
            (foperator_ge::op2_range): Same.
            (foperator_unordered::op1_range): Same.
            (foperator_ordered::fold_range): Same.
            (foperator_ordered::op1_range): Same.
            (build_le): Assert that we don't have a NAN.
            (build_lt): Same.
            (build_gt): Same.
            (build_ge): Same.

    gcc/testsuite/ChangeLog:

            * gcc.dg/tree-ssa/pr106967.c: New test.

[Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733

[aldyh at gcc dot gnu.org]

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

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

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

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

i'll addressed the suggestions by richi in another patch-- they're not needed
for correctness, so we can close this PR.

[Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r13-2761-gdc829c7613ddf562d1aecaf22eda965e87108ac8
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Wed Sep 21 11:18:48 2022 +0200

    [PR106967] Set known NANs to undefined for flag_finite_math_only.

    Explicit NANs in the IL can be treated as undefined for
    flag_finite_math_only.  This causes all the right things to happen wrt
    threading, folding, etc.  It also saves us special casing throughout.

            PR tree-optimization/106967

    gcc/ChangeLog:

            * value-range.cc (frange::set): Set known NANs to undefined for
            flag_finite_math_only.