[Bug debug/94450] lto abstract variable emitted as concrete decl

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94450

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
So the current situation is similar to that of

static inline int foo(int i)
{
  static int j;
  j = i + 1;
  return j;
}

int bar(int i)
{
  return foo(i);
}

int baz(int i)
{
  return foo(i);
}

here we get

 <1><2d>: Abbrev Number: 2 (DW_TAG_subprogram)
    <2e>   DW_AT_name        : foo
    <32>   DW_AT_decl_file   : 1
    <33>   DW_AT_decl_line   : 1
    <34>   DW_AT_prototyped  : 1
    <34>   DW_AT_type        : <0x50>
    <38>   DW_AT_inline      : 3        (declared as inline and inlined)
    <39>   DW_AT_sibling     : <0x50>
...
 <2><46>: Abbrev Number: 4 (DW_TAG_variable)
    <47>   DW_AT_name        : j
    <49>   DW_AT_decl_file   : 1
    <4a>   DW_AT_decl_line   : 3
    <4b>   DW_AT_type        : <0x50>

...
 <1><57>: Abbrev Number: 6 (DW_TAG_subprogram)
    <58>   DW_AT_external    : 1
    <58>   DW_AT_name        : bar
...
 <2><83>: Abbrev Number: 8 (DW_TAG_inlined_subroutine)
    <84>   DW_AT_abstract_origin: <0x2d>
    <88>   DW_AT_low_pc      : 0x0
    <90>   DW_AT_high_pc     : 0x9
    <98>   DW_AT_call_file   : 1
    <99>   DW_AT_call_line   : 10
 <3><9a>: Abbrev Number: 9 (DW_TAG_formal_parameter)
    <9b>   DW_AT_abstract_origin: <0x3d>
    <9f>   DW_AT_location    : 1 byte block: 55         (DW_OP_reg5 (rdi))
 <3><a1>: Abbrev Number: 10 (DW_TAG_lexical_block)
    <a2>   DW_AT_low_pc      : 0x0
    <aa>   DW_AT_high_pc     : 0x9
 <4><b2>: Abbrev Number: 11 (DW_TAG_variable)
    <b3>   DW_AT_abstract_origin: <0x46>
    <b7>   DW_AT_location    : 9 byte block: 3 0 0 0 0 0 0 0 0  (DW_OP_addr: 0)

...

 <1><c4>: Abbrev Number: 12 (DW_TAG_subprogram)
    <c5>   DW_AT_external    : 1
    <c5>   DW_AT_name        : baz
...
 <2><ec>: Abbrev Number: 8 (DW_TAG_inlined_subroutine)
    <ed>   DW_AT_abstract_origin: <0x2d>
    <f1>   DW_AT_low_pc      : 0x10
    <f9>   DW_AT_high_pc     : 0x9
    <101>   DW_AT_call_file   : 1
    <102>   DW_AT_call_line   : 15
 <3><103>: Abbrev Number: 9 (DW_TAG_formal_parameter)
    <104>   DW_AT_abstract_origin: <0x3d>
    <108>   DW_AT_location    : 1 byte block: 55        (DW_OP_reg5 (rdi))
 <3><10a>: Abbrev Number: 10 (DW_TAG_lexical_block)
    <10b>   DW_AT_low_pc      : 0x10
    <113>   DW_AT_high_pc     : 0x9
 <4><11b>: Abbrev Number: 11 (DW_TAG_variable)
    <11c>   DW_AT_abstract_origin: <0x46>
    <120>   DW_AT_location    : 9 byte block: 3 0 0 0 0 0 0 0 0        
(DW_OP_addr: 0)


which also means at least two (in the DW_TAG_inlined_subroutine instances)
concrete variables named 'j'.  Not sure if the <46> DIE is a concrete
variable - DWARF doesn't have linkage attributes and the containing
subroutine DIE is marked with DW_AT_inline.

Note we're not emitting a concrete instance of the function which would
contain the "main" instance of 'j'.  Not sure what the DWARF for a
standalone concrete instantiation of 'j' would look like.

So current LTO is modeled after this, the early debug contains abstract
instances only (also for non-functions, thus global variables), albeit
not marked as such in all cases.  The LTRANS debug contains all concrete
(and inline) instances.