Ok for google branch. David
On Sat, Aug 23, 2014 at 11:58 AM, Teresa Johnson <tejohn...@google.com> wrote: > The ICE is, because we create a new node when querying the node during > symtab_remove_unreachable_nodes after LIPO linking is complete, and > then try to access its resolved node, for which there is none. Trunk > has the same code in these two locations, but the creation of a new > node after deleting the first does not cause any problems. > Teresa > > On Sat, Aug 23, 2014 at 11:50 AM, Xinliang David Li <davi...@google.com> > wrote: >> Is it a problem specific to LIPO? >> >> David >> >> On Sat, Aug 23, 2014 at 11:41 AM, Teresa Johnson <tejohn...@google.com> >> wrote: >>> This patch ensures we don't prematurely delete an abstract origin node, >>> leading >>> to creating a new one after LIPO linking when we invoke similar handling in >>> symtab_remove_unreachable_nodes, which then does not have a resolved node. >>> It >>> makes the handling of such nodes equivalent to that in >>> symtab_remove_unreachable_nodes. >>> >>> Tested with regression tests and internal benchmarks. Ok for google/4_9 >>> >>> 2014-08-23 Teresa Johnson <tejohn...@google.com> >>> >>> Google ref b/16731481 >>> * cgraphunit.c (analyze_functions): Don't remove origin node. >>> >>> Index: cgraphunit.c >>> =================================================================== >>> --- cgraphunit.c (revision 214320) >>> +++ cgraphunit.c (working copy) >>> @@ -1051,6 +1051,7 @@ analyze_functions (void) >>> struct cgraph_node *origin_node >>> = cgraph_get_node (DECL_ABSTRACT_ORIGIN (decl)); >>> origin_node->used_as_abstract_origin = true; >>> + enqueue_node (origin_node); >>> } >>> } >>> else >>> >>> -- >>> Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413 > > > > -- > Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413