[Bug debug/68860] [6/7 regression] FAIL: gcc.dg/guality/pr36728-1.c -flto -O3 -g line 16/7 arg1 == 1

2017-01-12 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68860

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug debug/68860] [6/7 regression] FAIL: gcc.dg/guality/pr36728-1.c -flto -O3 -g line 16/7 arg1 == 1

2016-10-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68860

--- Comment #17 from Richard Biener  ---
I have a fix for that, queued into early LTO debug patches.  But the testcase
still fails...

foo (arg7=arg7@entry=30, arg6=, arg5=, 
arg4=, arg3=, arg2=, 
arg1=, arg8=7)
at
/space/rguenther/src/svn/early-lto-debug/gcc/testsuite/gcc.dg/guality/pr68860-1.c:8
8 foo (int arg1, int arg2, int arg3, int arg4, int arg5, int arg6, int arg7,
int arg8)

vs. w/o LTO:

foo (arg7=arg7@entry=30, arg6=6, arg5=5, arg4=4, arg3=3, arg2=2, arg1=1, 
arg8=7)
at
/space/rguenther/src/svn/early-lto-debug/gcc/testsuite/gcc.dg/guality/pr68860-1.c:8
8 foo (int arg1, int arg2, int arg3, int arg4, int arg5, int arg6, int arg7,
int arg8)

but location info looks good to me:

 <1><1ff>: Abbrev Number: 10 (DW_TAG_subprogram)
<200>   DW_AT_abstract_origin: <0x2b5>
<204>   DW_AT_low_pc  : 0x400570
<20c>   DW_AT_high_pc : 0x47
<214>   DW_AT_frame_base  : 1 byte block: 9c(DW_OP_call_frame_cfa)
<216>   DW_AT_GNU_all_call_sites: 1
 <2><216>: Abbrev Number: 11 (DW_TAG_formal_parameter)
<217>   DW_AT_abstract_origin: <0x306>
<21b>   DW_AT_location: 0x37 (location list)
 <2><21f>: Abbrev Number: 12 (DW_TAG_formal_parameter)
<220>   DW_AT_abstract_origin: <0x2fb>
<224>   DW_AT_location: 6 byte block: fa 5b 0 0 0 9f   
(DW_OP_GNU_parameter_ref: <0x1b6>; DW_OP_stack_value)

though the DW_OP_GNU_parameter_ref points to an extra indirection:

 <1><189>: Abbrev Number: 3 (DW_TAG_subprogram)
<18a>   DW_AT_abstract_origin: <0x2b5>
<18e>   DW_AT_inline  : 1   (inlined)
<18f>   DW_AT_sibling : <0x1c6>
 <2><193>: Abbrev Number: 4 (DW_TAG_formal_parameter)
<194>   DW_AT_abstract_origin: <0x306>
...
 <2><1b6>: Abbrev Number: 4 (DW_TAG_formal_parameter)
<1b7>   DW_AT_abstract_origin: <0x2fb>

which then ultimatively points to the early debug:

 <1><2b5>: Abbrev Number: 5 (DW_TAG_subprogram)
<2b6>   DW_AT_name: foo
<2ba>   DW_AT_decl_file   : 1
<2bb>   DW_AT_decl_line   : 8
<2bc>   DW_AT_prototyped  : 1
<2bc>   DW_AT_type: <0x2ae>
<2c0>   DW_AT_sibling : <0x32f>
...
 <2><2fb>: Abbrev Number: 6 (DW_TAG_formal_parameter)
<2fc>   DW_AT_name: (indirect string, offset: 0x3ac): arg6
<300>   DW_AT_decl_file   : 1
<301>   DW_AT_decl_line   : 8
<302>   DW_AT_type: <0x2ae>

can't seem to make parameter_ref_descriptor to directly use a reference
to the early created DIE.

[Bug debug/68860] [6/7 regression] FAIL: gcc.dg/guality/pr36728-1.c -flto -O3 -g line 16/7 arg1 == 1

2016-10-17 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68860

--- Comment #16 from Jakub Jelinek  ---
Yes, see the #c4 partial patch and the following comments.

[Bug debug/68860] [6/7 regression] FAIL: gcc.dg/guality/pr36728-1.c -flto -O3 -g line 16/7 arg1 == 1

2016-10-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68860

--- Comment #15 from Richard Biener  ---
So with LTO early debug I now get proper debug decls but still no locations for
the parameters

 <1><1ff>: Abbrev Number: 10 (DW_TAG_subprogram)
