On 06/07/2015 02:33 PM, Richard Biener wrote:
On June 7, 2015 6:00:05 PM GMT+02:00, Aldy Hernandez <al...@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
<al...@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?

The attached patch fixes the bootstrap failure on ppc64le, and theoretically the aarch64 problem as well, but I haven't checked.

Tested on ppc64le linux by bootstrapping, and regtesting C/C++ against pre debug-early merge sources. Also tested by a full bootstrap and regtest on x86-64 Linux.

OK for mainline?

Aldy
        * varasm.c (output_object_block_htab): Push each object_block into
        a vector instead of calling output_object_block.
        (output_object_block_compare): New.
        (output_object_blocks): Sort object_blocks and then output them.

diff --git a/gcc/varasm.c b/gcc/varasm.c
index 18f3eac..008360e 100644
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -7420,22 +7420,57 @@ output_object_block (struct object_block *block)
     }
 }
 
-/* A htab_traverse callback used to call output_object_block for
-   each member of object_block_htab.  */
+/* An htab_traverse callback used to copy object_blocks into a vector.  */
 
 int
-output_object_block_htab (object_block **slot, void *)
+output_object_block_htab (object_block **slot, void *data)
 {
-  output_object_block (*slot);
+  vec<object_block *, va_heap> *v = (vec<object_block *, va_heap> *) data;
+  v->safe_push (*slot);
   return 1;
 }
 
+/* A callback for qsort to compare object_blocks.  We only care about
+   named sections.  */
+
+static int
+output_object_block_compare (const void *x, const void *y)
+{
+  object_block *p1 = *(object_block * const*)x;
+  object_block *p2 = *(object_block * const*)y;
+
+  if (p1->sect->common.flags & SECTION_NAMED
+      && !(p2->sect->common.flags & SECTION_NAMED))
+    return 1;
+
+  if (!(p1->sect->common.flags & SECTION_NAMED)
+      && p2->sect->common.flags & SECTION_NAMED)
+    return -1;
+
+  if (p1->sect->common.flags & SECTION_NAMED
+      && p2->sect->common.flags & SECTION_NAMED)
+    return strcmp (p1->sect->named.name,
+                  p2->sect->named.name);
+
+  return 0;
+}
+
 /* Output the definitions of all object_blocks.  */
 
 void
 output_object_blocks (void)
 {
-  object_block_htab->traverse<void *, output_object_block_htab> (NULL);
+  vec<object_block *, va_heap> v = vNULL;
+  object_block_htab->traverse<void *, output_object_block_htab> (&v);
+
+  /* Sort them in order to output them in a deterministic manner,
+     otherwise we may get .rodata sections in different orders with
+     and without -g.  */
+  v.qsort (output_object_block_compare);
+  unsigned i;
+  object_block *obj;
+  FOR_EACH_VEC_ELT (v, i, obj)
+    output_object_block (obj);
 }
 
 /* This function provides a possible implementation of the

Reply via email to