[Bug debug/78685] -Og generates too many ""s

[fredrik at dolda2000 dot com]

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

--- Comment #11 from Fredrik Tolf  ---
(In reply to Richard Biener from comment #10)
> That is, it is reasonable to lose track of z in
> 
>   int a = (x + z) + b;
> 
> but only after x + z is computed.

Just for the record, I disagree that it's okay to lose z after that. As I
explained in #85059, not having access to variable values after they've been
consumed is one of the absolute main reasons I never use -Og.

[Bug rtl-optimization/85059] New: Compiling with -Og should preserve variable values

[fredrik at dolda2000 dot com]

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

Bug ID: 85059
   Summary: Compiling with -Og should preserve variable values
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fredrik at dolda2000 dot com
  Target Milestone: ---

One of the most valuable resources when debugging is being able to see the
values of variables (including function arguments), even when those values are
technically dead in the program. If the purpose of the `-Og' optimization
option is, as the manual states, to "optimize the debugging experience", then I
think it would make a lot of sense for it to ensure that variable values are
not thrown away just because they're dead in the dataflow. In practice, this is
the main and foremost reason why I never use `-Og' when debugging a program.

Just as a practical example, consider this C file:

int *b(void *);

int a(void *obj)
{
return(b(obj)[0]);
}

Consider the case where b() returns an invalid pointer and a() crashes on
dereferencing it. In such a case, it would likely be enormously helpful to have
the parameter value `obj' to figure out why b() failed. However, when this file
is compiled with `-Og', that value is no longer present after the call to b().
To illustrate:

$ gcc -ggdb -Og -c -o test.o test.c
$ objdump -dr test.o

test.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0:   48 83 ec 08 sub$0x8,%rsp
   4:   e8 00 00 00 00  callq  9 <a+0x9>
5: R_X86_64_PLT32   b-0x4
   9:   8b 00   mov(%rax),%eax
   b:   48 83 c4 08 add$0x8,%rsp
   f:   c3  retq   

`obj' only lives in %rdi, and its value is not preserved over the call to b.

If it matters, I've tested this on GCC versions 4.7.2, 6.3.0 and 7.2.0 (the
default versions in various Debian releases), and the latest 8.0.1 from SVN
right now.