Re: debug-early branch merged into mainline

[Richard Biener <richard dot guenther at gmail dot com>]

On June 7, 2015 6:00:05 PM GMT+02:00, Aldy Hernandez <aldyh@redhat.com> wrote:
>On 06/07/2015 11:25 AM, Richard Biener wrote:
>> On June 7, 2015 5:03:30 PM GMT+02:00, Aldy Hernandez
><aldyh@redhat.com> wrote:
>>> On 06/06/2015 05:49 AM, Andreas Schwab wrote:
>>>> Bootstrap fails on aarch64:
>>>>
>>>> Comparing stages 2 and 3
>>>> warning: gcc/cc1objplus-checksum.o differs
>>>> warning: gcc/cc1obj-checksum.o differs
>>>> warning: gcc/cc1plus-checksum.o differs
>>>> warning: gcc/cc1-checksum.o differs
>>>> Bootstrap comparison failure!
>>>> gcc/ira-costs.o differs
>>>> gcc/tree-sra.o differs
>>>> gcc/tree-parloops.o differs
>>>> gcc/tree-vect-data-refs.o differs
>>>> gcc/java/jcf-io.o differs
>>>> gcc/ipa-inline-analysis.o differs
>>>
>>> The bootstrap comparison failure on ppc64le, aarch64, and possibly
>>> others is due to the order of some sections being in a different
>order
>>> with and without debugging.
>>>
>>> Stage2 is being compiled with no debugging due to -gtoggle, and
>stage3
>>> is being compiled with debugging.
>>>
>>> For ira-costs.o on ppc64le we have:
>>>
>>> -Disassembly of section
>>>
>.rodata._ZN10hash_tableI19cost_classes_hasher11xcallocatorE6expandEv.str1.8:
>>> +Disassembly of section
>>>
>.rodata._ZN10hash_tableI19cost_classes_hasher11xcallocatorE26find_empty_slot_for_expandEj.str1.8:
>>>
>>> ...
>>>
>>> -Disassembly of section
>>>
>.rodata._ZN10hash_tableI19cost_classes_hasher11xcallocatorE26find_empty_slot_for_expandEj.str1.8:
>>> +Disassembly of section
>>>
>.rodata._ZN10hash_tableI19cost_classes_hasher11xcallocatorE6expandEv.str1.8:
>>>
>>> There is no semantic difference between the objects, just the
>ordering.
>>>
>>> I assume it's the same problem for the rest of the objects and
>>> architectures.
>>>
>>> I will look into this, unless someone beats me to it, or has an idea
>>> right off the bat.
>>
>> Check whether the symbol table walkers are walking hash tables.  I
>assume the above are emitted via the symbol removal handling for debug
>stuff?
>
>Ughh, indeed.  These sections are being outputted from 
>output_object_blocks which traverses a hash table:
>
>void
>output_object_blocks (void)
>{
>  object_block_htab->traverse<void *, output_object_block_htab> (NULL);
>}
>
>Perhaps we should sort them by some deterministic field and then call 
>output_object_block() on each member of the resulting list?

Yes, that would be the usual fix. Maybe sth has an UID already, is the 'object' a decl by chance?

Richard.

>Aldy