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 > >