This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: LTO ICE in D Frontend

On 10 July 2014 11:54, Richard Biener <> wrote:
> On Thu, Jul 10, 2014 at 12:52 PM, Richard Biener
> <> wrote:
>> On Thu, Jul 10, 2014 at 11:52 AM, Iain Buclaw <> wrote:
>>> On 10 July 2014 10:01, Richard Biener <> wrote:
>>>> On Thu, Jul 10, 2014 at 10:51 AM, Iain Buclaw <> wrote:
>>>>> On 10 July 2014 08:26, Richard Biener <> wrote:
>>>>>> On July 10, 2014 8:31:54 AM CEST, Iain Buclaw <> wrote:
>>>>>>>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
>>>>>>> <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...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]