--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 12 Oct 2016, marxin at gcc dot wrote:

> --- Comment #5 from Martin Liška <marxin at gcc dot> ---
> Created attachment 39791
>   -->
> Really reduced test-case

So we are properly creating a DIE for m_fn1 early but then end up
removing it via prune_unused_types.  It looks like this is because
the DIE for C has the CU as parent rather than B::m_fn2.  It
first gets created in limbo (via dwarf2out_type_decl) because:

      /* If we're a function-scope tag, initially use a parent of NULL;
         this will be fixed up in decls_for_scope.  */
      if (decl_function_context (decl))
        context_die = NULL;

but we never end up calling dwarf2out_early_global_decl for B::m_fn2
and thus the limbo gets re-parented to the CU DIE (as we record
the TREE_TYPE for DW_TAG_class_type DIEs, not the TYPE_DECL):

              if (DECL_P (node->created_for))
                origin = get_context_die (DECL_CONTEXT 
              else if (TYPE_P (node->created_for))
                origin = scope_die_for (node->created_for, comp_unit_die 

and scope_die_for simply doesn't handle FUNCTION_DECL as containing_scope.

B::m_fn2 has been optimized out as unreachable which is the reason we
are not ending up in decls_for_scope eventually.

IMHO optimizing C as unused is ok.  The question is why we end up
with inlining m_fn1 ...

looks like we devirtualize the call in fn1 to B::C::m_fn1:

t.ii:25:14: note: speculatively devirtualizing call in void fn1(A&)/8 to 
virtual bool B::m_fn2() const::C::m_fn1() const/0
Indirect call -> speculative call void fn1(A&)/8 => virtual bool 
B::m_fn2() const::C::m_fn1() const/0
1 polymorphic calls, 0 devirtualized, 1 speculatively devirtualized, 0 
0 have multiple targets, 0 overwritable, 0 already speculated (0 agree, 0 
disagree), 0 external, 0 not defined, 0 artificial, 0 infos dropped
Symbol table:

and -fno-devirtualize fixes it.

-> we shouldn't reclaim B::m_fn2 when we later end up devirtualizing
to B::m_fn2::C::m_fn1 (or rather we should never devirtualize to
a local class method?)

Reply via email to