| Message ID | 557B11C5.90303@redhat.com |
|---|---|
| State | New |
| Headers | show |
On 06/12/2015 10:07 AM, Aldy Hernandez wrote: Hi. This is now a P2, as it is causing a secondary target bootstrap to fail (s390). Aldy > Sigh. I must say my head is spinning with this testcase and what we do > with it (-O3), even prior to the debug-early work: > > void f(int p) {} > int g() { > void f(int p); > g(); > return 0; > } > > The inliner recursively inlines this function up to a certain depth, but > the useless inlining gets cleaned up shortly afterwards. However, the > BLOCK_SOURCE_LOCATION are still set throughout which is technically > correct. > > Eventually late dwarf gets a hold of all this and we end up calling > dwarf2out_abstract_function to build debug info for the abstract > instance of a function for which we have already generated a DIE for. > Basically, a similar issue to what we encountered for template parameter > packs. Or at least, that's my understanding, because as I've said, I > admit to being slightly confused here. > > Since technically this is all going away when we remove > dwarf2out_abstract_function, I suggest we remove the assert and avoid > sudden death. It's not like the we generated useful debugging for this > testcase anyhow. > > Aldy
On Tue, Jun 23, 2015 at 6:08 PM, Aldy Hernandez <aldyh@redhat.com> wrote: > On 06/12/2015 10:07 AM, Aldy Hernandez wrote: > > Hi. > > This is now a P2, as it is causing a secondary target bootstrap to fail > (s390). Ok. Thanks, Richard. > Aldy > >> Sigh. I must say my head is spinning with this testcase and what we do >> with it (-O3), even prior to the debug-early work: >> >> void f(int p) {} >> int g() { >> void f(int p); >> g(); >> return 0; >> } >> >> The inliner recursively inlines this function up to a certain depth, but >> the useless inlining gets cleaned up shortly afterwards. However, the >> BLOCK_SOURCE_LOCATION are still set throughout which is technically >> correct. >> >> Eventually late dwarf gets a hold of all this and we end up calling >> dwarf2out_abstract_function to build debug info for the abstract >> instance of a function for which we have already generated a DIE for. >> Basically, a similar issue to what we encountered for template parameter >> packs. Or at least, that's my understanding, because as I've said, I >> admit to being slightly confused here. >> >> Since technically this is all going away when we remove >> dwarf2out_abstract_function, I suggest we remove the assert and avoid >> sudden death. It's not like the we generated useful debugging for this >> testcase anyhow. >> >> Aldy > >
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c index d2c516a..57a8e52 100644 --- a/gcc/dwarf2out.c +++ b/gcc/dwarf2out.c @@ -18023,18 +18023,14 @@ gen_formal_parameter_die (tree node, tree origin, bool emit_name_p, { /* FIXME: Reuse DIE even with a differing context. - This happens when called through - dwarf2out_abstract_function for formal parameter - packs. The issue is that we're calling + This can happen when calling dwarf2out_abstract_function to build debug info for the abstract instance of a function for which we have already generated a DIE in dwarf2out_early_global_decl. - Once we remove dwarf2out_abstract_function, this - gcc_assert should be a gcc_unreachable. */ - gcc_assert (parm_die->die_parent->die_tag - == DW_TAG_GNU_formal_parameter_pack); + Once we remove dwarf2out_abstract_function, we should + have a call to gcc_unreachable here. */ } } diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/pr66482.c b/gcc/testsuite/gcc.dg/debug/dwarf2/pr66482.c new file mode 100644 index 0000000..880791c --- /dev/null +++ b/gcc/testsuite/gcc.dg/debug/dwarf2/pr66482.c @@ -0,0 +1,9 @@ +/* { dg-do compile } */ +/* { dg-options "-O3 -gdwarf" } */ + +void f(int p) {} +int g() { + void f(); + g(); + return 0; +}
Sigh. I must say my head is spinning with this testcase and what we do with it (-O3), even prior to the debug-early work: void f(int p) {} int g() { void f(int p); g(); return 0; } The inliner recursively inlines this function up to a certain depth, but the useless inlining gets cleaned up shortly afterwards. However, the BLOCK_SOURCE_LOCATION are still set throughout which is technically correct. Eventually late dwarf gets a hold of all this and we end up calling dwarf2out_abstract_function to build debug info for the abstract instance of a function for which we have already generated a DIE for. Basically, a similar issue to what we encountered for template parameter packs. Or at least, that's my understanding, because as I've said, I admit to being slightly confused here. Since technically this is all going away when we remove dwarf2out_abstract_function, I suggest we remove the assert and avoid sudden death. It's not like the we generated useful debugging for this testcase anyhow. Aldy commit 80f8e8aefc3c628ad22cd2b17b28beb8bf4f3523 Author: Aldy Hernandez <aldyh@redhat.com> Date: Fri Jun 12 09:53:44 2015 -0700 * dwarf2out.c (gen_formal_parameter_die): Remove assert.