This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: debug-early branch merged into mainline
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Aldy Hernandez <aldyh at redhat dot com>,Andreas Schwab <schwab at linux-m68k dot org>
- Cc: GCC Mailing List <gcc at gcc dot gnu dot org>
- Date: Sun, 07 Jun 2015 17:25:59 +0200
- Subject: Re: debug-early branch merged into mainline
- Authentication-results: sourceware.org; auth=none
- References: <5571F319 dot 205 at redhat dot com> <m2sia5p3ne dot fsf at linux-m68k dot org> <55745D42 dot 1000709 at redhat dot com>
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?
Richard.
>Aldy