Created attachment 32693 [details] Error output, config.log, config.status /builds/gbgbuild/bld/gcc/stbldap01/obj_stbldap01-4.9.0/./prev-gcc/xg++ -B/builds/gbgbuild/bld/gcc/stbldap01/obj_stbldap01-4.9.0/./prev-gcc/ -B/usr/local/gcc-4.9.0/powerpc-ibm-aix6.1.0.0/bin/ -nostdinc++ -B/builds/gbgbuild/bld/gcc/stbldap01/obj_stbldap01-4.9.0/prev-powerpc-ibm-aix6.1.0.0/libstdc++-v3/src/.libs -B/builds/gbgbuild/bld/gcc/stbldap01/obj_stbldap01-4.9.0/prev-powerpc-ibm-aix6.1.0.0/libstdc++-v3/libsupc++/.libs -I/builds/gbgbuild/bld/gcc/stbldap01/obj_stbldap01-4.9.0/prev-powerpc-ibm-aix6.1.0.0/libstdc++-v3/include/powerpc-ibm-aix6.1.0.0 -I/builds/gbgbuild/bld/gcc/stbldap01/obj_stbldap01-4.9.0/prev-powerpc-ibm-aix6.1.0.0/libstdc++-v3/include -I/builds/gbgbuild/bld/gcc/gcc-4.9.0/libstdc++-v3/libsupc++ -L/builds/gbgbuild/bld/gcc/stbldap01/obj_stbldap01-4.9.0/prev-powerpc-ibm-aix6.1.0.0/libstdc++-v3/src/.libs -L/builds/gbgbuild/bld/gcc/stbldap01/obj_stbldap01-4.9.0/prev-powerpc-ibm-aix6.1.0.0/libstdc++-v3/libsupc++/.libs -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I/builds/gbgbuild/bld/gcc/gcc-4.9.0/gcc -I/builds/gbgbuild/bld/gcc/gcc-4.9.0/gcc/. -I/builds/gbgbuild/bld/gcc/gcc-4.9.0/gcc/../include -I./../intl -I/builds/gbgbuild/bld/gcc/gcc-4.9.0/gcc/../libcpp/include -I/usr/local/lib32-static/include -I/usr/local/lib32-static/include -I/usr/local/lib32-static/include -I/builds/gbgbuild/bld/gcc/gcc-4.9.0/gcc/../libdecnumber -I/builds/gbgbuild/bld/gcc/gcc-4.9.0/gcc/../libdecnumber/dpd -I../libdecnumber -I/builds/gbgbuild/bld/gcc/gcc-4.9.0/gcc/../libbacktrace -o tree-ssa-address.o -MT tree-ssa-address.o -MMD -MP -MF ./.deps/tree-ssa-address.TPo /builds/gbgbuild/bld/gcc/gcc-4.9.0/gcc/tree-ssa-address.c In file included from /builds/gbgbuild/bld/gcc/gcc-4.9.0/gcc/tree-ssa-address.c:1024:0: ./gt-tree-ssa-address.h:86:2: internal compiler error: in operator[], at vec.h:735 }; ^ libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [tree-ssa-address.o] Error 1 make[3]: Leaving directory `/builds/gbgbuild/bld/gcc/stbldap01/obj_stbldap01-4.9.0/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/builds/gbgbuild/bld/gcc/stbldap01/obj_stbldap01-4.9.0' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/builds/gbgbuild/bld/gcc/stbldap01/obj_stbldap01-4.9.0' make: *** [all] Error 2
I have been bootstrapping GCC trunk and 4.9 on AIX 7.1 without any failures.
Okay, I can confirm this now. Bootstrap is working on trunk and was working at the point of the branch, so this is due to some 4.9-specific patch.
731 template<typename T, typename A> 732 inline T & 733 vec<T, A, vl_embed>::operator[] (unsigned ix) 734 { 735 gcc_checking_assert (ix < m_vecpfx.m_num); 736 return m_vecdata[ix]; 737 } 3153 gcc_checking_assert (true_predicate_p (&(*info->entry)[0].predicate));
AIX bootstraps at the gcc-4_9-branch creation point, but fails at GCC 4.9.0 release point. Trunk also bootstraps successfully. I am trying to bisect. r209304 okay r209518 fail
Isn't it --enable-checking=yes vs. --enable-checking=release ? Bet that is the most important change since 4.9.0 branch creation.
Torbjorn: What release of GCC are you using as the system compiler to bootstrap?
I used gcc-4.8.2
I reproduced the failure starting with both GCC 4.6.3 and GCC 4.8.1. However, I am seeing some very strange results: r209278 built in /tmp/20140412 SUCCESS r209300 (trunk before branch) built in /tmp/209300 SUCCESS r209304 (branch before DEV-PHASE commit) built in /tmp/209304 SUCCESS r209304 built in /tmp/G49 FAIL I am testing again with /tmp/Z49 This is starting to look like either the build directory name or build path length affects this failure.
Torbjorn: could you try building in a different directory, e.g., /builds/YYYYMMDD for the date or some random number?
I have started the build on a local filesystem with a shorter path (/home/tga01/obj_stbldap01-4.9.0). The previous build was done on a nfs partition. The build in our environment is slow. Usually a week. The error appeared after about two days.
No failure but restarted it in /home/tga01/obj_gcc with the thought of having a shorter and simpler path.
Are you using GNU Bash as your SHELL (recommended in the target-specific installation instructions). It should not take that long to bootstrap GCC on a recent system. AIX /bin/sh runs configure very slowly.
I got the same error this time. I use bash but looking at config.log I see that /bin/sh is used. I have seen nothing regarding this in the target-specific installation instructions. I have restarted the build using CONFIG_SHELL=/usr/local/bin/bash. Maybe that will make a difference :-)
It did not make any difference - but the build was really much faster! Thanks for the info on using bash.
#0 _Z11fancy_abortPKciS0_ ( file=0x11dc62b8 <gt_ggc_r_gt_cp_method_h+94056> "/home/dje/src/gcc/gcc/vec.h", line=735, function=0x11dc62e0 <gt_ggc_r_gt_cp_method_h+94096> "operator[]") at /home/dje/src/gcc/gcc/diagnostic.c:1190 #1 0x100f8fd0 in _ZN3vecI15size_time_entry5va_gc8vl_embedEixEj (this=0x0, ix=0) at /home/dje/src/gcc/gcc/vec.h:735 #2 0x11247914 in _ZL27estimate_node_size_and_timeP11cgraph_nodej3vecIP9tree_node7va_heap6vl_ptrES6_S1_IP21ipa_agg_jump_functionS4_S5_EPiSA_SA_SA_S1_I20inline_param_summaryS4_S5_E (node=0x700099c0, possible_truths=0, known_vals=..., known_binfos=..., known_aggs=..., ret_size=0x2ff224b0, ret_min_size=0x0, ret_time=0x0, ret_hints=0x0, inline_param_summary=...) at /home/dje/src/gcc/gcc/ipa-inline-analysis.c:3153 #3 0x11249df4 in _Z21do_estimate_edge_sizeP11cgraph_edge (edge=0x71270b80) at /home/dje/src/gcc/gcc/ipa-inline-analysis.c:3722 #4 0x112e0cbc in _ZL18estimate_edge_sizeP11cgraph_edge (edge=0x71270b80) at /home/dje/src/gcc/gcc/ipa-inline.h:281 #5 0x112e0da4 in _ZL20estimate_edge_growthP11cgraph_edge (edge=0x71270b80) at /home/dje/src/gcc/gcc/ipa-inline.h:294 #6 0x112e189c in _Z11inline_callP11cgraph_edgebP3vecIS0_7va_heap6vl_ptrEPib ( e=0x71270b80, update_original=true, new_edges=0x0, overall_size=0x0, update_overall_summary=true) at /home/dje/src/gcc/gcc/ipa-inline-transform.c:233 #7 0x112da9fc in _ZL21inline_to_all_callersP11cgraph_nodePv (node=0x700099c0, data=0x2ff22780) at /home/dje/src/gcc/gcc/ipa-inline.c:1980 #8 0x1096637c in _Z27cgraph_for_node_and_aliasesP11cgraph_nodePFbS0_PvES1_b ( node=0x700099c0, callback=@0x30323bb0: 0x112da8f0 <_ZL21inline_to_all_callersP11cgraph_nodePv>, data=0x2ff22780, include_overwritable=true) at /home/dje/src/gcc/gcc/cgraph.c:2243 #9 0x1096641c in _Z27cgraph_for_node_and_aliasesP11cgraph_nodePFbS0_PvES1_b ( node=0x71251840, callback=@0x30323bb0: 0x112da8f0 <_ZL21inline_to_all_callersP11cgraph_nodePv>, data=0x2ff22780, include_overwritable=true) at /home/dje/src/gcc/gcc/cgraph.c:2251 #10 0x112daf2c in _ZL10ipa_inlinev () at /home/dje/src/gcc/gcc/ipa-inline.c:2111 #11 0x112dc0bc in _ZN50_GLOBAL__N__Z20speculation_useful_pP11cgraph_edgeb15pass_ipa_inline7executeEv (this=0x303a9428) at /home/dje/src/gcc/gcc/ipa-inline.c:2407 #12 0x101113a4 in _Z16execute_one_passP8opt_pass (pass=0x303a9428) at /home/dje/src/gcc/gcc/passes.c:2233 #13 0x10112810 in _Z21execute_ipa_pass_listP8opt_pass (pass=0x303a9428) at /home/dje/src/gcc/gcc/passes.c:2611 #14 0x1108e334 in _ZL10ipa_passesv () at /home/dje/src/gcc/gcc/cgraphunit.c:2084 #15 0x1108e778 in _Z7compilev () at /home/dje/src/gcc/gcc/cgraphunit.c:2174 #16 0x1108eccc in _Z25finalize_compilation_unitv () at /home/dje/src/gcc/gcc/cgraphunit.c:2329 #17 0x1085b838 in _Z28cp_write_global_declarationsv () at /home/dje/src/gcc/gcc/cp/decl2.c:4611 #18 0x100027e8 in _ZL12compile_filev () at /home/dje/src/gcc/gcc/toplev.c:562 #19 0x10005cac in _ZL10do_compilev () at /home/dje/src/gcc/gcc/toplev.c:1914 #20 0x10005ed0 in _Z11toplev_mainiPPc (argc=3, argv=0x2ff22bc0) at /home/dje/src/gcc/gcc/toplev.c:1990 #21 0x100006c8 in main (argc=3, argv=0x2ff22bc0) at /home/dje/src/gcc/gcc/main.c:36
3153 gcc_checking_assert (true_predicate_p (&(*info->entry)[0].predicate)); (gdb) print info $1 = (inline_summary *) 0x704970f8 (gdb) print info->entry $2 = (vec *) 0x0 (gdb) print *info $3 = {estimated_self_stack_size = 0, self_size = 0, self_time = 0, min_size = 0, inlinable = 0, estimated_stack_size = 0, stack_frame_offset = 0, time = 0, size = 0, conds = 0x0, entry = 0x0, loop_iterations = 0x0, loop_stride = 0x0, array_index = 0x0, growth = 0, scc_no = 0}
(gdb) print node->name() $37 = 0x303f2768 "void __builtin_unreachable()" (gdb) print *edge $32 = {count = 0, caller = 0x70460a80, callee = 0x700099c0, prev_caller = 0x0, next_caller = 0x0, prev_callee = 0x0, next_callee = 0x0, call_stmt = 0x71272140, indirect_info = 0x0, aux = 0x0, inline_failed = CIF_UNREACHABLE, lto_stmt_uid = 0, frequency = 0, uid = 41, indirect_inlining_edge = 0, indirect_unknown_callee = 0, call_stmt_cannot_inline_p = 0, can_throw_external = 1, speculative = 0}
Created attachment 32761 [details] Pre-processed file that causes ICE The pre-processed file crashes both 4.9 branch and trunk in ipa-inline-analysis.c:estimate_node_size_and_time().
What seems to go wrong is that we try to analyze builtin_unreachable size/time that should not happen. It would help to know the dump_cgraph_node of the node of builtin_unreachable (or have full cgraph dump). I will try to reproduce it at the gcc farm, probably after my arrival back to calgary, at 13th of May.
(gdb) print debug_cgraph_node(node) __builtin_unreachable/1630 (void __builtin_unreachable()) @700099c0 Type: function Visibility: external public visibility_specified artificial References: Referring: Availability: not_available First run: 0 Function flags: Called by: _ZN10vec_prefix20calculate_allocationEPS_jb/554 (can throw external) Calls: $1 = 10
Created attachment 32770 [details] full cgraph dump gzipped
The failure first appears with r208916, producing a different error: In file included from /home/dje/src/src/gcc/tree-core.h:27:0, from /home/dje/src/src/gcc/tree.h:23, from /home/dje/src/src/gcc/tree-ssa-address.c:27: /home/dje/src/src/gcc/vec.h: In function 'rtx_def* addr_for_mem_ref(mem_address*, addr_space_t, bool)': /home/dje/src/src/gcc/vec.h:253:68: internal compiler error: in cgraph_get_body, at cgraph.c:3025 return calculate_allocation_1 (pfx->m_alloc, pfx->m_num + reserve); ^
To clarify, the error shown in Comment 22 is for GCC configured with --enable-checking=release, which is necessary for tree-ssa-address.c to cause a failure. With normal checking, the error shown in the initial report occurs. The failures begin with r208916.
Hi, the problem turns out to be quite ugly issue where inline_call removes dead alias, but the alias is being walked by cgraph_for_node_and_aliases used by ipa-inline to inline function into all callees. The attached patch (I am still testing) makes us to restart the walk in this case. Honza Index: ipa-inline-transform.c =================================================================== --- ipa-inline-transform.c (revision 210624) +++ ipa-inline-transform.c (working copy) @@ -214,6 +214,7 @@ it is NULL. If UPDATE_OVERALL_SUMMARY is false, do not bother to recompute overall size of caller after inlining. Caller is required to eventually do it via inline_update_overall_summary. + If callee_removed is non-NULL, set it to true if we removed callee node. Return true iff any new callgraph edges were discovered as a result of inlining. */ @@ -221,7 +222,8 @@ bool inline_call (struct cgraph_edge *e, bool update_original, vec<cgraph_edge_p> *new_edges, - int *overall_size, bool update_overall_summary) + int *overall_size, bool update_overall_summary, + bool *callee_removed) { int old_size = 0, new_size = 0; struct cgraph_node *to = NULL; @@ -260,6 +262,8 @@ { next_alias = cgraph_alias_target (alias); cgraph_remove_node (alias); + if (callee_removed) + *callee_removed = true; alias = next_alias; } else Index: ipa-inline.c =================================================================== --- ipa-inline.c (revision 210624) +++ ipa-inline.c (working copy) @@ -1971,6 +1971,8 @@ inline_to_all_callers (struct cgraph_node *node, void *data) { int *num_calls = (int *)data; + bool callee_removed = false; + while (node->callers && !node->global.inlined_to) { struct cgraph_node *caller = node->callers->caller; @@ -1987,7 +1989,7 @@ inline_summary (node->callers->caller)->size); } - inline_call (node->callers, true, NULL, NULL, true); + inline_call (node->callers, true, NULL, NULL, true, &callee_removed); if (dump_file) fprintf (dump_file, " Inlined into %s which now has %i size\n", @@ -1997,8 +1999,10 @@ { if (dump_file) fprintf (dump_file, "New calls found; giving up.\n"); - return true; + return callee_removed; } + if (callee_removed) + return true; } return false; } @@ -2244,8 +2248,9 @@ int num_calls = 0; cgraph_for_node_and_aliases (node, sum_callers, &num_calls, true); - cgraph_for_node_and_aliases (node, inline_to_all_callers, - &num_calls, true); + while (cgraph_for_node_and_aliases (node, inline_to_all_callers, + &num_calls, true)) + ; remove_functions = true; } } Index: ipa-inline.h =================================================================== --- ipa-inline.h (revision 210624) +++ ipa-inline.h (working copy) @@ -236,7 +236,8 @@ bool speculation_useful_p (struct cgraph_edge *e, bool anticipate_inlining); /* In ipa-inline-transform.c */ -bool inline_call (struct cgraph_edge *, bool, vec<cgraph_edge_p> *, int *, bool); +bool inline_call (struct cgraph_edge *, bool, vec<cgraph_edge_p> *, int *, bool, + bool *callee_removed = NULL); unsigned int inline_transform (struct cgraph_node *); void clone_inlined_nodes (struct cgraph_edge *e, bool, bool, int *, int freq_scale);
Thanks for tracking this down. I will test it as well. AIX is a very good canary for these types of bugs.
> Thanks for tracking this down. I will test it as well. AIX is a very good > canary for these types of bugs. Yeah, the difference here is that we produce a lot more local aliases on AIX than elsewhere. We discussed it previously - it is because middle-end believes that comdat mechanizm is missing and only WEAK is used. If AIX linker has mechanizm to throw away unused comdat functions, we ought to model this to the middle-end. (perhaps something like unreachable_symbol_removal_in_linker target hook or so) Honza
The GCC 4.9 branch bootstraps with the patch for me. I'm running the testsuite now.
Author: hubicka Date: Wed May 21 05:40:09 2014 New Revision: 210673 URL: http://gcc.gnu.org/viewcvs?rev=210673&root=gcc&view=rev Log: PR bootstrap/60984 * ipa-inline-transform.c (inline_call): Use add CALLEE_REMOVED parameter. * ipa-inline.c (inline_to_all_callers): If callee was removed; return. (ipa_inline): Loop inline_to_all_callers until no more aliases are removed. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/ipa-inline-transform.c branches/gcc-4_9-branch/gcc/ipa-inline.c branches/gcc-4_9-branch/gcc/ipa-inline.h
Author: hubicka Date: Wed May 21 05:41:46 2014 New Revision: 210674 URL: http://gcc.gnu.org/viewcvs?rev=210674&root=gcc&view=rev Log: PR bootstrap/60984 * ipa-inline-transform.c (inline_call): Use add CALLEE_REMOVED parameter. * ipa-inline.c (inline_to_all_callers): If callee was removed; return. (ipa_inline): Loop inline_to_all_callers until no more aliases are removed. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline-transform.c trunk/gcc/ipa-inline.c trunk/gcc/ipa-inline.h
Bootstrap issue ought to be fixed. I do not have base for a testsuite, but hope we are in shape now.
This worked for me. Thanks a lot :-)
Successfully built on AIX 5.3.0. Thanks.