| Message ID | CAAe5K+UZXbPFe-X9Q77whGfcwQkVLKbSfo2dknRvj-wrgFss_A@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
Is it a problem specific to LIPO? David On Sat, Aug 23, 2014 at 11:41 AM, Teresa Johnson <tejohnson@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 <tejohnson@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 | tejohnson@google.com | 408-460-2413
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 <davidxl@google.com> wrote: > Is it a problem specific to LIPO? > > David > > On Sat, Aug 23, 2014 at 11:41 AM, Teresa Johnson <tejohnson@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 <tejohnson@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 | tejohnson@google.com | 408-460-2413
Ok for google branch. David On Sat, Aug 23, 2014 at 11:58 AM, Teresa Johnson <tejohnson@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 <davidxl@google.com> wrote: >> Is it a problem specific to LIPO? >> >> David >> >> On Sat, Aug 23, 2014 at 11:41 AM, Teresa Johnson <tejohnson@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 <tejohnson@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 | tejohnson@google.com | 408-460-2413 > > > > -- > Teresa Johnson | Software Engineer | tejohnson@google.com | 408-460-2413
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
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 <tejohnson@google.com> Google ref b/16731481 * cgraphunit.c (analyze_functions): Don't remove origin node.