public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/106967] New: [13 Regression] ICE in upper_bound, at value-range.h:348
@ 2022-09-19 12:10 asolokha at gmx dot com
2022-09-19 16:16 ` [Bug tree-optimization/106967] " pinskia at gcc dot gnu.org
` (16 more replies)
0 siblings, 17 replies; 18+ messages in thread
From: asolokha at gmx dot com @ 2022-09-19 12:10 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348
2022-09-19 12:10 [Bug tree-optimization/106967] New: [13 Regression] ICE in upper_bound, at value-range.h:348 asolokha at gmx dot com
@ 2022-09-19 16:16 ` pinskia at gcc dot gnu.org
2022-09-20 2:28 ` asolokha at gmx dot com
` (15 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-09-19 16:16 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348
2022-09-19 12:10 [Bug tree-optimization/106967] New: [13 Regression] ICE in upper_bound, at value-range.h:348 asolokha at gmx dot com
2022-09-19 16:16 ` [Bug tree-optimization/106967] " pinskia at gcc dot gnu.org
@ 2022-09-20 2:28 ` asolokha at gmx dot com
2022-09-20 8:39 ` [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
` (14 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: asolokha at gmx dot com @ 2022-09-20 2:28 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733
2022-09-19 12:10 [Bug tree-optimization/106967] New: [13 Regression] ICE in upper_bound, at value-range.h:348 asolokha at gmx dot com
2022-09-19 16:16 ` [Bug tree-optimization/106967] " pinskia at gcc dot gnu.org
2022-09-20 2:28 ` asolokha at gmx dot com
@ 2022-09-20 8:39 ` marxin at gcc dot gnu.org
2022-09-20 9:16 ` aldyh at gcc dot gnu.org
` (13 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: marxin at gcc dot gnu.org @ 2022-09-20 8:39 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733
2022-09-19 12:10 [Bug tree-optimization/106967] New: [13 Regression] ICE in upper_bound, at value-range.h:348 asolokha at gmx dot com
` (2 preceding siblings ...)
2022-09-20 8:39 ` [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
@ 2022-09-20 9:16 ` aldyh at gcc dot gnu.org
2022-09-20 9:24 ` jakub at gcc dot gnu.org
` (12 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: aldyh at gcc dot gnu.org @ 2022-09-20 9:16 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733
2022-09-19 12:10 [Bug tree-optimization/106967] New: [13 Regression] ICE in upper_bound, at value-range.h:348 asolokha at gmx dot com
` (3 preceding siblings ...)
2022-09-20 9:16 ` aldyh at gcc dot gnu.org
@ 2022-09-20 9:24 ` jakub at gcc dot gnu.org
2022-09-20 9:46 ` aldyh at gcc dot gnu.org
` (11 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-09-20 9:24 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733
2022-09-19 12:10 [Bug tree-optimization/106967] New: [13 Regression] ICE in upper_bound, at value-range.h:348 asolokha at gmx dot com
` (4 preceding siblings ...)
2022-09-20 9:24 ` jakub at gcc dot gnu.org
@ 2022-09-20 9:46 ` aldyh at gcc dot gnu.org
2022-09-20 9:50 ` aldyh at gcc dot gnu.org
` (10 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: aldyh at gcc dot gnu.org @ 2022-09-20 9:46 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733
2022-09-19 12:10 [Bug tree-optimization/106967] New: [13 Regression] ICE in upper_bound, at value-range.h:348 asolokha at gmx dot com
` (5 preceding siblings ...)
2022-09-20 9:46 ` aldyh at gcc dot gnu.org
@ 2022-09-20 9:50 ` aldyh at gcc dot gnu.org
2022-09-20 10:18 ` jakub at gcc dot gnu.org
` (9 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: aldyh at gcc dot gnu.org @ 2022-09-20 9:50 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733
2022-09-19 12:10 [Bug tree-optimization/106967] New: [13 Regression] ICE in upper_bound, at value-range.h:348 asolokha at gmx dot com
` (6 preceding siblings ...)
2022-09-20 9:50 ` aldyh at gcc dot gnu.org
@ 2022-09-20 10:18 ` jakub at gcc dot gnu.org
2022-09-20 14:33 ` aldyh at gcc dot gnu.org
` (8 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-09-20 10:18 UTC (permalink / raw)
To: gcc-bugs
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...
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733
2022-09-19 12:10 [Bug tree-optimization/106967] New: [13 Regression] ICE in upper_bound, at value-range.h:348 asolokha at gmx dot com
` (7 preceding siblings ...)
2022-09-20 10:18 ` jakub at gcc dot gnu.org
@ 2022-09-20 14:33 ` aldyh at gcc dot gnu.org
2022-09-20 14:34 ` aldyh at gcc dot gnu.org
` (7 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: aldyh at gcc dot gnu.org @ 2022-09-20 14:33 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733
2022-09-19 12:10 [Bug tree-optimization/106967] New: [13 Regression] ICE in upper_bound, at value-range.h:348 asolokha at gmx dot com
` (8 preceding siblings ...)
2022-09-20 14:33 ` aldyh at gcc dot gnu.org
@ 2022-09-20 14:34 ` aldyh at gcc dot gnu.org
2022-09-20 14:38 ` aldyh at gcc dot gnu.org
` (6 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: aldyh at gcc dot gnu.org @ 2022-09-20 14:34 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733
2022-09-19 12:10 [Bug tree-optimization/106967] New: [13 Regression] ICE in upper_bound, at value-range.h:348 asolokha at gmx dot com
` (9 preceding siblings ...)
2022-09-20 14:34 ` aldyh at gcc dot gnu.org
@ 2022-09-20 14:38 ` aldyh at gcc dot gnu.org
2022-09-21 7:10 ` rguenth at gcc dot gnu.org
` (5 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: aldyh at gcc dot gnu.org @ 2022-09-20 14:38 UTC (permalink / raw)
To: gcc-bugs
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. ***
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733
2022-09-19 12:10 [Bug tree-optimization/106967] New: [13 Regression] ICE in upper_bound, at value-range.h:348 asolokha at gmx dot com
` (10 preceding siblings ...)
2022-09-20 14:38 ` aldyh at gcc dot gnu.org
@ 2022-09-21 7:10 ` rguenth at gcc dot gnu.org
2022-09-21 7:41 ` aldyh at gcc dot gnu.org
` (4 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-09-21 7:10 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733
2022-09-19 12:10 [Bug tree-optimization/106967] New: [13 Regression] ICE in upper_bound, at value-range.h:348 asolokha at gmx dot com
` (11 preceding siblings ...)
2022-09-21 7:10 ` rguenth at gcc dot gnu.org
@ 2022-09-21 7:41 ` aldyh at gcc dot gnu.org
2022-09-21 7:44 ` rguenther at suse dot de
` (3 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: aldyh at gcc dot gnu.org @ 2022-09-21 7:41 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733
2022-09-19 12:10 [Bug tree-optimization/106967] New: [13 Regression] ICE in upper_bound, at value-range.h:348 asolokha at gmx dot com
` (12 preceding siblings ...)
2022-09-21 7:41 ` aldyh at gcc dot gnu.org
@ 2022-09-21 7:44 ` rguenther at suse dot de
2022-09-21 9:08 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: rguenther at suse dot de @ 2022-09-21 7:44 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733
2022-09-19 12:10 [Bug tree-optimization/106967] New: [13 Regression] ICE in upper_bound, at value-range.h:348 asolokha at gmx dot com
` (13 preceding siblings ...)
2022-09-21 7:44 ` rguenther at suse dot de
@ 2022-09-21 9:08 ` cvs-commit at gcc dot gnu.org
2022-09-21 9:10 ` aldyh at gcc dot gnu.org
2022-09-21 11:33 ` cvs-commit at gcc dot gnu.org
16 siblings, 0 replies; 18+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-09-21 9:08 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733
2022-09-19 12:10 [Bug tree-optimization/106967] New: [13 Regression] ICE in upper_bound, at value-range.h:348 asolokha at gmx dot com
` (14 preceding siblings ...)
2022-09-21 9:08 ` cvs-commit at gcc dot gnu.org
@ 2022-09-21 9:10 ` aldyh at gcc dot gnu.org
2022-09-21 11:33 ` cvs-commit at gcc dot gnu.org
16 siblings, 0 replies; 18+ messages in thread
From: aldyh at gcc dot gnu.org @ 2022-09-21 9:10 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733
2022-09-19 12:10 [Bug tree-optimization/106967] New: [13 Regression] ICE in upper_bound, at value-range.h:348 asolokha at gmx dot com
` (15 preceding siblings ...)
2022-09-21 9:10 ` aldyh at gcc dot gnu.org
@ 2022-09-21 11:33 ` cvs-commit at gcc dot gnu.org
16 siblings, 0 replies; 18+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-09-21 11:33 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2022-09-21 11:33 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-19 12:10 [Bug tree-optimization/106967] New: [13 Regression] ICE in upper_bound, at value-range.h:348 asolokha at gmx dot com
2022-09-19 16:16 ` [Bug tree-optimization/106967] " pinskia at gcc dot gnu.org
2022-09-20 2:28 ` asolokha at gmx dot com
2022-09-20 8:39 ` [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
2022-09-20 9:16 ` aldyh at gcc dot gnu.org
2022-09-20 9:24 ` jakub at gcc dot gnu.org
2022-09-20 9:46 ` aldyh at gcc dot gnu.org
2022-09-20 9:50 ` aldyh at gcc dot gnu.org
2022-09-20 10:18 ` jakub at gcc dot gnu.org
2022-09-20 14:33 ` aldyh at gcc dot gnu.org
2022-09-20 14:34 ` aldyh at gcc dot gnu.org
2022-09-20 14:38 ` aldyh at gcc dot gnu.org
2022-09-21 7:10 ` rguenth at gcc dot gnu.org
2022-09-21 7:41 ` aldyh at gcc dot gnu.org
2022-09-21 7:44 ` rguenther at suse dot de
2022-09-21 9:08 ` cvs-commit at gcc dot gnu.org
2022-09-21 9:10 ` aldyh at gcc dot gnu.org
2022-09-21 11:33 ` cvs-commit 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).