This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: LTO ICE in D Frontend


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

Regards
Iain


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]