[Bug tree-optimization/107668] New: [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int

[Bug tree-optimization/107668] New: [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int

[zsojka at seznam dot cz]

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

            Bug ID: 107668
           Summary: [13 Regression] ICE: in clear_nan, at
                    value-range.h:1167 with -fsanitize=float-cast-overflow
                    and _Complex int
           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: zsojka at seznam dot cz
  Target Milestone: ---
              Host: x86_64-pc-linux-gnu

Two examples:
$ cat testcase.c
_Complex short c;

void
foo (void)
{
  c *= (_Complex) 5;
}
$ x86_64-pc-linux-gnu-gcc -Ofast -fsanitize=float-cast-overflow
-fno-guess-branch-probability -fsigned-zeros testcase.c 
cc1: warning: '-fassociative-math' disabled; other options take precedence
during GIMPLE pass: thread
testcase.c: In function 'foo':
testcase.c:4:1: internal compiler error: in clear_nan, at value-range.h:1167
    4 | foo (void)
      | ^~~
0xd1af22 frange::clear_nan()
        /repo/gcc-trunk/gcc/value-range.h:1167
0xd1b0de frange::clear_nan()
        /repo/gcc-trunk/gcc/value-range.h:1127
0xd1b0de float_binary_op_range_finish
        /repo/gcc-trunk/gcc/range-op-float.cc:1904
0x2568f53 float_binary_op_range_finish
        /repo/gcc-trunk/gcc/range-op-float.cc:1886
0x2568f53 foperator_mult::op1_range(frange&, tree_node*, frange const&, frange
const&, relation_trio) const
        /repo/gcc-trunk/gcc/range-op-float.cc:2143
0x24414d7 gori_compute::compute_operand1_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
        /repo/gcc-trunk/gcc/gimple-range-gori.cc:1095
0x2440193 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
        /repo/gcc-trunk/gcc/gimple-range-gori.cc:692
0x2441e2f gori_compute::compute_operand2_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
        /repo/gcc-trunk/gcc/gimple-range-gori.cc:1243
0x24408ca gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
        /repo/gcc-trunk/gcc/gimple-range-gori.cc:694
0x2441553 gori_compute::compute_operand1_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
        /repo/gcc-trunk/gcc/gimple-range-gori.cc:1150
0x2440193 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
        /repo/gcc-trunk/gcc/gimple-range-gori.cc:692
0x243ff7b gori_compute::compute_logical_operands(vrange&, vrange&,
gimple_range_op_handler&, irange const&, tree_node*, fur_source&, tree_node*,
bool)
        /repo/gcc-trunk/gcc/gimple-range-gori.cc:917
0x2440750 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
        /repo/gcc-trunk/gcc/gimple-range-gori.cc:674
0x2441553 gori_compute::compute_operand1_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
        /repo/gcc-trunk/gcc/gimple-range-gori.cc:1150
0x2440193 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
        /repo/gcc-trunk/gcc/gimple-range-gori.cc:692
0x2443ee2 gori_compute::outgoing_edge_range_p(vrange&, edge_def*, tree_node*,
range_query&)
        /repo/gcc-trunk/gcc/gimple-range-gori.cc:1373
0x159a3e5 path_range_query::compute_ranges_in_block(basic_block_def*)
        /repo/gcc-trunk/gcc/gimple-range-path.cc:454
0x159aa92 path_range_query::compute_ranges(bitmap_head const*)
        /repo/gcc-trunk/gcc/gimple-range-path.cc:622
0x16205d9 back_threader::find_taken_edge_cond(vec<basic_block_def*, va_heap,
vl_ptr> const&, gcond*)
        /repo/gcc-trunk/gcc/tree-ssa-threadbackward.cc:324
0x162078e back_threader::maybe_register_path(back_threader_profitability&)
        /repo/gcc-trunk/gcc/tree-ssa-threadbackward.cc:248
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See https://gcc.gnu.org/bugs/ for instructions.


$ cat testcase.c
_Complex int c;
int i;

void
foo (void)
{
  c /= (_Complex) i;
}
$ x86_64-pc-linux-gnu-gcc -Os -ffinite-math-only -fsanitize=float-cast-overflow
-fcx-fortran-rules testcase.c 
during GIMPLE pass: dom
testcase.c: In function 'foo':
testcase.c:5:1: internal compiler error: in clear_nan, at value-range.h:1167
    5 | foo (void)
      | ^~~
0xd1af22 frange::clear_nan()
        /repo/gcc-trunk/gcc/value-range.h:1167
0xd1b0de frange::clear_nan()
        /repo/gcc-trunk/gcc/value-range.h:1127
0xd1b0de float_binary_op_range_finish
        /repo/gcc-trunk/gcc/range-op-float.cc:1904
0x2568f53 float_binary_op_range_finish
        /repo/gcc-trunk/gcc/range-op-float.cc:1886
0x2568f53 foperator_mult::op1_range(frange&, tree_node*, frange const&, frange
const&, relation_trio) const
        /repo/gcc-trunk/gcc/range-op-float.cc:2143
0x24414d7 gori_compute::compute_operand1_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
        /repo/gcc-trunk/gcc/gimple-range-gori.cc:1095
0x2440193 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
        /repo/gcc-trunk/gcc/gimple-range-gori.cc:692
0x2441e2f gori_compute::compute_operand2_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
        /repo/gcc-trunk/gcc/gimple-range-gori.cc:1243
0x24408ca gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
        /repo/gcc-trunk/gcc/gimple-range-gori.cc:694
0x2441e2f gori_compute::compute_operand2_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
        /repo/gcc-trunk/gcc/gimple-range-gori.cc:1243
0x24423b2 gori_compute::compute_operand1_and_operand2_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
        /repo/gcc-trunk/gcc/gimple-range-gori.cc:1263
0x2440ac0 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
        /repo/gcc-trunk/gcc/gimple-range-gori.cc:689
0x2441553 gori_compute::compute_operand1_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
        /repo/gcc-trunk/gcc/gimple-range-gori.cc:1150
0x2440193 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
        /repo/gcc-trunk/gcc/gimple-range-gori.cc:692
0x243fe91 gori_compute::compute_logical_operands(vrange&, vrange&,
gimple_range_op_handler&, irange const&, tree_node*, fur_source&, tree_node*,
bool)
        /repo/gcc-trunk/gcc/gimple-range-gori.cc:935
0x2440750 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
        /repo/gcc-trunk/gcc/gimple-range-gori.cc:674
0x2441553 gori_compute::compute_operand1_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
        /repo/gcc-trunk/gcc/gimple-range-gori.cc:1150
0x2440193 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
        /repo/gcc-trunk/gcc/gimple-range-gori.cc:692
0x2443ee2 gori_compute::outgoing_edge_range_p(vrange&, edge_def*, tree_node*,
range_query&)
        /repo/gcc-trunk/gcc/gimple-range-gori.cc:1373
0x2434dee ranger_cache::edge_range(vrange&, edge_def*, tree_node*,
ranger_cache::rfd_mode)
        /repo/gcc-trunk/gcc/gimple-range-cache.cc:964
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See https://gcc.gnu.org/bugs/ for instructions.


$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-3944-20221113164720-g43435c7eb0f-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-3944-20221113164720-g43435c7eb0f-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20221113 (experimental) (GCC)

[Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int

[dcb314 at hotmail dot com]

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

David Binderman <dcb314 at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dcb314 at hotmail dot com

--- Comment #1 from David Binderman <dcb314 at hotmail dot com> ---
I see this also in C++ code with flags -O1 -march=znver3 -ffast-math.

The problem first seems to occur sometime between git hash 52672be7d328df50
and 05432288d4e56055, some 28 commits later.

I have a cvise job running.

[Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int

[dcb314 at hotmail dot com]

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

--- Comment #2 from David Binderman <dcb314 at hotmail dot com> ---
Reduced C++ code seems to be:

--- /home/dcb36/cvise/bug862.cc ---
float dot();
float intersectcylinder_md;
void intersectcylinder(float &dist) {
  float nd = dot();
  dist = 0 / nd;
  float offset = intersectcylinder_md + dist;
  if (offset < 0)
    dist = nd;
}

[Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman <dcb314 at hotmail dot com> ---
Trying git revision 2d5c4a16dd833aa0.

[Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int

[dcb314 at hotmail dot com]

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

--- Comment #4 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to David Binderman from comment #3)
> Trying git revision 2d5c4a16dd833aa0.

That looks good. Trying 59a63247992eb131.

[Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int

[dcb314 at hotmail dot com]

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

--- Comment #5 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to David Binderman from comment #4)
> (In reply to David Binderman from comment #3)
> > Trying git revision 2d5c4a16dd833aa0.
> 
> That looks good. Trying 59a63247992eb131.

Looks bad. Trying 2a193e9df82917ea. 

Range is currently [2d5c4a16dd833aa0..59a63247992eb131].

[Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int

[dcb314 at hotmail dot com]

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

--- Comment #6 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to David Binderman from comment #5)
> (In reply to David Binderman from comment #4)
> > (In reply to David Binderman from comment #3)
> > > Trying git revision 2d5c4a16dd833aa0.
> > 
> > That looks good. Trying 59a63247992eb131.
> 
> Looks bad. Trying 2a193e9df82917ea. 
> 
> Range is currently [2d5c4a16dd833aa0..59a63247992eb131].

2a193e9df82917ea looks bad. I could try d4c2f1d376da6fc3,
but the current range is 2d5c4a16dd833aa0..2a193e9df82917ea,
and they are all Jakub's revisions.

Over to Jakub for his best advice.

[Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
   Target Milestone|---                         |13.0

[Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-11-14
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
             Status|UNCONFIRMED                 |ASSIGNED
     Ever confirmed|0                           |1
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 53895
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53895&action=edit
gcc13-pr107668.patch

Untested fix.

[Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
While the patch passed bootstrap/regtest, I'm afraid it is not correct.

What we have is lhs = op1 * 0.0; with range of lhs [-0.0, 0.0] and range of
op2 [0.0, 0.0] and we call fop_mult.op1_range to determine range of op1.
Now, if it would be HONOR_NANS, the division lhs / op2 aka [-0.0, 0.0] / [0.0,
0.0] would compute NAN and float_binary_op_range_finish would take the:
  // If we get a known NAN from reverse op, it means either that
  // the other operand was known NAN (in that case we know nothing),
  // or the reverse operation introduced a known NAN.
  // Say for lhs = op1 * op2 if lhs is [-0, +0] and op2 is too,
  // 0 / 0 is known NAN.  Just punt in that case.
  // Or if lhs is a known NAN, we also don't know anything.
  if (r.known_isnan () || lhs.known_isnan ())
    {
      r.set_varying (type);
      return true;
    }
path.  VARYING is the range we want in this case btw, because anything times
0.0
is 0.0 or -0.0 (well, if INF/NANs are honored, we could make it [-MAX, MAX], or
if honoring signed zeros and lhs range would be just [0.0, 0.0] or [-0.0, -0.0]
or op2 one of these it could be even [-MAX, -0.0] or [0.0, MAX].
But because NANs aren't honored and INFs neither, we get from [-0.0, 0.0] /
[0.0, 0.0] division UNDEFINED range (NAN with NAN removed).
So, a safe fix would be to handle r.undefined_p () the same as r.known_isnan ()
or lhs.known_isnan () and if we want to eventually improve the op[12]_range
calls for individual ops for some special cases, we can.

Aldy, thoughts on this?

[Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #53895|0                           |1
        is obsolete|                            |

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 53899
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53899&action=edit
gcc13-pr107668.patch

Same in patch form.

[Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int

[aldyh at gcc dot gnu.org]

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

--- Comment #10 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #8)
> While the patch passed bootstrap/regtest, I'm afraid it is not correct.
> 
> What we have is lhs = op1 * 0.0; with range of lhs [-0.0, 0.0] and range of
> op2 [0.0, 0.0] and we call fop_mult.op1_range to determine range of op1.
> Now, if it would be HONOR_NANS, the division lhs / op2 aka [-0.0, 0.0] /
> [0.0, 0.0] would compute NAN and float_binary_op_range_finish would take the:
>   // If we get a known NAN from reverse op, it means either that
>   // the other operand was known NAN (in that case we know nothing),
>   // or the reverse operation introduced a known NAN.
>   // Say for lhs = op1 * op2 if lhs is [-0, +0] and op2 is too,
>   // 0 / 0 is known NAN.  Just punt in that case.
>   // Or if lhs is a known NAN, we also don't know anything.
>   if (r.known_isnan () || lhs.known_isnan ())
>     {
>       r.set_varying (type);
>       return true;
>     }
> path.  VARYING is the range we want in this case btw, because anything times
> 0.0
> is 0.0 or -0.0 (well, if INF/NANs are honored, we could make it [-MAX, MAX],
> or
> if honoring signed zeros and lhs range would be just [0.0, 0.0] or [-0.0,
> -0.0]
> or op2 one of these it could be even [-MAX, -0.0] or [0.0, MAX].
> But because NANs aren't honored and INFs neither, we get from [-0.0, 0.0] /
> [0.0, 0.0] division UNDEFINED range (NAN with NAN removed).
> So, a safe fix would be to handle r.undefined_p () the same as r.known_isnan
> () or lhs.known_isnan () and if we want to eventually improve the
> op[12]_range
> calls for individual ops for some special cases, we can.
> 
> Aldy, thoughts on this?

OMG, head hurts on this one.

Yeah, op1 could have been anything so varying seems like the right thing to do.

I was curious if we were doing something in operator_div::op1_range for
integers, but we haven't even thought that far :).

OK for trunk btw.

[Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:7c6cd9c05efca29a1a9635b81c86cbad25bbdbbe

commit r13-4081-g7c6cd9c05efca29a1a9635b81c86cbad25bbdbbe
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Nov 16 07:30:07 2022 +0100

    ragen-op-float: Fix up float_binary_op_range_finish [PR107668]

    The following testcase ICEs, because when !HONOR_NANS but
    HONOR_SIGNED_ZEROS, if we see
    lhs = op1 * op2;
    and know that lhs is [-0.0, 0.0] and op2 is [0.0, 0.0], the
    division of these two yields UNDEFINED and clear_nan () on it
    fails an assert.  With HONOR_NANS it would actually result in
    a known NAN, but when NANs aren't honored, we clear the NAN bits.
    Now, for the above case we actually don't know anything about
    the op1 range (except that it isn't a NAN/INF because of
    !HONOR_NANS !HONOR_INFINITIES), so I think the best is just
    to return VARYING for the case we get UNDEFINED as well.

    If we want, the op[12]_range methods perhaps can handle the
    corner cases earlier separately, say for
    lhs [0.0, 0.0] and op2 [0.0, 0.0] when HONOR_SIGNED_ZEROS this
    would be just [0.0, MAX].

    2022-11-16  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/107668
            * range-op-float.cc (float_binary_op_range_finish): Set VARYING
            also when r is UNDEFINED.

            * gcc.dg/ubsan/pr107668.c: New test.

[Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.