[Bug debug/83157] [8 regression] gcc.dg/guality/pr41616-1.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83157 Richard Biener changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #7 from Richard Biener --- First of all the clone should have pointed to the abstract origin of guality_main but it seems we re-use that for the concrete instance failing to see it was "inlined". So the bogus location shoudln't be visible in the guality_main.constprop () context. After we fixed that we can continue investigating (if it still fails). So: ;; guality_main.constprop() <1><9f0>: Abbrev Number: 42 (DW_TAG_subprogram) <9f1> DW_AT_abstract_origin: <0x474> and ;; guality_main() <1><994>: Abbrev Number: 42 (DW_TAG_subprogram) <995> DW_AT_abstract_origin: <0x474> refer to the same abstract instance of guality_main. But <2>: Abbrev Number: 46 (DW_TAG_variable) DW_AT_abstract_origin: <0x9c1> doesn't refer to the abstract origin copy of the variable but the concrete instace one. As said, with current trunk I don't even see a DIE for guality_main.constprop because it is inlined (but the guality test still fails). Your reduced testcase reproduces the issue for me. Ah... I guess this all might happen because the actual DECL refers to both the abstract instance and the concrete instance and add_abstract_origin_attribute simply never expects the concrete instance to exist already... But creating the DIE for the clone happens late enough here (when it is finally output): Breakpoint 6, equate_decl_number_to_die ( decl=, decl_die=>) at /space/rguenther/src/svn/trunk2/gcc/dwarf2out.c:5763 5763 unsigned int decl_id = DECL_UID (decl); ... Breakpoint 6, equate_decl_number_to_die ( decl=, decl_die=>) at /space/rguenther/src/svn/trunk2/gcc/dwarf2out.c:5763 5763 unsigned int decl_id = DECL_UID (decl); ... Breakpoint 5, add_abstract_origin_attribute ( die=>, origin=) at /space/rguenther/src/svn/trunk2/gcc/dwarf2out.c:20445 20445 dw_die_ref origin_die = NULL; boring (gdb) p debug_generic_expr (cfun->decl) guality_main.constprop (gdb) p origin_die $24 = > This means we're lacking an "early" DIE creation stage for the function clone. IPA materialization happens early enough for this. Forgoing the 1:1 mapping of decl to DIE would be another possibility to fix this (making the global map always point to the abstract copy and adding a local map for querying during dwarf2out_function_decl). Jason?
[Bug debug/83157] [8 regression] gcc.dg/guality/pr41616-1.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83157 Mark Wielaard changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #6 from Mark Wielaard --- (In reply to Aldy Hernandez from comment #4) > I am attaching a simplified preprocessed file that exhibits the problem. > Perhaps someone with more debug-fu can comment here. > > [tl;dr: Shouldn't local variables in a cloned variable have their own > location lists?]. In this case it seems the answer is yes. The location code range(s) of the abstract origin don't make sense in the cloned code since it doesn't cover the new cloned code range. Also, since it seems we know the cloned variable is always 1 maybe it could just simply have a DW_AT_const_value 1 instead of a DW_AT_location?
[Bug debug/83157] [8 regression] gcc.dg/guality/pr41616-1.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83157 --- Comment #5 from Aldy Hernandez --- Created attachment 42950 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42950=edit hacked up preprocessed file showing problem with only -O3 -g
[Bug debug/83157] [8 regression] gcc.dg/guality/pr41616-1.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83157
Aldy Hernandez changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
--- Comment #4 from Aldy Hernandez ---
I am attaching a simplified preprocessed file that exhibits the problem.
Perhaps someone with more debug-fu can comment here.
[tl;dr: Shouldn't local variables in a cloned variable have their own location
lists?].
The following is being cloned into guality_main.constprop(), which in turn is
called from main():
int
guality_main(int argc, char *argv[])
{
int boring = -1;
boring = -f();
guality_check ("boring", boring, 0);
return boring;
}
[FWIW, guality_main and guality_main.constprop have exactly the same IL, albeit
with different #DEBUG statements. I don't know why we even clone it.]
$ ./a.out
FAIL: guality/guality.h: boring is -1, not 1
FAIL: guality/guality.h: 0 PASS, 1 FAIL, 0 UNRESOLVED
Since guality_main.constprop() is the function being called, let's look for
"boring" in it:
;; guality_main.constprop()
<1><9f0>: Abbrev Number: 42 (DW_TAG_subprogram)
<9f1> DW_AT_abstract_origin: <0x474>
<9f5> DW_AT_low_pc : 0x400e22
<9fd> DW_AT_high_pc : 0x1f
DW_AT_frame_base : 1 byte block: 9c(DW_OP_call_frame_cfa)
DW_AT_GNU_all_call_sites: 1
DW_AT_sibling : <0xa4a>
<2>: Abbrev Number: 46 (DW_TAG_variable)
DW_AT_abstract_origin: <0x9c1>
According to this, "boring" comes from 0x9c1 which is defined in
guality_main(), the original function:
;; guality_main()
<1><994>: Abbrev Number: 42 (DW_TAG_subprogram)
<995> DW_AT_abstract_origin: <0x474>
<999> DW_AT_low_pc : 0x400e03
<9a1> DW_AT_high_pc : 0x1f
<9a9> DW_AT_frame_base : 1 byte block: 9c(DW_OP_call_frame_cfa)
<9ab> DW_AT_GNU_all_call_sites: 1
<9ab> DW_AT_sibling : <0x9f0>
...
<2><9c1>: Abbrev Number: 45 (DW_TAG_variable)
<9c2> DW_AT_abstract_origin: <0x49d> <-- points to DW_TAG_var for
"boring"
<9c6> DW_AT_location: 0x542 (location list)
The location list for this 0x542 has a literal of 1 as expected:
0542 00400e03 00400e18 (DW_OP_lit1; DW_OP_stack_value)
However, my question is, shouldn't "boring" in guality_main.constprop (0xa0b)
have a DW_AT_location of itself? Because even if if the location of boring in
guality_main.constprop (0xa0b) comes through the abstract origin that
ultimately leeds to...
0542 00400e03 00400e18 (DW_OP_lit1; DW_OP_stack_value)
This is the wrong address. 0x400e03 through 0x400e18 is in guality_main(), not
in guality_main.constprop() which is the function being called:
00400e03 :
400e03: 48 83 ec 08 sub$0x8,%rsp
400e07: 31 d2 xor%edx,%edx
400e09: be 01 00 00 00 mov$0x1,%esi
400e0e: bf 08 12 40 00 mov$0x401208,%edi
400e13: e8 b3 fd ff ff callq 400bcb
400e18: b8 01 00 00 00 mov$0x1,%eax
400e1d: 48 83 c4 08 add$0x8,%rsp
400e21: c3 retq
Hints, tips, and/or solutions, would be greatly appreciated :).
[Bug debug/83157] [8 regression] gcc.dg/guality/pr41616-1.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83157 --- Comment #3 from Aldy Hernandez --- Looks like it actually started with r247597, which AFAICT is also a change in how we determine cloning/inlining, so perhaps a latent bug?
[Bug debug/83157] [8 regression] gcc.dg/guality/pr41616-1.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83157 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-12-19 CC||aldyh at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Aldy Hernandez --- Confirmed.
[Bug debug/83157] [8 regression] gcc.dg/guality/pr41616-1.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83157 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0 --- Comment #1 from Richard Biener --- Just different inlining, thus a latent bug.
