Re: [RFA] dwarf2out.c:eliminate_regs() bug

[Maxim Kuvyrkov <maxim@codesourcery.com>]

Richard Guenther wrote:
...
> Yes, though we should probably try to catch the DECL_ABSTRACT case
> further up the call chain - there shouldn't be any location lists for abstract
> function.  Thus, see why
> 
> static dw_die_ref
> gen_formal_parameter_die (tree node, tree origin, dw_die_ref context_die)
> ...
>       if (! DECL_ABSTRACT (node_or_origin))
>         add_location_or_const_value_attribute (parm_die, node_or_origin,
>                                                DW_AT_location);
> 
> the node_or_origin of the param isn't DECL_ABSTRACT.  In the end the
> above check should have avoided the situation you run into.

The origin_or_origin (== origin) turned out to be 'this' pointer.  It 
came from BLOCK_NONLOCALIZED_VARs in decls_for_scope():

static void
decls_for_scope (tree stmt, dw_die_ref context_die, int depth)
{
...
    for (i = 0; i < BLOCK_NUM_NONLOCALIZED_VARS (stmt); i++)
      process_scope_var (stmt, NULL, BLOCK_NONLOCALIZED_VAR (stmt, i),
                         context_die);
...
}

set_decl_abstract_flags() doesn't seem to process 
BLOCK_NONLOCALIZED_VARs.  From what I gather, this is correct behavior.

At this point I got the feeling that something is clobbering the 
information.  There is this patch by Honza 
(http://gcc.gnu.org/viewcvs/trunk/gcc/dwarf2out.c?r1=151901&r2=151917) 
that fixes a clobbering issue with abstract functions.  Backporting it 
to my sources fixed the problem, yay!

Honza, does the bug you've fixed with the above patch resemble the 
problem I've stumbled into?

Regards,

--
Maxim K.