From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6803 invoked by alias); 8 Jun 2015 12:05:41 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 6791 invoked by uid 89); 8 Jun 2015 12:05:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.5 required=5.0 tests=AWL,BAYES_40,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 12:05:39 +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 189DE3582C1; Mon, 8 Jun 2015 12:05:38 +0000 (UTC) Received: from reynosa.quesejoda.com (vpn-60-44.rdu2.redhat.com [10.10.60.44]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t58C5aUn007209; Mon, 8 Jun 2015 08:05:37 -0400 Message-ID: <55758510.6020106@redhat.com> Date: Mon, 08 Jun 2015 12:05:00 -0000 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 CC: Andreas Schwab , gcc-patches Subject: Re: debug-early branch merged into mainline References: <5571F319.205@redhat.com> <55745D42.1000709@redhat.com> <55746A85.8010208@redhat.com> <5574EE9C.4070908@redhat.com> In-Reply-To: Content-Type: multipart/mixed; boundary="------------000806000507080709050406" X-SW-Source: 2015-06/txt/msg00555.txt.bz2 This is a multi-part message in MIME format. --------------000806000507080709050406 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-length: 3991 On 06/08/2015 04:26 AM, Richard Biener wrote: > On Mon, Jun 8, 2015 at 3:23 AM, Aldy Hernandez wrote: >> 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? > > 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? Aldy --------------000806000507080709050406 Content-Type: text/plain; charset=UTF-8; name="curr" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="curr" Content-length: 3107 ZGlmZiAtLWdpdCBhL2djYy9DaGFuZ2VMb2cgYi9nY2MvQ2hhbmdlTG9nCmlu ZGV4IGUxYmQzMDUuLmY2ZDRiZGEgMTAwNjQ0Ci0tLSBhL2djYy9DaGFuZ2VM b2cKKysrIGIvZ2NjL0NoYW5nZUxvZwpAQCAtMSwzICsxLDEwIEBACisyMDE1 LTA2LTA3ICBBbGR5IEhlcm5hbmRleiAgPGFsZHloQHJlZGhhdC5jb20+CisK KwkqIHZhcmFzbS5jIChvdXRwdXRfb2JqZWN0X2Jsb2NrX2h0YWIpOiBSZW1v dmUuCisJKG91dHB1dF9vYmplY3RfYmxvY2tfY29tcGFyZSk6IE5ldy4KKwko b3V0cHV0X29iamVjdF9ibG9ja3MpOiBTb3J0IG5hbWVkIG9iamVjdF9ibG9j a3MgYmVmb3JlIG91dHB1dHRpbmcKKwl0aGVtLgorCiAyMDE1LTA2LTA2ICBK YW4gSHViaWNrYSAgPGh1Ymlja2FAdWN3LmN6PgogCiAJKiBhbGlhcy5jIChn ZXRfYWxpYXNfc2V0KTogQmUgcmVhZHkgZm9yIFRZUEVfQ0FOT05JQ0FMCmRp ZmYgLS1naXQgYS9nY2MvdmFyYXNtLmMgYi9nY2MvdmFyYXNtLmMKaW5kZXgg MThmM2VhYy4uYTc2NTI3OCAxMDA2NDQKLS0tIGEvZ2NjL3ZhcmFzbS5jCisr KyBiL2djYy92YXJhc20uYwpAQCAtNzQyMCwxNCArNzQyMCwxOCBAQCBvdXRw dXRfb2JqZWN0X2Jsb2NrIChzdHJ1Y3Qgb2JqZWN0X2Jsb2NrICpibG9jaykK ICAgICB9CiB9CiAKLS8qIEEgaHRhYl90cmF2ZXJzZSBjYWxsYmFjayB1c2Vk IHRvIGNhbGwgb3V0cHV0X29iamVjdF9ibG9jayBmb3IKLSAgIGVhY2ggbWVt YmVyIG9mIG9iamVjdF9ibG9ja19odGFiLiAgKi8KKy8qIEEgY2FsbGJhY2sg Zm9yIHFzb3J0IHRvIGNvbXBhcmUgb2JqZWN0X2Jsb2Nrcy4gICovCiAKLWlu dAotb3V0cHV0X29iamVjdF9ibG9ja19odGFiIChvYmplY3RfYmxvY2sgKipz bG90LCB2b2lkICopCitzdGF0aWMgaW50CitvdXRwdXRfb2JqZWN0X2Jsb2Nr X2NvbXBhcmUgKGNvbnN0IHZvaWQgKngsIGNvbnN0IHZvaWQgKnkpCiB7Ci0g IG91dHB1dF9vYmplY3RfYmxvY2sgKCpzbG90KTsKLSAgcmV0dXJuIDE7Cisg IG9iamVjdF9ibG9jayAqcDEgPSAqKG9iamVjdF9ibG9jayAqIGNvbnN0Kil4 OworICBvYmplY3RfYmxvY2sgKnAyID0gKihvYmplY3RfYmxvY2sgKiBjb25z dCopeTsKKworICBnY2NfYXNzZXJ0IChwMS0+c2VjdC0+Y29tbW9uLmZsYWdz ICYgU0VDVElPTl9OQU1FRAorCSAgICAgICYmIHAyLT5zZWN0LT5jb21tb24u ZmxhZ3MgJiBTRUNUSU9OX05BTUVEKTsKKworICByZXR1cm4gc3RyY21wIChw MS0+c2VjdC0+bmFtZWQubmFtZSwgcDItPnNlY3QtPm5hbWVkLm5hbWUpOwog fQogCiAvKiBPdXRwdXQgdGhlIGRlZmluaXRpb25zIG9mIGFsbCBvYmplY3Rf YmxvY2tzLiAgKi8KQEAgLTc0MzUsNyArNzQzOSwyNSBAQCBvdXRwdXRfb2Jq ZWN0X2Jsb2NrX2h0YWIgKG9iamVjdF9ibG9jayAqKnNsb3QsIHZvaWQgKikK IHZvaWQKIG91dHB1dF9vYmplY3RfYmxvY2tzICh2b2lkKQogewotICBvYmpl Y3RfYmxvY2tfaHRhYi0+dHJhdmVyc2U8dm9pZCAqLCBvdXRwdXRfb2JqZWN0 X2Jsb2NrX2h0YWI+IChOVUxMKTsKKyAgdmVjPG9iamVjdF9ibG9jayAqLCB2 YV9oZWFwPiB2ID0gdk5VTEw7CisgIG9iamVjdF9ibG9jayAqb2JqOworICBo YXNoX3RhYmxlPG9iamVjdF9ibG9ja19oYXNoZXI+OjppdGVyYXRvciBoaTsK KworICBGT1JfRUFDSF9IQVNIX1RBQkxFX0VMRU1FTlQgKCpvYmplY3RfYmxv Y2tfaHRhYiwgb2JqLCBvYmplY3RfYmxvY2sgKiwgaGkpCisgICAgaWYgKG9i ai0+c2VjdC0+Y29tbW9uLmZsYWdzICYgU0VDVElPTl9OQU1FRCkKKyAgICAg IHYuc2FmZV9wdXNoIChvYmopOworCisgIC8qIFNvcnQgdGhlbSBpbiBvcmRl ciB0byBvdXRwdXQgdGhlbSBpbiBhIGRldGVybWluaXN0aWMgbWFubmVyLAor ICAgICBvdGhlcndpc2Ugd2UgbWF5IGdldCAucm9kYXRhIHNlY3Rpb25zIGlu IGRpZmZlcmVudCBvcmRlcnMgd2l0aAorICAgICBhbmQgd2l0aG91dCAtZy4g ICovCisgIHYucXNvcnQgKG91dHB1dF9vYmplY3RfYmxvY2tfY29tcGFyZSk7 CisgIHVuc2lnbmVkIGk7CisgIEZPUl9FQUNIX1ZFQ19FTFQgKHYsIGksIG9i aikKKyAgICBvdXRwdXRfb2JqZWN0X2Jsb2NrIChvYmopOworCisgIEZPUl9F QUNIX0hBU0hfVEFCTEVfRUxFTUVOVCAoKm9iamVjdF9ibG9ja19odGFiLCBv YmosIG9iamVjdF9ibG9jayAqLCBoaSkKKyAgICBpZiAoIShvYmotPnNlY3Qt PmNvbW1vbi5mbGFncyAmIFNFQ1RJT05fTkFNRUQpKQorICAgICAgb3V0cHV0 X29iamVjdF9ibG9jayAob2JqKTsKIH0KIAogLyogVGhpcyBmdW5jdGlvbiBw cm92aWRlcyBhIHBvc3NpYmxlIGltcGxlbWVudGF0aW9uIG9mIHRoZQo= --------------000806000507080709050406--