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) Richard. > Regards > Iain
