On Thu, Jul 10, 2014 at 10:51 AM, Iain Buclaw <ibuc...@gdcproject.org> wrote: > On 10 July 2014 08:26, Richard Biener <richard.guent...@gmail.com> wrote: >> On July 10, 2014 8:31:54 AM CEST, Iain Buclaw <ibuc...@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. Richard. > Regards > Iain.
