[Bug debug/95098] Out of scope variable visible during debugging at Og

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aoliva at gcc dot gnu.org,
                   |                            |edlinger at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Don't see this with gdb:

(gdb) start
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Temporary breakpoint 4 at 0x4004bd: file z.c, line 11.
Starting program: /home/rguenther/obj/gcc/a.out 

Temporary breakpoint 4, main () at z.c:11
11      int main() { b(); }
(gdb) s

Breakpoint 3, b () at z.c:4
4           for (g_2 = 21; (g_2 < (-27)); g_2 = 0)
(gdb) p l_9
No symbol "l_9" in current context.
(gdb) info locals
l_10 = <optimized out>

note there _is_ l_9 in the DWARF, even with a location:

 <2><ba>: Abbrev Number: 8 (DW_TAG_lexical_block)
    <bb>   DW_AT_low_pc      : 0xa
    <c3>   DW_AT_high_pc     : 0x0
 <3><cb>: Abbrev Number: 9 (DW_TAG_variable)
    <cc>   DW_AT_name        : l_9
    <d0>   DW_AT_decl_file   : 1
    <d1>   DW_AT_decl_line   : 7
    <d2>   DW_AT_decl_column : 7
    <d3>   DW_AT_type        : <0xeb>
    <d7>   DW_AT_location    : 10 byte block: 3 0 0 0 0 0 0 0 0 9f     
(DW_OP_addr: 0; DW_OP_stack_value)

but

0000000000000000 <b>:
   0:   c7 05 00 00 00 00 15    movl   $0x15,0x0(%rip)        # a <b+0xa>
   7:   00 00 00 
   a:   c3                      retq   

and certainly the DW_AT_high_pc of the lexical block looks "odd" - the
block is not existent.  Assembly:

b:
.LFB0:
        .file 1 "z.c"
        .loc 1 2 9 view -0
        .cfi_startproc
        .loc 1 3 5 view .LVU1
        .loc 1 4 5 view .LVU2
        .loc 1 4 14 is_stmt 0 view .LVU3
        movl    $21, g_2(%rip)
        .loc 1 4 20 is_stmt 1 view .LVU4
.LBB2:
        .loc 1 7 2 view .LVU5
.LVL0:
        .loc 1 8 2 view .LVU6
.LBE2:
        .loc 1 10 1 is_stmt 0 view .LVU7
        ret

so you can see .LBB2 to .LBE2 do not contain any actual instructions.
GIMPLE we expand from:

 b ()
{
  <bb 2> [local count: 1073741824]:
  [z.c:3:5] # DEBUG BEGIN_STMT
  [z.c:4:5] # DEBUG BEGIN_STMT
  [z.c:4:14] g_2 = 21;
  [z.c:4:20] # DEBUG BEGIN_STMT
  [z.c:7:2] # DEBUG BEGIN_STMT
  [z.c:7:7] # DEBUG l_9 => [z.c:7:13] &a
  [z.c:8:2] # DEBUG BEGIN_STMT
  [z.c:8:2] return;

does lldb try to interpret location views yet?  I suppose it might get
confused about the is_stmt 0 on the movl and only stop at ret
even though the "last" location on that is line 10 (but is_stmt 0 again).

It's difficult to produce a meaningful line-number program for the
resulting assembler ;)