This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: LTO ICE in D Frontend
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Iain Buclaw <ibuclaw at gdcproject dot org>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Thu, 10 Jul 2014 12:54:50 +0200
- Subject: Re: LTO ICE in D Frontend
- Authentication-results: sourceware.org; auth=none
- References: <CABOHX+exHdkqEcVn=W98T9CA-j1AR+smDj+Uj-ryGidTqo0tVg at mail dot gmail dot com> <07ba1b9f-eb72-461e-b466-309e15519082 at email dot android dot com> <CABOHX+d4gEDY77zGUoB=Y7KUBFPhbbKsyCeBLVYoEp0W6ux94Q at mail dot gmail dot com> <CAFiYyc1YuJf9H1r__EGtAjy1EDdraSxUSb4g95P1uCyxoBS4NA at mail dot gmail dot com> <CABOHX+ds27HM1JeFw7r5OsuPhVYUw38rON-Rm=3sxkjfeBXCgw at mail dot gmail dot com> <CAFiYyc1UnLVN9bMOeFxJ+PY2fYrqwBZKyQbt1w+sKv6ta_4hfg at mail dot gmail dot com>
On Thu, Jul 10, 2014 at 12:52 PM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Thu, Jul 10, 2014 at 11:52 AM, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
>> On 10 July 2014 10:01, Richard Biener <richard.guenther@gmail.com> wrote:
>>> On Thu, Jul 10, 2014 at 10:51 AM, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
>>>> On 10 July 2014 08:26, Richard Biener <richard.guenther@gmail.com> wrote:
>>>>> On July 10, 2014 8:31:54 AM CEST, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
>>>>>>Hi,
>>>>>>
>>>>>>I'm trying to get to the bottom of a bug when using the D front-end
>>>>>>with -flto.
>>>>>>
>>>>>>When compiling anything, it always ICEs at in
>>>>>>streamer_get_pickled_tree, at tree-streamer-in.c.
>>>>>>
>>>>>>The of it appears to be that the LTO frontend seems to never retrieve
>>>>>>what it is expected to find. But I don't know what could be missing
>>>>>>from the code generation on my side to sort that out.
>>>>>>
>>>>>>
>>>>>>The following minimal test that yields an ICE.
>>>>>>---
>>>>>>extern(C) int test = void;
>>>>>>
>>>>>>
>>>>>>I had set a breakpoint at hash_tree and looked at debug_tree output
>>>>>>from an equivalent program in C++, but nothing stands out as wrong
>>>>>>here to me.
>>>>>>
>>>>>>Any insight would be helpful.
>>>>>>
>>>>>>
>>>>>>// D
>>>>>>DECL_NAME:
>>>>>> <identifier_node 0x7ffff66981b8 test>
>>>>>>
>>>>>>DECL_CONTEXT: (null_tree)
>>>>>
>>>>> This should have a translation unit decl here.
>>>>>
>>>>> Richard.
>>>>
>>>>
>>>> I've been avoiding doing that for the last few years. Doesn't
>>>> progress any further the problem though. It looks like the LTO
>>>> front-end ICE's before it even attempts to read the decl context.
>>>>
>>>> Getting an ERROR_MARK when expecting an IDENTIFIER_NODE.
>>>>
>>>> Something not right with the DECL_NAME?
>>>
>>> It rather sounds like sth out-of-sync somewhere. Typical fronend
>>> issues are lang-specific tree codes leaking into LTO but that usually
>>> has a different kind of fallout.
>>>
>>> How is the D frontend integrated? Is it done "regularly", that is,
>>> in-tree? It's important that the all-tree.def generated at build time
>>> is consistent when building the D and the lto frontend.
>>>
>>
>> Yep, all-tree.def should be consistent between the two. d/d-tree.def
>> is included in the generated all-tree.def file. In my example though,
>> only core tree codes are used, and I would have thought that they
>> should be unaffected by the language tree codes (that have higher code
>> numbers).
>
> Yeah. I have no clue what goes wrong then, you have to debug it :/
> (the testcase is small, so see where it writes the corresponding
> pieces in tree-streamer-out.c and try to match-up with the LTO read
> side in two parallel gdb sessions)
Oh, another common source of issues is that the trees the streamer
cache is seeded with in preload_common_nodes is inconsistent
between D and LTO. In fact I bet it is that (you can simply add
some printfs and try to match entries).
Richard.
> Richard.
>
>> Regards
>> Iain