On Tue, Jun 23, 2015 at 6:08 PM, Aldy Hernandez <[email protected]> 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
>
>
