public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/107668] New: [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int
@ 2022-11-13 19:36 zsojka at seznam dot cz
2022-11-13 21:01 ` [Bug tree-optimization/107668] " dcb314 at hotmail dot com
` (12 more replies)
0 siblings, 13 replies; 14+ messages in thread
From: zsojka at seznam dot cz @ 2022-11-13 19:36 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int
2022-11-13 19:36 [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
@ 2022-11-13 21:01 ` dcb314 at hotmail dot com
2022-11-13 21:32 ` dcb314 at hotmail dot com
` (11 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: dcb314 at hotmail dot com @ 2022-11-13 21:01 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int
2022-11-13 19:36 [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
2022-11-13 21:01 ` [Bug tree-optimization/107668] " dcb314 at hotmail dot com
@ 2022-11-13 21:32 ` dcb314 at hotmail dot com
2022-11-14 8:13 ` dcb314 at hotmail dot com
` (10 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: dcb314 at hotmail dot com @ 2022-11-13 21:32 UTC (permalink / raw)
To: gcc-bugs
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;
}
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int
2022-11-13 19:36 [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
2022-11-13 21:01 ` [Bug tree-optimization/107668] " dcb314 at hotmail dot com
2022-11-13 21:32 ` dcb314 at hotmail dot com
@ 2022-11-14 8:13 ` dcb314 at hotmail dot com
2022-11-14 8:34 ` dcb314 at hotmail dot com
` (9 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: dcb314 at hotmail dot com @ 2022-11-14 8:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107668
--- Comment #3 from David Binderman <dcb314 at hotmail dot com> ---
Trying git revision 2d5c4a16dd833aa0.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int
2022-11-13 19:36 [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
` (2 preceding siblings ...)
2022-11-14 8:13 ` dcb314 at hotmail dot com
@ 2022-11-14 8:34 ` dcb314 at hotmail dot com
2022-11-14 8:50 ` dcb314 at hotmail dot com
` (8 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: dcb314 at hotmail dot com @ 2022-11-14 8:34 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int
2022-11-13 19:36 [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
` (3 preceding siblings ...)
2022-11-14 8:34 ` dcb314 at hotmail dot com
@ 2022-11-14 8:50 ` dcb314 at hotmail dot com
2022-11-14 9:14 ` dcb314 at hotmail dot com
` (7 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: dcb314 at hotmail dot com @ 2022-11-14 8:50 UTC (permalink / raw)
To: gcc-bugs
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].
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int
2022-11-13 19:36 [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
` (4 preceding siblings ...)
2022-11-14 8:50 ` dcb314 at hotmail dot com
@ 2022-11-14 9:14 ` dcb314 at hotmail dot com
2022-11-14 14:04 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: dcb314 at hotmail dot com @ 2022-11-14 9:14 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int
2022-11-13 19:36 [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
` (5 preceding siblings ...)
2022-11-14 9:14 ` dcb314 at hotmail dot com
@ 2022-11-14 14:04 ` rguenth at gcc dot gnu.org
2022-11-14 14:28 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-11-14 14:04 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int
2022-11-13 19:36 [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
` (6 preceding siblings ...)
2022-11-14 14:04 ` rguenth at gcc dot gnu.org
@ 2022-11-14 14:28 ` jakub at gcc dot gnu.org
2022-11-15 8:19 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-11-14 14:28 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int
2022-11-13 19:36 [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
` (7 preceding siblings ...)
2022-11-14 14:28 ` jakub at gcc dot gnu.org
@ 2022-11-15 8:19 ` jakub at gcc dot gnu.org
2022-11-15 8:29 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-11-15 8:19 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int
2022-11-13 19:36 [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
` (8 preceding siblings ...)
2022-11-15 8:19 ` jakub at gcc dot gnu.org
@ 2022-11-15 8:29 ` jakub at gcc dot gnu.org
2022-11-15 16:26 ` aldyh at gcc dot gnu.org
` (2 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-11-15 8:29 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int
2022-11-13 19:36 [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
` (9 preceding siblings ...)
2022-11-15 8:29 ` jakub at gcc dot gnu.org
@ 2022-11-15 16:26 ` aldyh at gcc dot gnu.org
2022-11-16 6:36 ` cvs-commit at gcc dot gnu.org
2022-11-16 8:23 ` jakub at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: aldyh at gcc dot gnu.org @ 2022-11-15 16:26 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int
2022-11-13 19:36 [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
` (10 preceding siblings ...)
2022-11-15 16:26 ` aldyh at gcc dot gnu.org
@ 2022-11-16 6:36 ` cvs-commit at gcc dot gnu.org
2022-11-16 8:23 ` jakub at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-11-16 6:36 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int
2022-11-13 19:36 [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
` (11 preceding siblings ...)
2022-11-16 6:36 ` cvs-commit at gcc dot gnu.org
@ 2022-11-16 8:23 ` jakub at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-11-16 8:23 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2022-11-16 8:23 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-13 19:36 [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
2022-11-13 21:01 ` [Bug tree-optimization/107668] " dcb314 at hotmail dot com
2022-11-13 21:32 ` dcb314 at hotmail dot com
2022-11-14 8:13 ` dcb314 at hotmail dot com
2022-11-14 8:34 ` dcb314 at hotmail dot com
2022-11-14 8:50 ` dcb314 at hotmail dot com
2022-11-14 9:14 ` dcb314 at hotmail dot com
2022-11-14 14:04 ` rguenth at gcc dot gnu.org
2022-11-14 14:28 ` jakub at gcc dot gnu.org
2022-11-15 8:19 ` jakub at gcc dot gnu.org
2022-11-15 8:29 ` jakub at gcc dot gnu.org
2022-11-15 16:26 ` aldyh at gcc dot gnu.org
2022-11-16 6:36 ` cvs-commit at gcc dot gnu.org
2022-11-16 8:23 ` jakub at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).