[Bug debug/105124] New: -Og loses DWARF value for a reassigned variable that is kept instead by other optimization levels

[Bug debug/105124] New: -Og loses DWARF value for a reassigned variable that is kept instead by other optimization levels

[assaiante at diag dot uniroma1.it]

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

            Bug ID: 105124
           Summary: -Og loses DWARF value for a reassigned variable that
                    is kept instead by other optimization levels
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: assaiante at diag dot uniroma1.it
  Target Milestone: ---

In this minimized C code, variable l_62 appears as optimized out at line 6,
where it is assigned again with the same value and used in the assignment of
global variable a. The variable is then available at line 8 with its correct
value 6 coming from the update at line 7.

This behavior only occurs when the optimization level is Og, while at -O1 and
higher optimization levels the variable is always visible with a correct value
available.

Interestingly, if we assign l_62 for instance with 2 at line 4, then the issue
is no longer present at Og and the value 2 is displayed at line 6 (just like at
-O1/O2/O3). We also note that, in this case, at -O1/-Og the DWARF info contains
values 0 and 6, while at -O2/-O3 also value 0 which is in use only between line
6 and 7.

We provide below a detailed analysis on x64.

$ cat a.c
short a;
int foo1() { return 0; }
short foo0(int d) {
  int e, f = 11, l_62 = 0;
  e = foo1();
  a = f | (l_62 = e) >= d;
  l_62 = 6;
  return d;
}
int main() { foo0(0); }


GCC and GDB version (GCC commit id: 500d3f0a302):
$ gcc --version
gcc (GCC) 12.0.0 20211227 (experimental)

$ gdb --version
GNU gdb (GDB) 11.2

GDB trace:
$ gcc -Og -g a.c -o opt
$ gdb -q opt
Reading symbols from opt...
(gdb) b 6
Breakpoint 1 at 0x40048f: file a.c, line 6.
(gdb) r
Starting program: /home/stepping/4/reduce/opt 

Breakpoint 1, foo0 (d=d@entry=0) at a.c:6
6         a = f | (l_62 = e) >= d;
(gdb) info loc
e = <optimized out>
f = 11
l_62 = <optimized out>
(gdb) n
8         return d;
(gdb) info loc
e = <optimized out>
f = 11
l_62 = 6


ASM of foo0 function:
000000000040048c <foo0>:
 40048c:       53                      push   %rbx
 40048d:       89 fb                   mov    %edi,%ebx
 40048f:       66 c7 05 92 0b 20 00    movw   $0xb,0x200b92(%rip)        #
60102a <a>
 400496:       0b 00  
 400498:       89 d8                   mov    %ebx,%eax
 40049a:       5b                      pop    %rbx
 40049b:       c3                      retq 


DWARF at -Og:
0x000000c9:     DW_TAG_variable
                  DW_AT_name    ("l_62")
                  DW_AT_decl_file       ("/home/stepping/4/reduce/a.c")
                  DW_AT_decl_line       (4)
                  DW_AT_decl_column     (0x12)
                  DW_AT_type    (0x0000007f "int")
                  DW_AT_location        (0x00000010: 
                     [0x000000000040048f, 0x000000000040048f): DW_OP_lit0,
DW_OP_stack_value
                     [0x0000000000400498, 0x000000000040049c): DW_OP_lit6,
DW_OP_stack_value)
                  DW_AT_unknown_2137    (0x0000000c)



>From a quick analysis of DWARF symbols, the problem seems to be in the location
definition of the variable. The first entry is an empty range when it should
probably include the instruction at 40048f which is associated with line 6. We
tried to manually patch the executable file from -Og by setting the first entry
of the location [0x000000000040048f, 0x000000000040048f) to
[0x000000000040048f, 0x0000000000400498). After the change, the variable is
displayed. 

At -O1 and higher optimization levels, the first entry of the DWARF location
info contains the correct range that includes the ASM instruction associated
with line 6.

DWARF at O1 (identical at O2/O3, only addresses change):
0x000000a1:       DW_TAG_variable
                    DW_AT_abstract_origin       (0x000000e2 "l_62")
                    DW_AT_location      (0x00000020: 
                       [0x00000000004003a0, 0x00000000004003ac): DW_OP_lit0,
DW_OP_stack_value
                       [0x00000000004003ac, 0x00000000004003af): DW_OP_lit6,
DW_OP_stack_value)
                    DW_AT_unknown_2137  (0x0000001c)

 If we interpret the code correctly, foo1 is always
inlined/constant-propagated, while foo0 is inlined at other optimization levels
but not at -Og.


We have also tested older gcc versions (6.4, 7.5, 8.4, 9.3, 10.3, 11.1) and the
variable l_62 is always optimized out on line 6 at each optimization level.
The only exception is gcc-7 that produces (only at Og) a wrong debug
information, since at line 6 l_62 has 6 as current value.

[Bug debug/105124] -Og loses DWARF value for a reassigned variable that is kept instead by other optimization levels

[assaiante at diag dot uniroma1.it]

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

--- Comment #1 from Cristian Assaiante <assaiante at diag dot uniroma1.it> ---
We suspect this may be related to bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108 but this time the behaviors
at -O1 and -Og are different