Re: PING: Re: [patch] PR debug/66482: Do not ICE in gen_formal_parameter_die

2015-06-24 Thread Richard Biener 
On Tue, Jun 23, 2015 at 6:08 PM, Aldy Hernandez al...@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

PING: Re: [patch] PR debug/66482: Do not ICE in gen_formal_parameter_die

2015-06-23 Thread Aldy Hernandez 

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