| Message ID | 55758510.6020106@redhat.com |
|---|---|
| State | New |
| Headers | show |
On Mon, Jun 8, 2015 at 2:05 PM, Aldy Hernandez <aldyh@redhat.com> wrote: > On 06/08/2015 04:26 AM, Richard Biener wrote: >> >> On Mon, Jun 8, 2015 at 3:23 AM, Aldy Hernandez <aldyh@redhat.com> wrote: >>> >>> On 06/07/2015 02:33 PM, Richard Biener wrote: >>>> >>>> >>>> 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? >>> >>> >>> >>> 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? >> >> >> Please use FOR_EACH_HASH_TABLE_ELEMENT to put elements on the >> vector instead of the htab traversal. >> >> The compare function looks like we will end up having many equal elements >> (and thus random ordering on hosts where qsort doesn't behave "sane" >> here, like Solaris IIRC). Unless all sections are named (which it looks >> like) > > > Some sections are not named. > > How about we sort the named sections and output them, but call > output_object_block() on the rest of the sections on whatever order they > were in? This solves the bootstrap problem as well. > > Attached patch tested on x86-64 and ppc64le Linux. > > OK? No, but hash_section suggests to sort after sect->common.flags if the section is not named. Conveniently flags is just an 'int' ... Can you adjust again? Thanks, Richard. > Aldy
On 06/08/2015 09:30 AM, Richard Biener wrote: > On Mon, Jun 8, 2015 at 2:05 PM, Aldy Hernandez <aldyh@redhat.com> wrote: >> On 06/08/2015 04:26 AM, Richard Biener wrote: >>> >>> On Mon, Jun 8, 2015 at 3:23 AM, Aldy Hernandez <aldyh@redhat.com> wrote: >>>> >>>> On 06/07/2015 02:33 PM, Richard Biener wrote: >>>>> >>>>> >>>>> 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? >>>> >>>> >>>> >>>> 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? >>> >>> >>> Please use FOR_EACH_HASH_TABLE_ELEMENT to put elements on the >>> vector instead of the htab traversal. >>> >>> The compare function looks like we will end up having many equal elements >>> (and thus random ordering on hosts where qsort doesn't behave "sane" >>> here, like Solaris IIRC). Unless all sections are named (which it looks >>> like) >> >> >> Some sections are not named. >> >> How about we sort the named sections and output them, but call >> output_object_block() on the rest of the sections on whatever order they >> were in? This solves the bootstrap problem as well. >> >> Attached patch tested on x86-64 and ppc64le Linux. >> >> OK? > > No, but hash_section suggests to sort after sect->common.flags if > the section is not named. Conveniently flags is just an 'int' ... What about if the comparison routine gets a named section and an unnamed section? How to compare? That's why I was giving priority to one over the other originally, but I didn't know about problematic qsort implementations. Aldy
On June 8, 2015 7:14:19 PM GMT+02:00, Aldy Hernandez <aldyh@redhat.com> wrote: >On 06/08/2015 09:30 AM, Richard Biener wrote: >> On Mon, Jun 8, 2015 at 2:05 PM, Aldy Hernandez <aldyh@redhat.com> >wrote: >>> On 06/08/2015 04:26 AM, Richard Biener wrote: >>>> >>>> On Mon, Jun 8, 2015 at 3:23 AM, Aldy Hernandez <aldyh@redhat.com> >wrote: >>>>> >>>>> On 06/07/2015 02:33 PM, Richard Biener wrote: >>>>>> >>>>>> >>>>>> 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? >>>>> >>>>> >>>>> >>>>> 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? >>>> >>>> >>>> Please use FOR_EACH_HASH_TABLE_ELEMENT to put elements on the >>>> vector instead of the htab traversal. >>>> >>>> The compare function looks like we will end up having many equal >elements >>>> (and thus random ordering on hosts where qsort doesn't behave >"sane" >>>> here, like Solaris IIRC). Unless all sections are named (which it >looks >>>> like) >>> >>> >>> Some sections are not named. >>> >>> How about we sort the named sections and output them, but call >>> output_object_block() on the rest of the sections on whatever order >they >>> were in? This solves the bootstrap problem as well. >>> >>> Attached patch tested on x86-64 and ppc64le Linux. >>> >>> OK? >> >> No, but hash_section suggests to sort after sect->common.flags if >> the section is not named. Conveniently flags is just an 'int' ... > >What about if the comparison routine gets a named section and an >unnamed >section? How to compare? That's why I was giving priority to one over > >the other originally, but I didn't know about problematic qsort >implementations. Obviously unnamed and a named section can be sorted like you did in the original patch. Richard. >Aldy
diff --git a/gcc/ChangeLog b/gcc/ChangeLog index e1bd305..f6d4bda 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,10 @@ +2015-06-07 Aldy Hernandez <aldyh@redhat.com> + + * varasm.c (output_object_block_htab): Remove. + (output_object_block_compare): New. + (output_object_blocks): Sort named object_blocks before outputting + them. + 2015-06-06 Jan Hubicka <hubicka@ucw.cz> * alias.c (get_alias_set): Be ready for TYPE_CANONICAL diff --git a/gcc/varasm.c b/gcc/varasm.c index 18f3eac..a765278 100644 --- a/gcc/varasm.c +++ b/gcc/varasm.c @@ -7420,14 +7420,18 @@ output_object_block (struct object_block *block) } } -/* A htab_traverse callback used to call output_object_block for - each member of object_block_htab. */ +/* A callback for qsort to compare object_blocks. */ -int -output_object_block_htab (object_block **slot, void *) +static int +output_object_block_compare (const void *x, const void *y) { - output_object_block (*slot); - return 1; + object_block *p1 = *(object_block * const*)x; + object_block *p2 = *(object_block * const*)y; + + gcc_assert (p1->sect->common.flags & SECTION_NAMED + && p2->sect->common.flags & SECTION_NAMED); + + return strcmp (p1->sect->named.name, p2->sect->named.name); } /* Output the definitions of all object_blocks. */ @@ -7435,7 +7439,25 @@ output_object_block_htab (object_block **slot, void *) void output_object_blocks (void) { - object_block_htab->traverse<void *, output_object_block_htab> (NULL); + vec<object_block *, va_heap> v = vNULL; + object_block *obj; + hash_table<object_block_hasher>::iterator hi; + + FOR_EACH_HASH_TABLE_ELEMENT (*object_block_htab, obj, object_block *, hi) + if (obj->sect->common.flags & SECTION_NAMED) + v.safe_push (obj); + + /* 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; + FOR_EACH_VEC_ELT (v, i, obj) + output_object_block (obj); + + FOR_EACH_HASH_TABLE_ELEMENT (*object_block_htab, obj, object_block *, hi) + if (!(obj->sect->common.flags & SECTION_NAMED)) + output_object_block (obj); } /* This function provides a possible implementation of the