PR debug/66482: Do not ICE in gen_formal_parameter_die
diff mbox

Message ID 557B11C5.90303@redhat.com
State New
Headers show

Commit Message

Aldy Hernandez June 12, 2015, 5:07 p.m. UTC
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.

Comments

Aldy Hernandez June 23, 2015, 4:08 p.m. UTC | #1
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
Richard Biener June 24, 2015, 8:42 a.m. UTC | #2
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
>
>

Patch
diff mbox

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;
+}