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). >
I can say that is a first possible. There's a function ran in D's init hook after all common tree's have been built to override the TYPE_NAME's of common trees. Eg: intQI_type_node from 'signed char' to 'byte'. Commenting it out and giving it a try... Iain
