From: Aldy Hernandez <aldyh@redhat.com>
To: Richard Biener <richard.guenther@gmail.com>,
Andreas Schwab <schwab@linux-m68k.org>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: debug-early branch merged into mainline
Date: Mon, 08 Jun 2015 04:18:00 -0000 [thread overview]
Message-ID: <5574EE9C.4070908@redhat.com> (raw)
In-Reply-To: <B1EA82B7-CC5D-430B-88ED-00649931ADF8@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2932 bytes --]
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?
Aldy
[-- Attachment #2: curr --]
[-- Type: text/plain, Size: 2221 bytes --]
* 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
next prev parent reply other threads:[~2015-06-08 1:23 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 ` Aldy Hernandez [this message]
2015-06-08 8:45 ` debug-early branch merged into mainline 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
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=5574EE9C.4070908@redhat.com \
--to=aldyh@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=richard.guenther@gmail.com \
--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).