This is the mail archive of the gcc@gcc.gnu.org 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: debug-early branch merged into mainline


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?

Aldy


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