From patchwork Mon Jun 8 01:23:40 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Aldy Hernandez X-Patchwork-Id: 481770 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 1D3311401B5 for ; Mon, 8 Jun 2015 11:23:53 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=nd56gpzJ; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; q=dns; s=default; b=Ee+BieboUbuvKT1Hv b+70NIduHk6N9yU81OOe8fx2ikBVkCrILZSLu/KnkaZeh5x4j4HvqRJly7NdQhmJ A5/mApkuVij1A6Qa9fLHOBFGptJ4GCUSK+3kZNYggTPaEGZftfmqnx7e3/vRE6N2 cEDJYIDohj4VYv1HYRrNxSLYhA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; s=default; bh=NucR/eFnXBnje/Zc+zKtJfH zXmw=; b=nd56gpzJsNUWarHF4WHfejt3yyGzteSNKgla1WN1tTHIuMOLxhkPTNk Rxdn8FvDKKJvFrYvlMRW7YLoIYHRy7FRChRSNhso3LTSlX7iMtlW9kgg3/j2oNUj O8MaDoLTwHEh5NtQ7EoDnlBHpSEpSNRLf1UM9R1hMHGOzZaNQT/E= Received: (qmail 37093 invoked by alias); 8 Jun 2015 01:23:46 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 37081 invoked by uid 89); 8 Jun 2015 01:23:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.5 required=5.0 tests=AWL, BAYES_00, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_PASS, T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 08 Jun 2015 01:23:44 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id D42CD19244F; Mon, 8 Jun 2015 01:23:42 +0000 (UTC) Received: from reynosa.quesejoda.com (vpn-57-18.rdu2.redhat.com [10.10.57.18]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t581NfWu006709; Sun, 7 Jun 2015 21:23:41 -0400 Message-ID: <5574EE9C.4070908@redhat.com> Date: Sun, 07 Jun 2015 21:23:40 -0400 From: Aldy Hernandez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Richard Biener , Andreas Schwab CC: gcc-patches Subject: Re: debug-early branch merged into mainline References: <5571F319.205@redhat.com> <55745D42.1000709@redhat.com> <55746A85.8010208@redhat.com> In-Reply-To: On 06/07/2015 02:33 PM, Richard Biener wrote: > On June 7, 2015 6:00:05 PM GMT+02:00, Aldy Hernandez wrote: >> On 06/07/2015 11:25 AM, Richard Biener wrote: >>> On June 7, 2015 5:03:30 PM GMT+02:00, Aldy Hernandez >> 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 (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 *v = (vec *) 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 (NULL); + vec v = vNULL; + object_block_htab->traverse (&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