On Fri, Mar 24, 2017 at 8:46 AM, Jakub Jelinek <ja...@redhat.com> wrote: > On Thu, Mar 23, 2017 at 05:24:31PM -0400, Jason Merrill wrote: >> On Thu, Mar 23, 2017 at 4:44 PM, Jakub Jelinek <ja...@redhat.com> wrote: >> > The following C testcase shows how profiledbootstrap fails with checking >> > compiler. We have a (nested) FUNCTION_DECL inside of BLOCK_VARS of an >> > inline function, when it gets inlined, it is moved into >> > BLOCK_NONLOCALIZED_VARS. And, decls_for_scope calls process_scope_var >> > with NULL decl and non-NULL origin for all BLOCK_NONLOCALIZED_VARS. >> > That is fine for variables, but for FUNCTION_DECLs it can actually >> > try to dwarf2out_abstract_function that FUNCTION_DECL, which should be >> > really done only when it is inlined (i.e. BLOCK_ABSTRACT_ORIGIN of >> > some BLOCK). >> >> And when it's cloned. >> >> But does it make sense for gen_decl_die to call >> dwarf2out_abstract_function when decl is null? That seems wrong. > > Before r144529 we had just: > if (DECL_ORIGIN (decl) != decl) > dwarf2out_abstract_function (DECL_ABSTRACT_ORIGIN (decl)); > and that is indeed to handle clones etc. > > r144529 changed that to: > if (origin || DECL_ORIGIN (decl) != decl) > dwarf2out_abstract_function (DECL_ABSTRACT_ORIGIN (decl)); > All of the decl is NULL introduced in r144529 implies decl_or_origin > is abstract. > > Removing that origin || wouldn't really work, we'd have to rewrite most of > gen_decl_die FUNCTION_DECL handling to use decl_or_origin instead of > decl etc. > > But it doesn't look right to me, conceptually a FUNCTION_DECL in > BLOCK_NONLOCALIZED_VARS is nothing that represents a clone or something > abstract in itself. We can't keep it in BLOCK_VARS just because those > are chained through DECL_CHAIN and a single FUNCTION_DECL can't be > put into multiple BLOCK_VARS chains. It is still the same FUNCTION_DECL, > not a sign that we want to have in each inline function a separate > function declaration with abstract origin of the original FUNCTION_DECL.
Yeah, the thing BLOCK_NONLOCALIZED_VARS wants to do is optimize generated dwarf by adding a DW_AT_abstract_origin (just to refer to the subprogram DIE) but it doesn't actually care about refering to an abstract instance (a concrete one would work just fine). So I think in the context of scope vars calling dwarf2out_abstract_function is _always_ wrong. But it would require quite some refactoring to do this in a clean way. Richard. > Jakub