<200>   DW_AT_abstract_origin: <0x28b>
<204>   DW_AT_low_pc  : 0x400570
<20c>   DW_AT_high_pc : 0x47
<214>   DW_AT_frame_base  : 1 byte block: 9c(DW_OP_call_frame_cfa)
<216>   DW_AT_GNU_all_call_sites: 1
 <2><216>: Abbrev Number: 11 (DW_TAG_formal_parameter)
<217>   DW_AT_abstract_origin: <0x2dc>
<21b>   DW_AT_location: 0x37 (location list)
 <2><21f>: Abbrev Number: 4 (DW_TAG_formal_parameter)
<220>   DW_AT_abstract_origin: <0x2d1>
 <2><224>: Abbrev Number: 4 (DW_TAG_formal_parameter)
<225>   DW_AT_abstract_origin: <0x2c6>
...

vs. non-LTO -O2:

 <1><282>: Abbrev Number: 13 (DW_TAG_subprogram)
<283>   DW_AT_abstract_origin: <0x1fa>
<287>   DW_AT_low_pc  : 0x400570
<28f>   DW_AT_high_pc : 0x47
<297>   DW_AT_frame_base  : 1 byte block: 9c(DW_OP_call_frame_cfa)
<299>   DW_AT_GNU_all_call_sites: 1
 <2><299>: Abbrev Number: 14 (DW_TAG_formal_parameter)
<29a>   DW_AT_abstract_origin: <0x24c>
<29e>   DW_AT_location: 0x37 (location list)
 <2><2a2>: Abbrev Number: 15 (DW_TAG_formal_parameter)
<2a3>   DW_AT_abstract_origin: <0x241>
<2a7>   DW_AT_location: 6 byte block: fa e6 0 0 0 9f   
(DW_OP_GNU_parameter_ref: <0x241>; DW_OP_stack_value)


the .optimized GIMPLE looks the same (and early LTO debug does stream
DECL_ABSTRACT_ORIGIN).  var-tracking only has NOTE_INSN_VAR_LOCATION for arg7
though.  Initial RTL looks the same:

;; # DEBUG arg2 s=> arg2

(debug_insn 8 7 0 (var_location:SI arg2 (const_int 0 [0]) [uninit]) -1
 (nil))
...

Looks like var-tracking misses to add all

(note 63 62 64 2 (var_location arg1 (debug_parameter_ref:SI arg1))
NOTE_INSN_VAR_LOCATION)
(note 64 63 65 2 (var_location arg2 (debug_parameter_ref:SI arg2))
NOTE_INSN_VAR_LOCATION)
(note 65 64 66 2 (var_location arg3 (debug_parameter_ref:SI arg3))
NOTE_INSN_VAR_LOCATION)
(note 66 65 67 2 (var_location arg4 (debug_parameter_ref:SI arg4))
NOTE_INSN_VAR_LOCATION)
(note 67 66 68 2 (var_location arg5 (debug_parameter_ref:SI arg5))
NOTE_INSN_VAR_LOCATION)
(note 68 67 44 2 (var_location arg6 (debug_parameter_ref:SI arg6))
NOTE_INSN_VAR_LOCATION)

ah, because DECL_HAS_DEBUG_ARGS_P and friends has not been LTOed yet.

[Bug debug/68860] [6/7 regression] FAIL: gcc.dg/guality/pr36728-1.c -flto -O3 -g line 16/7 arg1 == 1

2016-04-29 Thread seurer at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68860

--- Comment #14 from Bill Seurer  ---
Dominik Vogt, I've noticed that sort of failure in several of the guality test
cases where a test is done at line X but optimization moves the assignment
being tested to after line X.  Should the tests be adjusted in all those cases?

[Bug debug/68860] [6/7 regression] FAIL: gcc.dg/guality/pr36728-1.c -flto -O3 -g line 16/7 arg1 == 1

2016-04-29 Thread vogt at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68860

--- Comment #13 from Dominik Vogt  ---
By the way, I think the value of y should be tested *after* the asm statement
in line 17 not before it in line 16.  At higher optimization levels the
assignement may not have happened yet when gdb reaches line 16.  (And x should
be tested in line 19 for the same reason).

[Bug debug/68860] [6/7 regression] FAIL: gcc.dg/guality/pr36728-1.c -flto -O3 -g line 16/7 arg1 == 1

2016-04-28 Thread vogt at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68860

--- Comment #12 from Dominik Vogt  ---
We've just been looking at this today for s390x which fails these tests for
various reasons too (actually we've located at least four different Gcc bugs by
looking at this test case).  Some of the calculations in
allocate_dynamic_stack_space are weird, but that isn't the issue at hand (I'm
currently working on that).

