User account creation filtered due to spam.

Bug 55056 - [4.8/4.9 Regression] -O0 -g missing location for register double var
Summary: [4.8/4.9 Regression] -O0 -g missing location for register double var
Status: RESOLVED WONTFIX
Alias: None
Product: gcc
Classification: Unclassified
Component: debug (show other bugs)
Version: 4.8.0
: P3 normal
Target Milestone: 4.8.3
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-24 14:22 UTC by Jan Kratochvil
Modified: 2013-10-25 11:46 UTC (History)
2 users (show)

See Also:
Host:
Target: x86_64-unknown-linux-gnu
Build:
Known to work:
Known to fail:
Last reconfirmed: 2012-10-24 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Kratochvil 2012-10-24 14:22:15 UTC
Regressions in gdb.base/store.exp by 2012-10-23 -> 2012-10-24.

double f(double u) {
  register double l = u;
  return l + l;
}

PASS: gcc (GCC) 4.7.3 20121024 (prerelease)
 <2><5d>: Abbrev Number: 4 (DW_TAG_variable)
    <5e>   DW_AT_name        : l
    <62>   DW_AT_type        : <0x6a>
    <66>   DW_AT_location    : 2 byte block: 76 70      (DW_OP_breg6 (rbp): -16)

FAIL: gcc (GCC) 4.8.0 20121024 (experimental)
 <2><58>: Abbrev Number: 4 (DW_TAG_variable)
    <59>   DW_AT_name        : l
    <5d>   DW_AT_type        : <0x62>
Comment 1 Richard Biener 2012-10-24 14:28:42 UTC
I bet it works for -Og (can you check the gdb testsuite for regressions vs. -O0
-g for -Og -g?)

Anyway, confirmed.
Comment 2 Jan Kratochvil 2012-10-24 15:23:19 UTC
-Og -g0 is a total failure of everything, such as:

-Breakpoint 2, func2 () at ./gdb.base/return.c:12
-12       return -5;
-(gdb) PASS: gdb.base/return.exp: continue to return of -5
+Breakpoint 2, func2 () at ./gdb.base/return.c:13
+13     }
+(gdb) FAIL: gdb.base/return.exp: continue to return of -5
Comment 3 Jakub Jelinek 2012-10-25 06:35:28 UTC
-Og -g0 doesn't produce debug info, so it should fail all debugger tests.
-Og -g should work.
The problem with register vars at -O0 is that they aren't assigned a stack slot, so for good debug info they'd need VTA, but we don't do that at -O0 (both because it is expensive and because var-tracking isn't tought to handle -O0 well - for -O0 I guess we don't want to add debug stmts (or ignore them) for non-register non-param vars (perhaps also with exception of VLA bound temporaries), and once something is stored into its memory location, it should be considered to live there and not for say
l = l + 1;
where l lives in memory say for an instruction or two that l lives in some register or register + 1 and then again in memory.
Comment 4 Jakub Jelinek 2012-10-25 07:14:16 UTC
Anyway, this "regression" is due to LRA which even for -O0 generates better code, CCing Vlad to see why old reload pushed the l var into its own stack slot, even when it is register and thus it doesn't have to do that.
Comment 5 Jan Kratochvil 2012-10-25 08:23:20 UTC
(In reply to comment #3)
> -Og -g0 doesn't produce debug info, so it should fail all debugger tests.
> -Og -g should work.

-Og -g0 is needed for GDB testsuite which expects unchanged CFLAGS produce no
DWARF while adding -g to them produces the proper (-Og in this case) dwarf.
From GCC standpoint it was -Og -g0 -g.

-Og is not usable with GDB testsuite without heavy work on the testsuite.
If this PR is WONTFIXed I can adjust the few GDB testcases to cope with the
missing location with -O0 -g.


(In reply to comment #4)
> Anyway, this "regression" is due to LRA which even for -O0 generates better
> code, CCing Vlad to see why old reload pushed the l var into its own stack
> slot, even when it is register and thus it doesn't have to do that.

For types up to double "register" keyword stores it to int registers like %rbx.
long double is really stored in stack memory in the code so this GDB testcase intended for register-stored values has nothing to test and it can be skipped (for long double).

I do not understand why "register" does not keep the value on FPU stack.
Comment 6 Richard Biener 2012-12-07 12:06:40 UTC
(In reply to comment #5)
> (In reply to comment #3)
> > -Og -g0 doesn't produce debug info, so it should fail all debugger tests.
> > -Og -g should work.
> 
> -Og -g0 is needed for GDB testsuite which expects unchanged CFLAGS produce no
> DWARF while adding -g to them produces the proper (-Og in this case) dwarf.
> From GCC standpoint it was -Og -g0 -g.

Even though it might be confusing, plain -Og does not generate debug info
(thus it's equivalent to -Og -g0) ;)

I suppose the reason this no longer works is (again) that we don't run
var-tracking at -O0.  Thus indeed WONTFIX may be reasonable.  Leaving at P3
for now.
Comment 7 Jan Kratochvil 2013-01-26 20:28:45 UTC
Workarounded with XFAIL for the GDB testsuite:
http://sourceware.org/ml/gdb-patches/2013-01/msg00655.html
Comment 8 Richard Biener 2013-02-26 15:12:54 UTC
Looking at the audit trail I'd conclude that this is not a bug but a feature.
Or an enhancement request (enable var-tracking at -O0).  But well, marking
as WAITING for now.
Comment 9 Jakub Jelinek 2013-03-22 14:45:02 UTC
GCC 4.8.0 is being released, adjusting target milestone.
Comment 10 Jakub Jelinek 2013-05-31 10:58:46 UTC
GCC 4.8.1 has been released.
Comment 11 Jakub Jelinek 2013-10-16 09:49:27 UTC
GCC 4.8.2 has been released.
Comment 12 Richard Biener 2013-10-25 11:46:31 UTC
-Og has 'l' as well

 <2><4f>: Abbrev Number: 4 (DW_TAG_formal_parameter)
    <50>   DW_AT_name        : u        
    <52>   DW_AT_decl_file   : 1        
    <53>   DW_AT_decl_line   : 1        
    <54>   DW_AT_type        : <0x2d>   
    <58>   DW_AT_location    : 0x0      (location list)
 <2><5c>: Abbrev Number: 5 (DW_TAG_variable)
    <5d>   DW_AT_name        : l        
    <5f>   DW_AT_decl_file   : 1        
    <60>   DW_AT_decl_line   : 2        
    <61>   DW_AT_type        : <0x2d>   
    <65>   DW_AT_location    : 0x0      (location list)