On Thu, Jul 10, 2014 at 12:52 PM, Richard Biener <richard.guent...@gmail.com> wrote: > On Thu, Jul 10, 2014 at 11:52 AM, Iain Buclaw <ibuc...@gdcproject.org> wrote: >> On 10 July 2014 10:01, Richard Biener <richard.guent...@gmail.com> wrote: >>> 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. >>> >> >> 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
