https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91611
Bug ID: 91611
Summary: debug info for register keyword variables at O0
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider this test-case:
...
int
main (void)
{
register float a;
register float b;
a = 1.0;
b = a;
return b == 1.0;
}
...
When compiled with -O0 -g, no DW_AT_location is generated for a and b.
The register keyword is documented in the C standard as: "suggests that access
to the object be as fast as possible".
GCC implements the register keyword at -O0 as documented here (
https://gcc.gnu.org/onlinedocs/gcc/Hints-implementation.html#Hints-implementation
):
...
* When -O0 is in use, the compiler allocates distinct stack memory for all
variables that do not have the register storage-class specifier; if register is
specified, the variable may have a shorter lifespan than the code would
indicate and may never be placed in memory.
...
So, it's made clear that using this hint at -O0 may degrade debug info for the
variable (much like using higher than -O0 may degrade debug info for all
variables).
So I'd say the current -O0 behaviour is valid.
Having said that, what would it take to emit the debug info?
Using -fvar-tracking gets us further:
...
$ gdb -q a.out -ex start
Reading symbols from a.out...done.
Temporary breakpoint 1 at 0x400492: file test.c, line 3.
Starting program: /data/gcc_versions/devel/a.out
Temporary breakpoint 1, main () at test.c:3
3 {
(gdb) n
6 a = 1.0;
(gdb) p a
$1 = <optimized out>
(gdb) n
8 return b == 1.0;
(gdb) p a
$2 = 1
(gdb) p b
$3 = 1
...
[ So, we could enable var-tracking at -O0 in a function if it contains the
register keyword in a local variable. However, currently using var-tracking at
-O0 can also degrade debug info (PR91610), so that would have to be addressed
first. ]
