This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Context sensitive inline analysis


> 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 Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]