[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #20 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:c76b3f9e83353a4cd437ca137c1fb835c9b5c21f commit r11-5443-gc76b3f9e83353a4cd437ca137c1fb835c9b5c21f Author: Richard Biener Date: Thu Nov 26 16:13:08 2020 +0100 tree-optimization/97953 - fix bougs range recorded by EVRP EVRP records some ranges from asserts into SSA_NAME_RANGE_INFO but fails to assert that the condition the range is derived from is always true after the SSA names definition. The patch implements the simplest post-dominance check, basic-block equality. 2020-11-26 Richard Biener PR tree-optimization/97953 * gimple-ssa-evrp-analyze.c (evrp_range_analyzer::record_ranges_from_incoming_edge): Make sure the condition post-dominates the SSA definition before recording into SSA_NAME_RANGE_INFO. * gcc.dg/pr97953.c: New testcase.
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 Martin Liška changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #19 from Martin Liška --- What a nice reduced test-case. Btw. started to fail with r8-4962-g4aa458f2ac11aef0 with -O2 -fno-tree-free
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953
--- Comment #18 from Richard Biener ---
int __attribute__((noipa))
foo (int flag, int *p)
{
int val = *p;
if (flag)
{
if (val != 1)
__builtin_unreachable ();
return 0;
}
int val2 = *p;
return val2 == 2;
}
int main()
{
int i = 2;
if (foo (0, ) != 1)
__builtin_abort ();
return 0;
}
fails with -fno-tree-fre.
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953
--- Comment #17 from Richard Biener ---
The issue is a bogus jump threading done in VRP2 caused by bogus range info on
the hoisted gimple_code (use->stmt).
tree-ssa-loop-ivopts.c.137t.pre- # PT = nonlocal escaped null
tree-ssa-loop-ivopts.c.137t.pre- pretmp_252 = use_79(D)->stmt;
tree-ssa-loop-ivopts.c.137t.pre: pretmp_31 = MEM[(const struct gimple
*)pretmp_252].code;
tree-ssa-loop-ivopts.c.137t.pre- if (_1 == 4)
the if is the cand->pos == IP_ORIGINAL check. Now after dom3
suddenly we have
tree-ssa-loop-ivopts.c.188t.dom3- # PT = nonlocal escaped null
tree-ssa-loop-ivopts.c.188t.dom3- pretmp_252 = use_79(D)->stmt;
tree-ssa-loop-ivopts.c.188t.dom3- # RANGE [6, 6] NONZERO 6
tree-ssa-loop-ivopts.c.188t.dom3: pretmp_31 = MEM[(const struct gimple
*)pretmp_252].code;
tree-ssa-loop-ivopts.c.188t.dom3- if (_1 == 4)
before DOM the check is below
[local count: 972093932]:
# PT = nonlocal escaped null
# prephitmp_179 = PHI
_164 = MEM[(const struct gimple *)prephitmp_179].code;
# DEBUG g => NULL
if (_164 == 6)
goto ; [26.31%]
where DOM seems to CSE the load with the earlier (correct) but then
even though it pops the recorded range on pretmp_31 it never backs out
the SSA_NAME_RANGE_INFO? It's set here:
#0 set_range_info_raw (name=, range_type=VR_RANGE,
min=..., max=...)
at /home/rguenther/src/trunk/gcc/tree-ssanames.c:359
#1 0x01b1d0f8 in set_range_info (name=,
range_type=VR_RANGE, min=..., max=...)
at /home/rguenther/src/trunk/gcc/tree-ssanames.c:405
#2 0x027a4d91 in evrp_range_analyzer::set_ssa_range_info
(this=0x7fffd100, lhs=,
vr=0x444dcd0) at
/home/rguenther/src/trunk/gcc/gimple-ssa-evrp-analyze.c:113
#3 0x027a5597 in evrp_range_analyzer::record_ranges_from_incoming_edge
(this=0x7fffd100,
bb=) at
/home/rguenther/src/trunk/gcc/gimple-ssa-evrp-analyze.c:223
#4 0x027a4ad5 in evrp_range_analyzer::enter (this=0x7fffd100,
bb=)
at /home/rguenther/src/trunk/gcc/gimple-ssa-evrp-analyze.c:75
#5 0x019643fb in dom_opt_dom_walker::before_dom_children
(this=0x7fffd0d0, bb=)
at /home/rguenther/src/trunk/gcc/tree-ssa-dom.c:1420
#6 0x02736350 in dom_walker::walk (this=0x7fffd0d0,
bb=)
at /home/rguenther/src/trunk/gcc/domwalk.c:309
#7 0x01962a54 in (anonymous namespace)::pass_dominator::execute
(this=0x3f2d540, fun=0x7112fb80)
at /home/rguenther/src/trunk/gcc/tree-ssa-dom.c:724
so we have m_update_global_ranges set here.
218 push_value_range (vrs[i].first, vrs[i].second);
219 if (is_fallthru
220 && m_update_global_ranges
221 && all_uses_feed_or_dominated_by_stmt (vrs[i].first,
stmt))
222 {
223 set_ssa_range_info (vrs[i].first, vrs[i].second);
224 maybe_set_nonzero_bits (pred_e, vrs[i].first);
but obviously this all_uses_feed_or_dominated_by_stmt doesn't tell us the
whole story:
(gdb) p debug_immediate_uses_for($12)
pretmp_31 : --> single use.
if (pretmp_31 != 6)
in the IL we have not yet updated
_164 = MEM[(const struct gimple *)prephitmp_179].code;
# DEBUG g => NULL
if (_164 == 6)
goto ; [26.31%]
else
goto ; [73.69%]
to reflect the CSE of this load to pretmp_31!
So we have basically
_1 = *p;
if (...)
{
if (_1 != 6)
gcc_unreachable (); // from the assert
}
_2 = *p;
if (_2 != 6)
...
and DOM happily records [6, 6] on _1 based on its single-use and after
that DOM itself CSEs the load and optimizes the second test.
I think all_uses_feed_or_dominated_by_stmt cannot work on its own.
IIRC we have another duplicate of this somewhere.
We have to make sure that the definition is post-dominated by the
condition as well.
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953
--- Comment #16 from Martin Liška ---
Then you will see the following diff in optimized dump:
--- good2020-11-25 16:27:16.795544128 +0100
+++ bad 2020-11-25 16:26:59.723620747 +0100
@@ -17022,7 +17022,6 @@
;; Function rewrite_use_nonlinear_expr
(_ZL26rewrite_use_nonlinear_exprP11ivopts_dataP6iv_useP7iv_cand,
funcdef_no=3488, decl_uid=138891, cgraph_uid=2628, symbol_order=2806)
-Removing basic block 55
Removing basic block 56
Removing basic block 57
Removing basic block 58
@@ -17049,6 +17048,10 @@
Removing basic block 79
Removing basic block 80
Removing basic block 81
+Removing basic block 82
+Removing basic block 83
+Removing basic block 84
+Removing basic block 85
__attribute__((noipa, noinline, noclone, no_icf))
rewrite_use_nonlinear_expr (struct ivopts_data * data, struct iv_use * use,
struct iv_cand * cand)
{
@@ -17182,6 +17185,9 @@
struct gimple * pretmp_236;
unsigned char _237;
struct gimple * _239;
+ unsigned char _265;
+ struct gimple * prephitmp_268;
+ unsigned char _269;
struct gimple * prephitmp_270;
struct gimple * pretmp_272;
struct gimple * _287;
@@ -17252,7 +17258,7 @@
if (_11 == _12)
goto ; [30.00%]
else
-goto ; [70.00%]
+goto ; [70.00%]
[local count: 109521665]:
_118 = MEM[(const struct gassign *)_12].D.92331.op[0];
@@ -17364,19 +17370,19 @@
[local count: 583887]:
pretmp_236 = use_88(D)->stmt;
- [local count: 972093934]:
- # prephitmp_15 = PHI
+ [local count: 716543374]:
+ # prephitmp_15 = PHI
_184 = MEM[(const struct gimple *)prephitmp_15].code;
if (_184 == 6)
-goto ; [44.98%]
+goto ; [25.49%]
else
-goto ; [55.02%]
+goto ; [74.51%]
- [local count: 972093934]:
+ [local count: 971122338]:
if (_184 == 18)
-goto ; [99.90%]
+goto ; [100.00%]
else
-goto ; [0.10%]
+goto ; [0.00%]
[local count: 534347641]:
_190 = MEM[(union tree_node * *)prephitmp_15 + 48B];
@@ -17431,17 +17437,19 @@
goto ; [100.00%]
[local count: 437211681]:
- pretmp_211 = MEM[(const struct gassign *)prephitmp_15].D.92331.op[0];
+ # prephitmp_268 = PHI
+ pretmp_211 = MEM[(const struct gassign *)prephitmp_268].D.92331.op[0];
[local count: 534347641]:
- # _287 = PHI
+ # _287 = PHI
# prephitmp_212 = PHI
bsi = gsi_for_stmt (_287);
pretmp_272 = use_88(D)->stmt;
goto ; [100.00%]
[local count: 534606]:
- retval.1249_113 = (int) _184;
+ # _265 = PHI <_184(29), _269(55)>
+ retval.1249_113 = (int) _265;
internal_error ("XX, code==%d\n", retval.1249_113);
[local count: 887017088]:
@@ -17607,6 +17615,13 @@
_18 ={v} MEM[(struct gimple * *)0B];
__builtin_trap ();
+ [local count: 20560]:
+ _269 = MEM[(const struct gimple *)_12].code;
+ if (_269 == 6)
+goto ; [99.62%]
+ else
+goto ; [0.38%]
+
}
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953
--- Comment #15 from Martin Liška ---
Created attachment 49624
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49624=edit
debugging patch
All right it will be for Richi. I suspect it's a do_hoist_insertion.
reduced test-case:
$ cat /tmp/bid.i
int __bid_ten2k64_res_0, __bid_ten2k64_ind;
void __bid_round64_2_18();
void __bid_ten2k64() {
for (; __bid_ten2k64_ind <= 9; __bid_ten2k64_ind++)
if (__bid_ten2k64_res_0)
break;
if (__bid_ten2k64_ind)
__bid_round64_2_18();
}
Steps to reproduce:
1) git co bd87cc14ebdb6789e067fb1828d5808407c308b3
2) patch -p1 < debug.patch
3) mkdir objdir
4) cd objdir
5) ../configure --disable-checking --disable-werror
--enable-languages=c,c++,fortran --disable-multilib
6) make -j16 (you can also use make -j16 'STAGE1_CFLAGS=-g -O2')
... then it build stage2 compiler and crashes in somewhere in libgcc (using the
compiler)
$ ./gcc/xgcc -Bgcc /tmp/bid.i -O2 -c -fverbose-asm
__bid_ten2k64_ind.2_11 = PHI <_3(13), __bid_ten2k64_ind.2_12(4)>
use->stmt: 0x77548400, use->stmt->code: 18
_3 = __bid_ten2k64_ind.2_11 + 1;
cand->incremented_at: 0x77544000, cand->incremented_at->code: 6
during GIMPLE pass: ivopts
/tmp/bid.i: In function ‘__bid_ten2k64’:
/tmp/bid.i:4:6: internal compiler error: XX, code==18
4 | void __bid_ten2k64() {
| ^
0x77695151 __libc_start_main
../csu/libc-start.c:314
0x5ffafd ???
../sysdeps/x86_64/start.S:120
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 Martin Liška changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #14 from Martin Liška --- Thank you Chris, I can really confirm that. Working on that..
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #13 from Chris Clayton --- (In reply to Martin Liška from comment #9) > Ok, so the question is: does it reproduce with the current master or now? Short answer: Yes, it does. A build done this morning (after pulling the latest changes into the tree I cloned yesterday) fails with the same ICE error messages.
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #12 from Chris Clayton --- Created attachment 49622 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49622=edit git bisect log
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #11 from Chris Clayton --- I've finished the bisect and landed at: [chris:~/scratch/gcc-ICE/gcc]$ git bisect good bd87cc14ebdb6789e067fb1828d5808407c308b3 is the first bad commit commit bd87cc14ebdb6789e067fb1828d5808407c308b3 Author: Richard Biener Date: Wed Nov 11 11:51:59 2020 +0100 tree-optimization/97623 - Avoid PRE hoist insertion iteration The recent previous change in this area limited hoist insertion iteration via a param but the following is IMHO better since we are not really interested in PRE opportunities exposed by hoisting but only the other way around. So this moves hoist insertion after PRE iteration finished and removes hoist insertion iteration alltogether. 2020-11-11 Richard Biener PR tree-optimization/97623 * params.opt (-param=max-pre-hoist-insert-iterations): Remove again. * doc/invoke.texi (max-pre-hoist-insert-iterations): Likewise. * tree-ssa-pre.c (insert): Move hoist insertion after PRE insertion iteration and do not iterate it. * gcc.dg/tree-ssa/ssa-hoist-3.c: Adjust. * gcc.dg/tree-ssa/ssa-hoist-7.c: Likewise. * gcc.dg/tree-ssa/ssa-pre-30.c: Likewise. gcc/doc/invoke.texi | 5 - gcc/params.opt | 4 gcc/testsuite/gcc.dg/tree-ssa/ssa-hoist-3.c | 2 +- gcc/testsuite/gcc.dg/tree-ssa/ssa-hoist-7.c | 4 ++-- gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-30.c | 2 +- gcc/tree-ssa-pre.c | 34 +++-- 6 files changed, 26 insertions(+), 25 deletions(-) I've also confirmed the outcome. A build with this commit at HEAD fails with the ICE. A build with the commits parent at HEAD succeeds. I'll attach the bisect log in a few minutes.
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #10 from Richard Biener --- There's only two relevant changes, both before the snapshot tested: ec383f0bdb4077b744d493d02afff5f13f33029e and d87ee7f1c9cd2ffa6302cdfd0686d72e5bb7463b
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #9 from Martin Liška --- Ok, so the question is: does it reproduce with the current master or now?
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #8 from Chris Clayton --- Sorry, my last comment contains an error. git bisect start... reported 7 bisections would be needed not that there were only 7 commits.
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #7 from Chris Clayton --- Yes, Richard's correct. I'm building from snapshot releases. That's why I used the term "snapshot releases" in comment 4. I've cloned git://gcc.gnu.org/git/gcc.git and am bisecting between b642fca1c31b2e2175e0860daf32b4ee0d918085 (11-20201108) and c746fc40f4ec8cfc1092efd49d567751858d2099 (11-20201115). I'm not 100% sure this is correct because I'm anything but a git expert and I've never come across a tree that didn't have branches for different strands of development (e.g gcc-10 gcc-11). git bisect start... reported that there were only 7 commits and that feels right, so I'll blunder on until someone tells me I'm doing this wrong (an, hopefully, how I should be doing it)
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 Richard Biener changed: What|Removed |Added Component|c |tree-optimization Target||x86_64-*-* --- Comment #6 from Richard Biener --- Hmm, I can't reproduce - there's nothing unusual in your full build log. Martin, I think he's testing one of the snapshot tarballs which have names after the date published.
