* [Bug ipa/103451] [12 Regression] crash at gcc/range-op.cc:1836 since r12-5531-g1b0acc4b800b589a
2021-11-27 9:10 [Bug c/103451] New: crash at gcc/range-op.cc:1836 dcb314 at hotmail dot com
@ 2021-11-27 11:14 ` marxin at gcc dot gnu.org
2021-11-29 7:36 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-11-27 11:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|c |ipa
Target Milestone|--- |12.0
Priority|P3 |P1
Ever confirmed|0 |1
CC| |hubicka at gcc dot gnu.org,
| |marxin at gcc dot gnu.org
Summary|crash at |[12 Regression] crash at
|gcc/range-op.cc:1836 |gcc/range-op.cc:1836 since
| |r12-5531-g1b0acc4b800b589a
Last reconfirmed| |2021-11-27
Status|UNCONFIRMED |NEW
Known to fail| |12.0
--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r12-5531-g1b0acc4b800b589a.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug ipa/103451] [12 Regression] crash at gcc/range-op.cc:1836 since r12-5531-g1b0acc4b800b589a
2021-11-27 9:10 [Bug c/103451] New: crash at gcc/range-op.cc:1836 dcb314 at hotmail dot com
2021-11-27 11:14 ` [Bug ipa/103451] [12 Regression] crash at gcc/range-op.cc:1836 since r12-5531-g1b0acc4b800b589a marxin at gcc dot gnu.org
@ 2021-11-29 7:36 ` rguenth at gcc dot gnu.org
2021-11-29 8:12 ` pinskia at gcc dot gnu.org
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-11-29 7:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aldyh at gcc dot gnu.org,
| |amacleod at redhat dot com,
| |rguenth at gcc dot gnu.org
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
So range-op.cc eventually wants to look at 'cfun' which of course is a non-go
in IPA context.
void
operator_div::wi_fold (irange &r, tree type,
const wide_int &lh_lb, const wide_int &lh_ub,
const wide_int &rh_lb, const wide_int &rh_ub) const
{
...
// If flag_non_call_exceptions, we must not eliminate a division by zero.
if (cfun->can_throw_non_call_exceptions)
{
r.set_varying (type);
return;
I'm not sure wi_fold should care about "eliminating a division", but surely
even for non-call EH the actual range of the result doesn't need to care.
So if sth goes wrong when eliding the above it needs to be fixed upthread
instead?
Otherwise a "quick" workaround for the ICE is to check !cfun || ... and
be conservative. I see there's no state associated with range_fold_binary_expr
where the IPA context could pass down relevant can_throw_non_call_exceptions.
I also see
bool
fold_using_range::range_of_builtin_call (irange &r, gcall *call,
fur_source &src)
...
if (cfun->after_inlining)
{
r.set_zero (type);
which might have similar problems (!cfun || ... looks quite reasonable there)
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug ipa/103451] [12 Regression] crash at gcc/range-op.cc:1836 since r12-5531-g1b0acc4b800b589a
2021-11-27 9:10 [Bug c/103451] New: crash at gcc/range-op.cc:1836 dcb314 at hotmail dot com
2021-11-27 11:14 ` [Bug ipa/103451] [12 Regression] crash at gcc/range-op.cc:1836 since r12-5531-g1b0acc4b800b589a marxin at gcc dot gnu.org
2021-11-29 7:36 ` rguenth at gcc dot gnu.org
@ 2021-11-29 8:12 ` pinskia at gcc dot gnu.org
2021-11-29 8:49 ` aldyh at gcc dot gnu.org
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-11-29 8:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451
--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
> // If flag_non_call_exceptions, we must not eliminate a division by zero.
> if (cfun->can_throw_non_call_exceptions)
Note the check is too restrictive anyways, it should be:
return (fun->can_throw_non_call_exceptions
&& !fun->can_delete_dead_exceptions
Like what is done in stmt_unremovable_because_of_non_call_eh_p. And yes go
defines can_delete_dead_exceptions to false.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug ipa/103451] [12 Regression] crash at gcc/range-op.cc:1836 since r12-5531-g1b0acc4b800b589a
2021-11-27 9:10 [Bug c/103451] New: crash at gcc/range-op.cc:1836 dcb314 at hotmail dot com
` (2 preceding siblings ...)
2021-11-29 8:12 ` pinskia at gcc dot gnu.org
@ 2021-11-29 8:49 ` aldyh at gcc dot gnu.org
2021-11-29 9:03 ` rguenther at suse dot de
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: aldyh at gcc dot gnu.org @ 2021-11-29 8:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451
--- Comment #4 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
> So range-op.cc eventually wants to look at 'cfun' which of course is a
> non-go in IPA context.
>
> void
> operator_div::wi_fold (irange &r, tree type,
> const wide_int &lh_lb, const wide_int &lh_ub,
> const wide_int &rh_lb, const wide_int &rh_ub) const
> {
> ...
> // If flag_non_call_exceptions, we must not eliminate a division by zero.
> if (cfun->can_throw_non_call_exceptions)
> {
> r.set_varying (type);
> return;
>
> I'm not sure wi_fold should care about "eliminating a division", but surely
> even for non-call EH the actual range of the result doesn't need to care.
>
> So if sth goes wrong when eliding the above it needs to be fixed upthread
> instead?
>
> Otherwise a "quick" workaround for the ICE is to check !cfun || ... and
> be conservative. I see there's no state associated with
> range_fold_binary_expr
> where the IPA context could pass down relevant can_throw_non_call_exceptions.
I honestly can't remember what the rationale was for checking
can_throw_non_call_exceptions. Perhaps this got added to catch some testcase?
My gut feeling is that we should be fixing whatever issue upstream, but !cfun
|| ... seems quite harmless.
>
> I also see
>
> bool
> fold_using_range::range_of_builtin_call (irange &r, gcall *call,
> fur_source &src)
> ...
> if (cfun->after_inlining)
> {
> r.set_zero (type);
>
> which might have similar problems (!cfun || ... looks quite reasonable there)
This one came from the old vr-values.c code, so you may have better insight
here ;-)
commit 46dfa8ad6c18feb45d35734eae38798edb7c38cd
Author: Richard Biener <rguenther@suse.de>
Date: Wed Sep 11 11:16:54 2019 +0000
re PR tree-optimization/90387 (__builtin_constant_p and -Warray-bounds
warnings)
2019-09-11 Richard Biener <rguenther@suse.de>
PR tree-optimization/90387
* vr-values.c (vr_values::extract_range_basic): After inlining
simplify non-constant __builtin_constant_p to false.
* gcc.dg/Warray-bounds-44.c: New testcase.
From-SVN: r275639
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug ipa/103451] [12 Regression] crash at gcc/range-op.cc:1836 since r12-5531-g1b0acc4b800b589a
2021-11-27 9:10 [Bug c/103451] New: crash at gcc/range-op.cc:1836 dcb314 at hotmail dot com
` (3 preceding siblings ...)
2021-11-29 8:49 ` aldyh at gcc dot gnu.org
@ 2021-11-29 9:03 ` rguenther at suse dot de
2021-11-29 9:31 ` aldyh at gcc dot gnu.org
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenther at suse dot de @ 2021-11-29 9:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451
--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 29 Nov 2021, aldyh at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451
>
> --- Comment #4 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #2)
> > So range-op.cc eventually wants to look at 'cfun' which of course is a
> > non-go in IPA context.
> >
> > void
> > operator_div::wi_fold (irange &r, tree type,
> > const wide_int &lh_lb, const wide_int &lh_ub,
> > const wide_int &rh_lb, const wide_int &rh_ub) const
> > {
> > ...
> > // If flag_non_call_exceptions, we must not eliminate a division by zero.
> > if (cfun->can_throw_non_call_exceptions)
> > {
> > r.set_varying (type);
> > return;
> >
> > I'm not sure wi_fold should care about "eliminating a division", but surely
> > even for non-call EH the actual range of the result doesn't need to care.
> >
> > So if sth goes wrong when eliding the above it needs to be fixed upthread
> > instead?
> >
> > Otherwise a "quick" workaround for the ICE is to check !cfun || ... and
> > be conservative. I see there's no state associated with
> > range_fold_binary_expr
> > where the IPA context could pass down relevant can_throw_non_call_exceptions.
>
> I honestly can't remember what the rationale was for checking
> can_throw_non_call_exceptions. Perhaps this got added to catch some testcase?
> My gut feeling is that we should be fixing whatever issue upstream, but !cfun
> || ... seems quite harmless.
Yes, I'd try just removing the code first ...
> >
> > I also see
> >
> > bool
> > fold_using_range::range_of_builtin_call (irange &r, gcall *call,
> > fur_source &src)
> > ...
> > if (cfun->after_inlining)
> > {
> > r.set_zero (type);
> >
> > which might have similar problems (!cfun || ... looks quite reasonable there)
>
> This one came from the old vr-values.c code, so you may have better insight
> here ;-)
Well, yeah - but at that point it wasn't exposed as API to IPA passes.
As said, !cfun || ... looks correct here (if in IPA context inlining
hasn't completed!)
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug ipa/103451] [12 Regression] crash at gcc/range-op.cc:1836 since r12-5531-g1b0acc4b800b589a
2021-11-27 9:10 [Bug c/103451] New: crash at gcc/range-op.cc:1836 dcb314 at hotmail dot com
` (4 preceding siblings ...)
2021-11-29 9:03 ` rguenther at suse dot de
@ 2021-11-29 9:31 ` aldyh at gcc dot gnu.org
2021-11-30 8:53 ` aldyh at gcc dot gnu.org
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: aldyh at gcc dot gnu.org @ 2021-11-29 9:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451
Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
--- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> Yes, I'd try just removing the code first ...
>
> > >
> > > I also see
> > >
> > > bool
> > > fold_using_range::range_of_builtin_call (irange &r, gcall *call,
> > > fur_source &src)
> > > ...
> > > if (cfun->after_inlining)
> > > {
> > > r.set_zero (type);
> > >
> > > which might have similar problems (!cfun || ... looks quite reasonable there)
> >
> > This one came from the old vr-values.c code, so you may have better insight
> > here ;-)
>
> Well, yeah - but at that point it wasn't exposed as API to IPA passes.
> As said, !cfun || ... looks correct here (if in IPA context inlining
> hasn't completed!)
Heh heh. I wasn't blaming you. It was just a coy way of saying "I don't know"
:-).
I'll investigate by first removing the code.
Thanks for your analysis.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug ipa/103451] [12 Regression] crash at gcc/range-op.cc:1836 since r12-5531-g1b0acc4b800b589a
2021-11-27 9:10 [Bug c/103451] New: crash at gcc/range-op.cc:1836 dcb314 at hotmail dot com
` (5 preceding siblings ...)
2021-11-29 9:31 ` aldyh at gcc dot gnu.org
@ 2021-11-30 8:53 ` aldyh at gcc dot gnu.org
2021-11-30 10:23 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: aldyh at gcc dot gnu.org @ 2021-11-30 8:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451
Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |zhendong.su at inf dot ethz.ch
--- Comment #7 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
*** Bug 103486 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug ipa/103451] [12 Regression] crash at gcc/range-op.cc:1836 since r12-5531-g1b0acc4b800b589a
2021-11-27 9:10 [Bug c/103451] New: crash at gcc/range-op.cc:1836 dcb314 at hotmail dot com
` (6 preceding siblings ...)
2021-11-30 8:53 ` aldyh at gcc dot gnu.org
@ 2021-11-30 10:23 ` cvs-commit at gcc dot gnu.org
2021-11-30 10:23 ` aldyh at gcc dot gnu.org
2021-11-30 11:17 ` aldyh at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-11-30 10:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451
--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Aldy Hernandez <aldyh@gcc.gnu.org>:
https://gcc.gnu.org/g:f33fdda0b805ff6097f9f325d73a4b07e72170b0
commit r12-5615-gf33fdda0b805ff6097f9f325d73a4b07e72170b0
Author: Aldy Hernandez <aldyh@redhat.com>
Date: Mon Nov 29 12:52:45 2021 +0100
Remove can_throw_non_call_exceptions special case from
operator_div::wi_fold.
PR tree-optimization/103451
gcc/ChangeLog:
* range-op.cc (operator_div::wi_fold): Remove
can_throw_non_call_exceptions special case.
* tree-ssa-sink.c (sink_code_in_bb): Same.
gcc/testsuite/ChangeLog:
* gcc.dg/pr103451.c: New test.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug ipa/103451] [12 Regression] crash at gcc/range-op.cc:1836 since r12-5531-g1b0acc4b800b589a
2021-11-27 9:10 [Bug c/103451] New: crash at gcc/range-op.cc:1836 dcb314 at hotmail dot com
` (7 preceding siblings ...)
2021-11-30 10:23 ` cvs-commit at gcc dot gnu.org
@ 2021-11-30 10:23 ` aldyh at gcc dot gnu.org
2021-11-30 11:17 ` aldyh at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: aldyh at gcc dot gnu.org @ 2021-11-30 10:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451
Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #9 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
fixed
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug ipa/103451] [12 Regression] crash at gcc/range-op.cc:1836 since r12-5531-g1b0acc4b800b589a
2021-11-27 9:10 [Bug c/103451] New: crash at gcc/range-op.cc:1836 dcb314 at hotmail dot com
` (8 preceding siblings ...)
2021-11-30 10:23 ` aldyh at gcc dot gnu.org
@ 2021-11-30 11:17 ` aldyh at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: aldyh at gcc dot gnu.org @ 2021-11-30 11:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451
--- Comment #10 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
*** Bug 103461 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 11+ messages in thread