| Message ID | 20110427144436.GB1981@kam.mff.cuni.cz |
|---|---|
| State | New |
| Headers | show |
Honza, I continue to receive an ICE: /farm/dje/src/src/libstdc++-v3/include/precompiled/stdc++.h:94:0: /tmp/20110427/powerpc-ibm-aix5.3.0.0/libstdc++-v3/include/valarray:1163:1: internal compiler error: vector VEC(tree,base) index domain error, in evaluate_conditions_for_edge at ipa-inline-analysis.c:537 I was able to bootstrap with GCC just prior to your patch on Friday. - David On Wed, Apr 27, 2011 at 10:44 AM, Jan Hubicka <hubicka@ucw.cz> wrote: >> >> This may have caused: >> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48791 > > Oops, yes, it is mine. The insertion hook at expansion time is incorrectly called > after function is expanded, not before. > ipa-prop should deregister itself earlier, but that can be done incrementally. > I am testing the following and will commit if testing succeeds. > > Index: cgraphunit.c > =================================================================== > --- cgraphunit.c (revision 173025) > +++ cgraphunit.c (working copy) > @@ -233,6 +233,7 @@ cgraph_process_new_functions (void) > cgraph_finalize_function (fndecl, false); > cgraph_mark_reachable_node (node); > output = true; > + cgraph_call_function_insertion_hooks (node); > break; > > case CGRAPH_STATE_IPA: > @@ -258,12 +259,14 @@ cgraph_process_new_functions (void) > free_dominance_info (CDI_DOMINATORS); > pop_cfun (); > current_function_decl = NULL; > + cgraph_call_function_insertion_hooks (node); > break; > > case CGRAPH_STATE_EXPANSION: > /* Functions created during expansion shall be compiled > directly. */ > node->process = 0; > + cgraph_call_function_insertion_hooks (node); > cgraph_expand_function (node); > break; > > @@ -271,7 +274,6 @@ cgraph_process_new_functions (void) > gcc_unreachable (); > break; > } > - cgraph_call_function_insertion_hooks (node); > varpool_analyze_pending_decls (); > } > return output; >
> Honza, > > I continue to receive an ICE: > > /farm/dje/src/src/libstdc++-v3/include/precompiled/stdc++.h:94:0: > /tmp/20110427/powerpc-ibm-aix5.3.0.0/libstdc++-v3/include/valarray:1163:1: > internal compiler error: vector VEC(tree,base) index domain error, in > evaluate_conditions_for_edge at ipa-inline-analysis.c:537 > > I was able to bootstrap with GCC just prior to your patch on Friday. Hi, can I have a preprocessed testcase? The one attached to HP PR don't seem to reproduce for me. Perhaps we just need a bounds check here though I think we should catch all "evil" edges with can_inline_edge_p and never try to propagate across those. Honza
> On Thu, Apr 28, 2011 at 9:27 AM, Jan Hubicka <hubicka@ucw.cz> wrote: > >> Honza, > >> > >> I continue to receive an ICE: > >> > >> /farm/dje/src/src/libstdc++-v3/include/precompiled/stdc++.h:94:0: > >> /tmp/20110427/powerpc-ibm-aix5.3.0.0/libstdc++-v3/include/valarray:1163:1: > >> internal compiler error: vector VEC(tree,base) index domain error, in > >> evaluate_conditions_for_edge at ipa-inline-analysis.c:537 > >> > >> I was able to bootstrap with GCC just prior to your patch on Friday. > > Hi, > > can I have a preprocessed testcase? The one attached to HP PR don't seem > > to reproduce for me. Perhaps we just need a bounds check here though I think > > we should catch all "evil" edges with can_inline_edge_p and never try to propagate > > across those. > > The failure currently occurs when building stdc++.h.gch with -O2. Duh, this sounds scary. I am attaching fix for the HP failure. Hopefully it will fix yours, too. Reproducing gch ICE in cross would be more fun (and of course, GCH should not make difference, so it seems that we have some latent problem here too) > > Apparently this does not reproduce on PPC Linux using the original TOC > model (cmodel=small). Note that GCC on AIX still defaults to 32 bit > application and GCC on PPC Linux is 64 bit, so that might contribute > to the difference. Or the different process data layout of Linux vs > AIX avoiding failure from memory corruption. The problem on HP is weird iteraction of ipa-cp, early inliner and constructor merging pass. It needs !have_ctors/dtors target to reproduce and you really need to be lucky to get this happen. So I hope it is yours problem, too. At least yours testcase looks almost identical to HP and works for me now, too. Martin, this is an example why we probably shoudl update jump functions to represent the program after ipa-cp transform. In this case we simply construct new direct call into the clone and that one gets misanalyzed. Bootstrapped/regtested x86_64-linux, comitted. PR middle-end/48752 * ipa-inline.c (early_inliner): Disable when doing late addition of function. Index: ipa-inline.c =================================================================== *** ipa-inline.c (revision 173189) --- ipa-inline.c (working copy) *************** early_inliner (void) *** 1663,1668 **** --- 1663,1676 ---- if (seen_error ()) return 0; + /* Do nothing if datastructures for ipa-inliner are already computed. This happens when + some pass decides to construct new function and cgraph_add_new_function calls lowering + passes and early optimization on it. This may confuse ourself when early inliner decide + to inline call to function clone, because function clones don't have parameter list + in ipa-prop matching their signature. */ + if (ipa_node_params_vector) + return 0; + #ifdef ENABLE_CHECKING verify_cgraph_node (node); #endif
Honza, This patch appears to fix the failure on AIX: my build progressed past libstdc++. Thanks, David 2011/4/30 Jan Hubicka <hubicka@ucw.cz>: >> On Thu, Apr 28, 2011 at 9:27 AM, Jan Hubicka <hubicka@ucw.cz> wrote: >> >> Honza, >> >> >> >> I continue to receive an ICE: >> >> >> >> /farm/dje/src/src/libstdc++-v3/include/precompiled/stdc++.h:94:0: >> >> /tmp/20110427/powerpc-ibm-aix5.3.0.0/libstdc++-v3/include/valarray:1163:1: >> >> internal compiler error: vector VEC(tree,base) index domain error, in >> >> evaluate_conditions_for_edge at ipa-inline-analysis.c:537 >> >> >> >> I was able to bootstrap with GCC just prior to your patch on Friday. >> > Hi, >> > can I have a preprocessed testcase? The one attached to HP PR don't seem >> > to reproduce for me. Perhaps we just need a bounds check here though I think >> > we should catch all "evil" edges with can_inline_edge_p and never try to propagate >> > across those. >> >> The failure currently occurs when building stdc++.h.gch with -O2. > > Duh, this sounds scary. > > I am attaching fix for the HP failure. Hopefully it will fix yours, too. > Reproducing gch ICE in cross would be more fun (and of course, GCH should not > make difference, so it seems that we have some latent problem here too) >> >> Apparently this does not reproduce on PPC Linux using the original TOC >> model (cmodel=small). Note that GCC on AIX still defaults to 32 bit >> application and GCC on PPC Linux is 64 bit, so that might contribute >> to the difference. Or the different process data layout of Linux vs >> AIX avoiding failure from memory corruption. > > The problem on HP is weird iteraction of ipa-cp, early inliner and constructor > merging pass. It needs !have_ctors/dtors target to reproduce and you really > need to be lucky to get this happen. So I hope it is yours problem, too. At > least yours testcase looks almost identical to HP and works for me now, too. > > Martin, this is an example why we probably shoudl update jump functions to > represent the program after ipa-cp transform. In this case we simply construct > new direct call into the clone and that one gets misanalyzed. > > Bootstrapped/regtested x86_64-linux, comitted. > > PR middle-end/48752 > * ipa-inline.c (early_inliner): Disable when doing late > addition of function. > Index: ipa-inline.c > =================================================================== > *** ipa-inline.c (revision 173189) > --- ipa-inline.c (working copy) > *************** early_inliner (void) > *** 1663,1668 **** > --- 1663,1676 ---- > if (seen_error ()) > return 0; > > + /* Do nothing if datastructures for ipa-inliner are already computed. This happens when > + some pass decides to construct new function and cgraph_add_new_function calls lowering > + passes and early optimization on it. This may confuse ourself when early inliner decide > + to inline call to function clone, because function clones don't have parameter list > + in ipa-prop matching their signature. */ > + if (ipa_node_params_vector) > + return 0; > + > #ifdef ENABLE_CHECKING > verify_cgraph_node (node); > #endif >
Index: cgraphunit.c =================================================================== --- cgraphunit.c (revision 173025) +++ cgraphunit.c (working copy) @@ -233,6 +233,7 @@ cgraph_process_new_functions (void) cgraph_finalize_function (fndecl, false); cgraph_mark_reachable_node (node); output = true; + cgraph_call_function_insertion_hooks (node); break; case CGRAPH_STATE_IPA: @@ -258,12 +259,14 @@ cgraph_process_new_functions (void) free_dominance_info (CDI_DOMINATORS); pop_cfun (); current_function_decl = NULL; + cgraph_call_function_insertion_hooks (node); break; case CGRAPH_STATE_EXPANSION: /* Functions created during expansion shall be compiled directly. */ node->process = 0; + cgraph_call_function_insertion_hooks (node); cgraph_expand_function (node); break; @@ -271,7 +274,6 @@ cgraph_process_new_functions (void) gcc_unreachable (); break; } - cgraph_call_function_insertion_hooks (node); varpool_analyze_pending_decls (); } return output;