We were planning to create a new bug report for this, but if it's already being
discussed ... S390x fails the checks "y == 2" probably because the
cprop_hardreg pass does something wrong with the var_location information. 
We've only debugged this for "x" yet, but it's probably the same cause for "y".
 After reload we have (s390x, -O3 -m64):

-- snip --
(insn 27 26 99 2 (parallel [
(set (reg/f:DI 15 %r15)
(minus:DI (reg/f:DI 15 %r15)
(reg:DI 2 %r2 [73])))
(clobber (reg:CC 33 %cc))
]) pr36728-1.c:12 1409 {*subdi3}
 (expr_list:REG_DEAD (reg:DI 2 %r2 [73])
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(nil
(insn 99 27 57 2 (set (reg/f:DI 1 %r1 [65])
(plus:DI (reg/f:DI 11 %r11)
(const_int 191 [0xbf]))) pr36728-1.c:10 1075 {*la_64}
 (nil))
(insn 57 99 33 2 (set (reg/f:DI 3 %r3 [77])
(reg/f:DI 15 %r15)) pr36728-1.c:12 1073 {*movdi_64}
 (nil))
(debug_insn 33 57 6 2 (var_location:DI x (plus:DI (reg/f:DI 3 %r3 [77])
(const_int 160 [0xa0]))) pr36728-1.c:12 -1
 (nil))
-- snip --

Insn 27 adjusts the stack pointer, insn 57 copies it to r3 and insn 33 says
that "x" is at "r3 + 160".  The following constant propagation pass
(cprop_hardreg) results in

-- snip --
(insn 27 26 99 2 (parallel [
(set (reg/f:DI 15 %r15)
(minus:DI (reg/f:DI 15 %r15)
(reg:DI 2 %r2 [73])))
(clobber (reg:CC 33 %cc))
]) pr36728-1.c:12 1409 {*subdi3}
 (expr_list:REG_DEAD (reg:DI 2 %r2 [73])
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(nil
(insn 99 27 57 2 (set (reg/f:DI 1 %r1 [65])
(plus:DI (reg/f:DI 11 %r11)
(const_int 191 [0xbf]))) pr36728-1.c:10 1075 {*la_64}
 (nil))
(insn 57 99 33 2 (set (reg/f:DI 3 %r3 [77])
(reg/f:DI 15 %r15)) pr36728-1.c:12 1073 {*movdi_64}
 (nil))
(debug_insn 33 57 6 2 (var_location:DI x (plus:DI (reg/f:DI 15 %r15 [77])
(const_int 160 [0xa0]))) pr36728-1.c:12 -1
 (nil))
-- snip --

It has propagated the value of r15 into insn 33, so now the var_location is now
separated from the place when it actually becomes valid (after insn 27), and
further passes result in bogus DWARF location list for "x".

(This is assembly output with a patch I'm working on; y does not use alloca for
aligmnent; I think this is independent of the bug.)
-- snip --
.LVL0:
stmg%r11,%r15,88(%r15)
aghi%r15,-200
lgr %r11,%r15
.loc 1 12 0
aghi%r2,14
.LVL1:
nill%r2,65528
sgr %r15,%r2  <== set final value of stack pointer
.loc 1 15 0   <== location list for "x" should start here
lhi %r2,2
.loc 1 10 0
la  %r1,191(%r11)
.LVL2:<== where location list for "x" actually starts
nill%r1,65504 <== 
.loc 1 16 0   <== location list for "y" should start here
larl%r4,b
.loc 1 17 0
mvi 160(%r15),25
.loc 1 12 0
la  %r3,160(%r15)
.LVL3:
.loc 1 18 0
larl%r5,a
.loc 1 15 0
st  %r2,0(%r1)
.loc 1 16 0
...
-- snip --

Without checking the details for "y" yet we've noticed that there is no
location list for y in the DWARF info, so gdb happily prints random data from
the stack slot with "p y" when stopping at the first ".loc 1 16 0".

[Bug debug/68860] [6/7 regression] FAIL: gcc.dg/guality/pr36728-1.c -flto -O3 -g line 16/7 arg1 == 1

2016-04-28 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68860

--- Comment #11 from Jakub Jelinek  ---
(In reply to Bill Seurer from comment #9)
> The pr36728 and pr68860 test cases that check the arguments (where the
> arguments are unused) all currently (and for a long time) fail on power. 
> They show up as "optimized out" in gdb as in the initial report here.
> 
> Is there some point to testing the value of the unused arguments in these
> test cases?

Of course there is a point, in lots of real-world code many variables are
optimized away, either in whole functions or just part of it, yet users very
often still want to be able to query those values.
DWARF (starting with DWARF 4) has ways to express even that in the debug info,
using DW_OP_stack_value etc., if there is a way to compute their values from
some other registers, memory content, constants etc.
The various DWARF extensions we've added (many of them are going to be in DWARF
5) enhance that even further (e.g. the DW_OP_GNU_entry_value,
DW_OP_GNU_parameter_ref, DW_OP_GNU_implicit_pointer, etc.).

[Bug debug/68860] [6/7 regression] FAIL: gcc.dg/guality/pr36728-1.c -flto -O3 -g line 16/7 arg1 == 1

2016-04-28 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68860

--- Comment #10 from rguenther at suse dot de  ---
On Thu, 28 Apr 2016, seurer at linux dot vnet.ibm.com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68860
> 
> Bill Seurer  changed:
> 
>What|Removed |Added
> 
>  CC||seurer at linux dot 
> vnet.ibm.com
> 
> --- Comment #9 from Bill Seurer  ---
> The pr36728 and pr68860 test cases that check the arguments (where the
> arguments are unused) all currently (and for a long time) fail on power.  They
> show up as "optimized out" in gdb as in the initial report here.
> 
> Is there some point to testing the value of the unused arguments in these test
> cases?

I think it is supposed to check the DW_TAG_GNU_call_site_parameter stuff.

You may want to double-check that is the case on x86_64 and debug why
the dwarf2out code doesn't work on ppc (it does some "interesting"
RTL deciphering which may not work on ppc for one or another reason)

[Bug debug/68860] [6/7 regression] FAIL: gcc.dg/guality/pr36728-1.c -flto -O3 -g line 16/7 arg1 == 1

2016-04-28 Thread seurer at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68860

Bill Seurer  changed:

   What|Removed |Added

 CC||seurer at linux dot 
vnet.ibm.com

--- Comment #9 from Bill Seurer  ---
The pr36728 and pr68860 test cases that check the arguments (where the
arguments are unused) all currently (and for a long time) fail on power.  They
show up as "optimized out" in gdb as in the initial report here.

Is there some point to testing the value of the unused arguments in these test
cases?

FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  line 16 arg1 == 1
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  line 16 arg2 == 2
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  line 16 arg3 == 3
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  line 16 arg4 == 4
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  line 16 arg5 == 5
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  line 16 arg6 == 6
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  line 16 arg7 == 30
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  line 18 arg1 == 1
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  line 18 arg2 == 2
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  line 18 arg3 == 3
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  line 18 arg4 == 4
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  line 18 arg5 == 5
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  line 18 arg6 == 6
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  line 18 arg7 == 30
FAIL: gcc.dg/guality/pr68860-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 14 arg1 == 1
FAIL: gcc.dg/guality/pr68860-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 14 arg2 == 2
FAIL: gcc.dg/guality/pr68860-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 14 arg3 == 3
FAIL: gcc.dg/guality/pr68860-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 14 arg4 == 4
FAIL: gcc.dg/guality/pr68860-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 14 arg5 == 5
FAIL: gcc.dg/guality/pr68860-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 14 arg6 == 6
FAIL: gcc.dg/guality/pr68860-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 16 arg1 == 1
FAIL: gcc.dg/guality/pr68860-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 16 arg2 == 2
FAIL: gcc.dg/guality/pr68860-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 16 arg3 == 3
FAIL: gcc.dg/guality/pr68860-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 16 arg4 == 4
FAIL: gcc.dg/guality/pr68860-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 16 arg5 == 5
FAIL: gcc.dg/guality/pr68860-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 16 arg6 == 6
FAIL: gcc.dg/guality/pr68860-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 14 arg1 == 1
FAIL: gcc.dg/guality/pr68860-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 14 arg2 == 2
FAIL: gcc.dg/guality/pr68860-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 14 arg3 == 3
FAIL: gcc.dg/guality/pr68860-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 14 arg4 == 4
FAIL: gcc.dg/guality/pr68860-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 14 arg5 == 5
FAIL: gcc.dg/guality/pr68860-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 14 arg6 == 6
FAIL: gcc.dg/guality/pr68860-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 16 arg1 == 1
FAIL: gcc.dg/guality/pr68860-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 16 arg2 == 2
FAIL: gcc.dg/guality/pr68860-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 16 arg3 == 3
FAIL: gcc.dg/guality/pr68860-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 16 arg4 == 4
FAIL: gcc.dg/guality/pr68860-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 16 arg5 == 5
FAIL: gcc.dg/guality/pr68860-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 16 arg6 == 6
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 16 arg1 == 1
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 16 arg2 == 2
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 16 arg3 == 3
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 16 arg4 == 4
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 16 arg5 == 5
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 16 arg6 == 6
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 16 arg7 == 30
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 18 arg1 == 1
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 18 arg2 == 2
FAIL: gcc.