From: Richard Biener <richard.guenther@gmail.com>
To: Aldy Hernandez <aldyh@redhat.com>
Cc: Andreas Schwab <schwab@linux-m68k.org>,gcc-patches
<gcc-patches@gcc.gnu.org>
Subject: Re: debug-early branch merged into mainline
Date: Mon, 08 Jun 2015 19:24:00 -0000 [thread overview]
Message-ID: <8718EC9E-01D8-4817-983B-147E32BCEBE5@gmail.com> (raw)
In-Reply-To: <5575CD6B.6000205@redhat.com>
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
next prev parent reply other threads:[~2015-06-08 18:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5571F319.205@redhat.com>
[not found] ` <m2k2vf253a.fsf@linux-m68k.org>
2015-06-07 13:08 ` [patch] fix _OBJC_Module defined but not used warning Aldy Hernandez
2015-06-07 14:37 ` Andreas Schwab
2015-06-08 8:05 ` Iain Sandoe
2015-06-08 10:27 ` Aldy Hernandez
[not found] ` <m2sia5p3ne.fsf@linux-m68k.org>
[not found] ` <55745D42.1000709@redhat.com>
[not found] ` <EC191B3F-2503-4979-8C6E-FD8868C3AD84@gmail.com>
[not found] ` <55746A85.8010208@redhat.com>
[not found] ` <B1EA82B7-CC5D-430B-88ED-00649931ADF8@gmail.com>
2015-06-08 4:18 ` debug-early branch merged into mainline Aldy Hernandez
2015-06-08 8:45 ` Richard Biener
2015-06-08 12:05 ` Aldy Hernandez
2015-06-08 13:32 ` Richard Biener
2015-06-08 17:29 ` Aldy Hernandez
2015-06-08 19:24 ` Richard Biener [this message]
2015-06-08 20:33 ` Aldy Hernandez
2015-06-09 8:08 ` Richard Biener
2015-06-09 9:47 ` Aldy Hernandez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8718EC9E-01D8-4817-983B-147E32BCEBE5@gmail.com \
--to=richard.guenther@gmail.com \
--cc=aldyh@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=schwab@linux-m68k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).