On 10 July 2014 11:54, Richard Biener <richard.guent...@gmail.com> wrote: > 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). >
It seems that I have got it working! Though I must admit it seems by complete accident rather than intent of my doing. There's some old (pre-2007, before I took over) backend initialisation of wint, pid, intmax... all of which are types not used by the D frontend but a necessity to flesh out GCC builtins to the language. I just did some clean-ups (120 odd line deletions) around it and aligned it up with what the LTO frontend does and... it works! Still, no clue how this could affect whether or not the LTO frontend ICE's, but it does. https://github.com/D-Programming-GDC/GDC/commit/28d98308.diff Regards Iain
