From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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-Archive: List-Post: List-Help: Sender: gcc-patches-owner@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: Mon, 08 Jun 2015 04:18: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 , 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: Content-Type: multipart/mixed; boundary="------------040009040006050900030602" X-SW-Source: 2015-06/txt/msg00522.txt.bz2 This is a multi-part message in MIME format. --------------040009040006050900030602 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-length: 2932 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 --------------040009040006050900030602 Content-Type: text/plain; charset=UTF-8; name="curr" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="curr" Content-length: 3014 CSogdmFyYXNtLmMgKG91dHB1dF9vYmplY3RfYmxvY2tfaHRhYik6IFB1c2gg ZWFjaCBvYmplY3RfYmxvY2sgaW50bwoJYSB2ZWN0b3IgaW5zdGVhZCBvZiBj YWxsaW5nIG91dHB1dF9vYmplY3RfYmxvY2suCgkob3V0cHV0X29iamVjdF9i bG9ja19jb21wYXJlKTogTmV3LgoJKG91dHB1dF9vYmplY3RfYmxvY2tzKTog U29ydCBvYmplY3RfYmxvY2tzIGFuZCB0aGVuIG91dHB1dCB0aGVtLgoKZGlm ZiAtLWdpdCBhL2djYy92YXJhc20uYyBiL2djYy92YXJhc20uYwppbmRleCAx OGYzZWFjLi4wMDgzNjBlIDEwMDY0NAotLS0gYS9nY2MvdmFyYXNtLmMKKysr IGIvZ2NjL3ZhcmFzbS5jCkBAIC03NDIwLDIyICs3NDIwLDU3IEBAIG91dHB1 dF9vYmplY3RfYmxvY2sgKHN0cnVjdCBvYmplY3RfYmxvY2sgKmJsb2NrKQog ICAgIH0KIH0KIAotLyogQSBodGFiX3RyYXZlcnNlIGNhbGxiYWNrIHVzZWQg dG8gY2FsbCBvdXRwdXRfb2JqZWN0X2Jsb2NrIGZvcgotICAgZWFjaCBtZW1i ZXIgb2Ygb2JqZWN0X2Jsb2NrX2h0YWIuICAqLworLyogQW4gaHRhYl90cmF2 ZXJzZSBjYWxsYmFjayB1c2VkIHRvIGNvcHkgb2JqZWN0X2Jsb2NrcyBpbnRv IGEgdmVjdG9yLiAgKi8KIAogaW50Ci1vdXRwdXRfb2JqZWN0X2Jsb2NrX2h0 YWIgKG9iamVjdF9ibG9jayAqKnNsb3QsIHZvaWQgKikKK291dHB1dF9vYmpl Y3RfYmxvY2tfaHRhYiAob2JqZWN0X2Jsb2NrICoqc2xvdCwgdm9pZCAqZGF0 YSkKIHsKLSAgb3V0cHV0X29iamVjdF9ibG9jayAoKnNsb3QpOworICB2ZWM8 b2JqZWN0X2Jsb2NrICosIHZhX2hlYXA+ICp2ID0gKHZlYzxvYmplY3RfYmxv Y2sgKiwgdmFfaGVhcD4gKikgZGF0YTsKKyAgdi0+c2FmZV9wdXNoICgqc2xv dCk7CiAgIHJldHVybiAxOwogfQogCisvKiBBIGNhbGxiYWNrIGZvciBxc29y dCB0byBjb21wYXJlIG9iamVjdF9ibG9ja3MuICBXZSBvbmx5IGNhcmUgYWJv dXQKKyAgIG5hbWVkIHNlY3Rpb25zLiAgKi8KKworc3RhdGljIGludAorb3V0 cHV0X29iamVjdF9ibG9ja19jb21wYXJlIChjb25zdCB2b2lkICp4LCBjb25z dCB2b2lkICp5KQoreworICBvYmplY3RfYmxvY2sgKnAxID0gKihvYmplY3Rf YmxvY2sgKiBjb25zdCopeDsKKyAgb2JqZWN0X2Jsb2NrICpwMiA9ICoob2Jq ZWN0X2Jsb2NrICogY29uc3QqKXk7CisKKyAgaWYgKHAxLT5zZWN0LT5jb21t b24uZmxhZ3MgJiBTRUNUSU9OX05BTUVECisgICAgICAmJiAhKHAyLT5zZWN0 LT5jb21tb24uZmxhZ3MgJiBTRUNUSU9OX05BTUVEKSkKKyAgICByZXR1cm4g MTsKKworICBpZiAoIShwMS0+c2VjdC0+Y29tbW9uLmZsYWdzICYgU0VDVElP Tl9OQU1FRCkKKyAgICAgICYmIHAyLT5zZWN0LT5jb21tb24uZmxhZ3MgJiBT RUNUSU9OX05BTUVEKQorICAgIHJldHVybiAtMTsKKworICBpZiAocDEtPnNl Y3QtPmNvbW1vbi5mbGFncyAmIFNFQ1RJT05fTkFNRUQKKyAgICAgICYmIHAy LT5zZWN0LT5jb21tb24uZmxhZ3MgJiBTRUNUSU9OX05BTUVEKQorICAgIHJl dHVybiBzdHJjbXAgKHAxLT5zZWN0LT5uYW1lZC5uYW1lLAorCQkgICBwMi0+ c2VjdC0+bmFtZWQubmFtZSk7CisKKyAgcmV0dXJuIDA7Cit9CisKIC8qIE91 dHB1dCB0aGUgZGVmaW5pdGlvbnMgb2YgYWxsIG9iamVjdF9ibG9ja3MuICAq LwogCiB2b2lkCiBvdXRwdXRfb2JqZWN0X2Jsb2NrcyAodm9pZCkKIHsKLSAg b2JqZWN0X2Jsb2NrX2h0YWItPnRyYXZlcnNlPHZvaWQgKiwgb3V0cHV0X29i amVjdF9ibG9ja19odGFiPiAoTlVMTCk7CisgIHZlYzxvYmplY3RfYmxvY2sg KiwgdmFfaGVhcD4gdiA9IHZOVUxMOworICBvYmplY3RfYmxvY2tfaHRhYi0+ dHJhdmVyc2U8dm9pZCAqLCBvdXRwdXRfb2JqZWN0X2Jsb2NrX2h0YWI+ICgm dik7CisKKyAgLyogU29ydCB0aGVtIGluIG9yZGVyIHRvIG91dHB1dCB0aGVt IGluIGEgZGV0ZXJtaW5pc3RpYyBtYW5uZXIsCisgICAgIG90aGVyd2lzZSB3 ZSBtYXkgZ2V0IC5yb2RhdGEgc2VjdGlvbnMgaW4gZGlmZmVyZW50IG9yZGVy cyB3aXRoCisgICAgIGFuZCB3aXRob3V0IC1nLiAgKi8KKyAgdi5xc29ydCAo b3V0cHV0X29iamVjdF9ibG9ja19jb21wYXJlKTsKKyAgdW5zaWduZWQgaTsK KyAgb2JqZWN0X2Jsb2NrICpvYmo7CisgIEZPUl9FQUNIX1ZFQ19FTFQgKHYs IGksIG9iaikKKyAgICBvdXRwdXRfb2JqZWN0X2Jsb2NrIChvYmopOwogfQog CiAvKiBUaGlzIGZ1bmN0aW9uIHByb3ZpZGVzIGEgcG9zc2libGUgaW1wbGVt ZW50YXRpb24gb2YgdGhlCg== --------------040009040006050900030602--