With --with-build-config=bootstrap-O3, I encounter an ICE in bootstrap on ppc64le: /home/guojiufu/gcc/gcc-mainline-test/gcc/tree-cfg.c: In function 'tree_node* get_cases_for_edge(edge, gswitch*)': /home/guojiufu/gcc/gcc-mainline-test/gcc/tree-cfg.c:1339:1: internal compiler error: Segmentation fault 1339 | } | ^ 0x116b928b crash_signal /home/guojiufu/gcc/gcc-mainline-test/gcc/toplev.c:327 0x10c6f55c lookup_page_table_entry /home/guojiufu/gcc/gcc-mainline-test/gcc/ggc-page.c:630 0x10c71057 ggc_set_mark(void const*) /home/guojiufu/gcc/gcc-mainline-test/gcc/ggc-page.c:1544 0x11175ddf gt_ggc_mx_basic_block_def(void*) /home/guojiufu/gcc/build/gcc-mainline-test/gcc/gtype-desc.c:1518 0x11174a5f gt_ggc_mx_gimple(void*) /home/guojiufu/gcc/build/gcc-mainline-test/gcc/gtype-desc.c:1238 0x10af4757 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:483 0x11174a2b gt_ggc_mx_gimple(void*) /home/guojiufu/gcc/build/gcc-mainline-test/gcc/gtype-desc.c:1235 0x111756f3 gt_ggc_mx_cgraph_edge(void*) /home/guojiufu/gcc/build/gcc-mainline-test/gcc/gtype-desc.c:1403 0x111756d3 gt_ggc_mx_cgraph_edge(void*) /home/guojiufu/gcc/build/gcc-mainline-test/gcc/gtype-desc.c:1402 0x111751e7 gt_ggc_mx_symtab_node(void*) /home/guojiufu/gcc/build/gcc-mainline-test/gcc/gtype-desc.c:1348 0x10af3c37 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:346 0x11176ff3 gt_ggc_mx(tree_node*&) /home/guojiufu/gcc/build/gcc-mainline-test/gcc/gtype-desc.c:1790 0x10b03e7b void gt_ggc_mx<tree_node*>(vec<tree_node*, va_gc, vl_embed>*) /home/guojiufu/gcc/gcc-mainline-test/gcc/vec.h:1353 0x11177477 gt_ggc_mx_vec_tree_va_gc_(void*) /home/guojiufu/gcc/build/gcc-mainline-test/gcc/gtype-desc.c:1868 0x10af1f53 gt_ggc_mx_lang_type(void*) ./gt-cp-tree.h:36 0x10af4457 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:440 0x10af32ef gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:263 0x11176ff3 gt_ggc_mx(tree_node*&) /home/guojiufu/gcc/build/gcc-mainline-test/gcc/gtype-desc.c:1790 0x10b03e7b void gt_ggc_mx<tree_node*>(vec<tree_node*, va_gc, vl_embed>*) /home/guojiufu/gcc/gcc-mainline-test/gcc/vec.h:1353 0x11177477 gt_ggc_mx_vec_tree_va_gc_(void*) /home/guojiufu/gcc/build/gcc-mainline-test/gcc/gtype-desc.c:1868 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. Makefile:1142: recipe for target 'tree-cfg.o' failed
The error is raised after ipa “inlining” pass, when doing ggc_collect at stage 2. At code: xlimit = ((*xlimit).next); The value of xlimit becomes 0xa5a5a5a5a5a5a5a5 before crash. 0xa5 may comes from poison_pages. If using "-fno-inline" the crash disappears.
There is a similar bug fixed for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447. it may be a different issue.
(In reply to Jiu Fu Guo from comment #1) > The error is raised after ipa “inlining” pass, when doing ggc_collect at > stage 2. > > At code: > xlimit = ((*xlimit).next); > > The value of xlimit becomes 0xa5a5a5a5a5a5a5a5 before crash. 0xa5 may comes > from poison_pages. > > > If using "-fno-inline" the crash disappears. 0xa5a5a5a5a5a5a5a means the location has been GC'ed already; either from ggc_free or from a previous ggc_collect. What you can try is run with the following options: --param ggc-min-expand=1 --param ggc-min-heapsize=1 Which will cause ggc_collect to run the garbage collection almost every time (setting it to 0 will run it every time but it is much much slower) and reduce the testcase that way. Also it would be a good idea to attach the preprocessed source and the exact command line xgcc is involved and which stage is this at too and the full configure command line used. I highly doubt it is related to PR 99447 which is about a stack overflow while doing the garbage collection walk.
Created attachment 50787 [details] t.ii /home/guojiufu/gcc/build/gcc-mainline-test/./prev-gcc/xg++ -B/home/guojiufu/gcc/build/gcc-mainline-test/./prev-gcc/ -c -O3 -o tree-cfg.o t.ii
build command is: configure --enable-languages=c,c++,fortran,objc,obj-c++,go --with-cpu=native --disable-multilib --with-long-double-128 --prefix=$HOME/xx --with-build-config=bootstrap-O3 make -j
cut.. > 0xa5a5a5a5a5a5a5a means the location has been GC'ed already; either from > ggc_free or from a previous ggc_collect. > What you can try is run with the following options: > --param ggc-min-expand=1 --param ggc-min-heapsize=1 > Which will cause ggc_collect to run the garbage collection almost every time > (setting it to 0 will run it every time but it is much much slower) and > reduce the testcase that way. Hi Andrew, thanks. With --param ggc-min-expand=1 --param ggc-min-heapsize=1, the error can reproduced too. > > Also it would be a good idea to attach the preprocessed source and the exact > command line xgcc is involved and which stage is this at too and the full > configure command line used. I would continue to reduce the testcase, .ii file is still large. > > I highly doubt it is related to PR 99447 which is about a stack overflow > while doing the garbage collection walk. Yes, it is possible! The stack depth is big: > 500 levels at least.
A similar issue also reported on X86 before, https://gcc.gnu.org/pipermail/gcc-testresults/2021-April/677996.html While when I bootstrap -O3 on one x86, it passes.
Just to clarify - this is on HEAD or the gcc-11 branch?
Yes, I can reproduce it and I'm working on it.
Reproduced with master on gcc112 machine (ppc64le).
I can also reproduce it on x86_64, right now I'm reducing the test-case. Started with r11-6411-gae99b315ba5b9e1c.
Created attachment 50789 [details] Reduced test-case (x86_64) Fails on master with: $ g++ tree-cfg.ii -O3 --param ggc-min-expand=1 --param ggc-min-heapsize=1 -c -w ... tree-cfg2.ii: In function ‘unsigned int split_critical_edges(bool)’: tree-cfg2.ii:1877:15: internal compiler error: Segmentation fault 1877 | unsigned int split_critical_edges (bool for_edge_insertion_p ) { basic_block bb; edge e; edge_iterator ei; start_recording_case_labels (); for (bb = (((cfun + 0))->cfg->x_entry_block_ptr); bb; bb = bb->next_bb) { for ((ei) = ei_start_1 (&((bb->succs))); ei_cond ((ei), &(e)); ei_next (&(ei))) { if ((vec_safe_length ((e)->src->succs) >= 2 && vec_safe_length ((e)->dest->preds) >= 2) && !(e->flags & EDGE_ABNORMAL)) split_edge (e); else if (for_edge_insertion_p && (!single_pred_p (e->dest) || !gimple_seq_empty_p (phi_nodes (e->dest)) || e->dest == (((cfun + 0))->cfg->x_exit_block_ptr)) && e->src != (((cfun + 0))->cfg->x_entry_block_ptr) && !(e->flags & EDGE_ABNORMAL)) { gimple_stmt_iterator gsi; gsi = gsi_last_bb (e->src); if (!gsi_end_p (gsi) && stmt_ends_bb_p (gsi_stmt (gsi)) && (gimple_code (gsi_stmt (gsi)) != GIMPLE_RETURN && !gimple_call_builtin_p (gsi_stmt (gsi), BUILT_IN_RETURN))) split_edge (e); } } } end_recording_case_labels (); return 0; } | ^~~~~~~~~~~~~~~~~~~~ 0x117deda crash_signal /home/marxin/Programming/gcc/gcc/toplev.c:327 0x7ffff789352f ??? /usr/src/debug/glibc-2.33-5.2.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0xc782cb lookup_page_table_entry /home/marxin/Programming/gcc/gcc/ggc-page.c:630 0xc782cb ggc_set_mark(void const*) /home/marxin/Programming/gcc/gcc/ggc-page.c:1550 0xeefdf1 gt_ggc_mx_basic_block_def(void*) /dev/shm/objdir/gcc/gtype-desc.c:1525 0xef226f gt_ggc_mx_gimple(void*) /dev/shm/objdir/gcc/gtype-desc.c:1285 0xbb0b8b gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:483 0xef257e gt_ggc_mx_gimple(void*) /dev/shm/objdir/gcc/gtype-desc.c:1233 0xef4e01 gt_ggc_mx_cgraph_edge(void*) /dev/shm/objdir/gcc/gtype-desc.c:1401 0xef4df3 gt_ggc_mx_cgraph_edge(void*) /dev/shm/objdir/gcc/gtype-desc.c:1400 0xef4b7d gt_ggc_mx_symtab_node(void*) /dev/shm/objdir/gcc/gtype-desc.c:1346 0xbb11a7 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:346 0xeedcde void gt_ggc_mx<tree_node*>(vec<tree_node*, va_gc, vl_embed>*) /home/marxin/Programming/gcc/gcc/vec.h:1353 0xeedcde gt_ggc_mx_vec_tree_va_gc_(void*) /dev/shm/objdir/gcc/gtype-desc.c:1877 0xeedcde gt_ggc_mx_vec_tree_va_gc_(void*) /dev/shm/objdir/gcc/gtype-desc.c:1872 0xbb20de gt_ggc_mx_lang_type(void*) ./gt-cp-tree.h:36 0xbb20de gt_ggc_mx_lang_type(void*) ./gt-cp-tree.h:23 0xbb0f71 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:440 0xbb1a2c gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:321 0xbb0f5f gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:439 Note that --param ggc-min-expand=0 --param ggc-min-heapsize=0 takes ages, do not use it..
So we're reaching a unreleased SSA names def_stmt which points to a ggc_freed CFG block. Referenced from a function decls symtab node and edge call stmts. And we're collecting after PRE. The basic-block in question is released via #0 ggc_free (p=0x7ffff607d3a8) at /home/rguenther/src/gcc3/gcc/ggc-page.c:1612 #1 0x0000000002596ae0 in free_block (bb=<basic_block 0x7ffff607d3a8 (7)>) at /home/rguenther/src/gcc3/gcc/cfg.c:105 #2 0x0000000002596b76 in free_cfg (fn=0x7ffff56d7228) at /home/rguenther/src/gcc3/gcc/cfg.c:122 #3 0x000000000105bed8 in release_function_body ( decl=<function_decl 0x7ffff3f66c00 ei_safe_edge.isra>) at /home/rguenther/src/gcc3/gcc/cgraph.c:1821 #4 0x000000000105c0b7 in cgraph_node::release_body ( this=<cgraph_node * const 0x7ffff402cbb0 "ei_safe_edge.isra"/1010>, keep_arguments=false) at /home/rguenther/src/gcc3/gcc/cgraph.c:1857 #5 0x000000000105c723 in cgraph_node::remove ( this=<cgraph_node * const 0x7ffff402cbb0 "ei_safe_edge.isra"/1010>) at /home/rguenther/src/gcc3/gcc/cgraph.c:1957 #6 0x00000000017ab133 in expand_call_inline ( bb=<basic_block 0x7ffff60d51a0 (12)>, stmt=<gimple_assign 0x7ffff3e93780>, id=0x7fffffffd920, to_purge=0x7fffffffd900) at /home/rguenther/src/gcc3/gcc/tree-inline.c:5270 #7 0x00000000017ab242 in gimple_expand_calls_inline ( bb=<basic_block 0x7ffff60d51a0 (12)>, id=0x7fffffffd920, to_purge=0x7fffffffd900) at /home/rguenther/src/gcc3/gcc/tree-inline.c:5299 #8 0x00000000017aba14 in optimize_inline_calls ( fn=<function_decl 0x7ffff55f4d00 gimple_purge_dead_abnormal_call_edges but the interesting thing is that the SSA name refering to the released block is not associated with the function released. <ssa_name 0x7ffff61e1870 type <pointer_type 0x7ffff582d3f0 edge type <record_type 0x7ffff582d2a0 edge_def cxx-odr-p type_5 type_6 BLK size <integer_cst 0x7ffff63e9060 constant 384> unit-size <integer_cst 0x7ffff63cdd98 constant 48> align:64 warn_if_not_align:0 symtab:0 alias-set 37 canonical-type 0x7ffff582d2a0 fields <field_decl 0x7ffff57c0980 src> context <translation_unit_decl 0x7ffff6578168 t.ii> full-name "class edge_def" X() X(constX&) this=(X&) n_parents=0 use_template=0 interface-unknown pointer_to_this <pointer_type 0x7ffff582d348> chain <type_decl 0x7ffff5c24d10 edge_def>> sizes-gimplified public unsigned DI size <integer_cst 0x7ffff656aeb8 constant 64> unit-size <integer_cst 0x7ffff656aed0 constant 8> align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7ffff582d348 pointer_to_this <pointer_type 0x7ffff5789c78>> visited def_stmt _6 = ei_edge (i, ISRA.1211_9(D), ISRA.1212_10(D)); version:8 ptr-info 0x7ffff610b588> (gdb) p t->ssa_name.def_stmt->bb $31 = <basic_block 0x7ffff3ef05b0 (3)> the SSA name is originally created by into SSA and rewritten via #1 0x00000000013ef215 in ipa_param_body_adjustments::modify_call_stmt ( this=0x3f45fc0, stmt_p=0x7fffffffd1a0) at /home/rguenther/src/gcc3/gcc/ipa-param-manipulation.c:1695 1695 gimple_call_set_lhs (new_stmt, lhs); (gdb) l 1690 gimple_call_set_chain (new_stmt, gimple_call_chain (stmt)); 1691 gimple_call_copy_flags (new_stmt, stmt); 1692 if (tree lhs = gimple_call_lhs (stmt)) 1693 { 1694 modify_expression (&lhs, false); 1695 gimple_call_set_lhs (new_stmt, lhs); 1696 } where this alters the 'lhs' SSA_NAME_DEF_STMT to new_stmt which has a NULL basic-block at this point. I suppose the old stmt is dead afterwards - because the caller will only remap the LHS SSA name _after_ this call adjustment. diff --git a/gcc/ipa-param-manipulation.c b/gcc/ipa-param-manipulation.c index 1d1e64f546a..8385c8f3073 100644 --- a/gcc/ipa-param-manipulation.c +++ b/gcc/ipa-param-manipulation.c @@ -1692,7 +1692,7 @@ ipa_param_body_adjustments::modify_call_stmt (gcall **stmt_p) if (tree lhs = gimple_call_lhs (stmt)) { modify_expression (&lhs, false); - gimple_call_set_lhs (new_stmt, lhs); + gimple_set_op (new_stmt, 0, lhs); } *stmt_p = new_stmt; return true; fixes this and the GC issue.
If you want to avoid that if (lhs && TREE_CODE (lhs) == SSA_NAME) SSA_NAME_DEF_STMT (lhs) = gs; in gimple_call_set_lhs, I think it deserves a comment and probably *gimple_call_lhs_ptr (new_stmt) = lhs; would be cleaner than gimple_set_op (new_stmt, 0, lhs);
(In reply to Jakub Jelinek from comment #14) > If you want to avoid that > if (lhs && TREE_CODE (lhs) == SSA_NAME) > SSA_NAME_DEF_STMT (lhs) = gs; > in gimple_call_set_lhs, I think it deserves a comment and probably > *gimple_call_lhs_ptr (new_stmt) = lhs; > would be cleaner than gimple_set_op (new_stmt, 0, lhs); Good point. Note I'm not (yet) testing the patch.
Created attachment 50790 [details] patch
Jiu, can you test whether the proposed patch fixes the bootstrap-O3 issue on ppc64le?
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>: https://gcc.gnu.org/g:7e0fe7761da9255c9342788956c37b426875d872 commit r12-716-g7e0fe7761da9255c9342788956c37b426875d872 Author: Richard Biener <rguenther@suse.de> Date: Tue May 11 13:23:45 2021 +0200 ipa/100513 - fix SSA_NAME_DEF_STMT corruption in IPA param manip This fixes unintended clobbering of SSA_NAME_DEF_STMT of the cloned/inlined from SSA name during IPA parameter manipulation of call stmt LHSs. gimple_call_set_lhs adjusts SSA_NAME_DEF_STMT of the lhs to the stmt being modified but when ipa_param_body_adjustments::modify_call_stmt is called the cloning/inlining process has not yet remapped the stmts operands to the copy variants but they are still original. 2021-05-11 Richard Biener <rguenther@suse.de> PR ipa/100513 * ipa-param-manipulation.c (ipa_param_body_adjustments::modify_call_stmt): Avoid altering SSA_NAME_DEF_STMT by adjusting the calls LHS via gimple_call_lhs_ptr.
Fixed on trunk sofar. The same code is present on the GCC 10 branch but not literally on the GCC 9 branch.
Yes, with the patch, bootstrap-O3 pass on ppc64le too. Thanks!
When build the go on trunk with the patch, an error occur: In function 'syscall.forkExec': go1: error: address taken, but ADDRESSABLE bit not set PHI argument &go..C479; for PHI node err$__object_77 = PHI <err$__object_76(62), &go..C479(63)> during GIMPLE pass: fre go1: internal compiler error: verify_ssa failed mv -f .deps/tsan_rtl_report.Tpo .deps/tsan_rtl_report.Plo 0x10fde5cf verify_ssa(bool, bool) /home/guojiufu/gcc/gcc-mainline-test/gcc/tree-ssa.c:1214 0x10aff4ef execute_function_todo /home/guojiufu/gcc/gcc-mainline-test/gcc/passes.c:2049 0x10b011c3 do_per_function /home/guojiufu/gcc/gcc-mainline-test/gcc/passes.c:1687 0x10b011c3 execute_todo /home/guojiufu/gcc/gcc-mainline-test/gcc/passes.c:2096 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. Makefile:3001: recipe for target 'syscall.lo' failed
On Tue, 11 May 2021, guojiufu at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100513 > > --- Comment #21 from Jiu Fu Guo <guojiufu at gcc dot gnu.org> --- > When build the go on trunk with the patch, an error occur: > In function 'syscall.forkExec': > go1: error: address taken, but ADDRESSABLE bit not set > PHI argument > &go..C479; > for PHI node > err$__object_77 = PHI <err$__object_76(62), &go..C479(63)> > during GIMPLE pass: fre > go1: internal compiler error: verify_ssa failed > mv -f .deps/tsan_rtl_report.Tpo .deps/tsan_rtl_report.Plo > 0x10fde5cf verify_ssa(bool, bool) > /home/guojiufu/gcc/gcc-mainline-test/gcc/tree-ssa.c:1214 > 0x10aff4ef execute_function_todo > /home/guojiufu/gcc/gcc-mainline-test/gcc/passes.c:2049 > 0x10b011c3 do_per_function > /home/guojiufu/gcc/gcc-mainline-test/gcc/passes.c:1687 > 0x10b011c3 execute_todo > /home/guojiufu/gcc/gcc-mainline-test/gcc/passes.c:2096 > Please submit a full bug report, > with preprocessed source if appropriate. > Please include the complete backtrace with any bug report. > See <https://gcc.gnu.org/bugs/> for instructions. > Makefile:3001: recipe for target 'syscall.lo' failed Yes, this was reported by Maxim as well, independent of this patch. It's caused by sth else.
Created attachment 50791 [details] the command to build syscall.o
(In reply to rguenther@suse.de from comment #22) > On Tue, 11 May 2021, guojiufu at gcc dot gnu.org wrote: > cut.. > > Makefile:3001: recipe for target 'syscall.lo' failed > > Yes, this was reported by Maxim as well, independent of this > patch. It's caused by sth else. Thanks ;)
(In reply to Jiu Fu Guo from comment #21) > When build the go on trunk with the patch, an error occur: > In function 'syscall.forkExec': > go1: error: address taken, but ADDRESSABLE bit not set I see this also on a go build on raspberry pi. Interesting.
The releases/gcc-11 branch has been updated by Richard Biener <rguenth@gcc.gnu.org>: https://gcc.gnu.org/g:d0a8a95003e7763ece4886e771f71385966e229b commit r11-8464-gd0a8a95003e7763ece4886e771f71385966e229b Author: Richard Biener <rguenther@suse.de> Date: Tue May 11 13:23:45 2021 +0200 ipa/100513 - fix SSA_NAME_DEF_STMT corruption in IPA param manip This fixes unintended clobbering of SSA_NAME_DEF_STMT of the cloned/inlined from SSA name during IPA parameter manipulation of call stmt LHSs. gimple_call_set_lhs adjusts SSA_NAME_DEF_STMT of the lhs to the stmt being modified but when ipa_param_body_adjustments::modify_call_stmt is called the cloning/inlining process has not yet remapped the stmts operands to the copy variants but they are still original. 2021-05-11 Richard Biener <rguenther@suse.de> PR ipa/100513 * ipa-param-manipulation.c (ipa_param_body_adjustments::modify_call_stmt): Avoid altering SSA_NAME_DEF_STMT by adjusting the calls LHS via gimple_call_lhs_ptr. (cherry picked from commit 7e0fe7761da9255c9342788956c37b426875d872)
The releases/gcc-10 branch has been updated by Richard Biener <rguenth@gcc.gnu.org>: https://gcc.gnu.org/g:37d845ac59b26e0beb97e7d0d138cb9995d6ada2 commit r10-9922-g37d845ac59b26e0beb97e7d0d138cb9995d6ada2 Author: Richard Biener <rguenther@suse.de> Date: Tue May 11 13:23:45 2021 +0200 ipa/100513 - fix SSA_NAME_DEF_STMT corruption in IPA param manip This fixes unintended clobbering of SSA_NAME_DEF_STMT of the cloned/inlined from SSA name during IPA parameter manipulation of call stmt LHSs. gimple_call_set_lhs adjusts SSA_NAME_DEF_STMT of the lhs to the stmt being modified but when ipa_param_body_adjustments::modify_call_stmt is called the cloning/inlining process has not yet remapped the stmts operands to the copy variants but they are still original. 2021-05-11 Richard Biener <rguenther@suse.de> PR ipa/100513 * ipa-param-manipulation.c (ipa_param_body_adjustments::modify_call_stmt): Avoid altering SSA_NAME_DEF_STMT by adjusting the calls LHS via gimple_call_lhs_ptr. (cherry picked from commit 7e0fe7761da9255c9342788956c37b426875d872)
Fixed.