From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106385 invoked by alias); 20 Dec 2016 16:25: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 106324 invoked by uid 89); 20 Dec 2016 16:25:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.0 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=varasm, our 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 ESMTP; Tue, 20 Dec 2016 16:25:38 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9B0AEA1F72 for ; Tue, 20 Dec 2016 16:25:37 +0000 (UTC) Received: from abulafia.quesejoda.com (ovpn-117-2.ams2.redhat.com [10.36.117.2]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uBKGPZbc031268; Tue, 20 Dec 2016 11:25:36 -0500 To: jason merrill , gcc-patches From: Aldy Hernandez Subject: [PR c++/78572] handle array self references in intializers Message-ID: Date: Tue, 20 Dec 2016 16:42:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------0740AFC909F04DE2E4CDDE62" X-SW-Source: 2016-12/txt/msg01723.txt.bz2 This is a multi-part message in MIME format. --------------0740AFC909F04DE2E4CDDE62 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1563 The problem in this PR is that we're trying to initialize an array with members of itself: int array[10] = { array[3]=5, array[7]=3 }; The C++ front-end, in store_init_value() via cxx_constant_value() and friends will transform: {array[3] = 5, array[7] = 3} into: {[3]=5, [0]=5, [7]=3, [1]=3} which looks invalid to output_constructor*(), presumably because it isn't sorted by increasing index. Jakub has even gone further to show that for the following: ... = { array[3]=5, array[7]=3, array[7]=8, array[7] = 9 }; things get even worse, because we generate code to write twice into [3]: {[3]=5, [0]=5, [7]=9, [1]=3, [2]=8, [3]=9} I took the easy way in cxx_eval_store_expression() and marked the expression as non_constant_p if we're trying to set an array from members of itself. This causes us to to generate the initialization of the self-referencing array[sub] elements as a CLEANUP_POINT_EXPR: <>>>>; <>>>>; Ultimately this yields correct code: array: .zero 40 ... ... _GLOBAL__sub_I_array: .LFB1: .cfi_startproc movl $5, array+12(%rip) movl $5, array(%rip) movl $3, array+28(%rip) movl $3, array+4(%rip) ret Is this approach acceptable, or should we be marking this as non-constant somewhere else in the chain? Or perhaps another approach would be to handle such constructor holes in the in the varasm code? Aldy --------------0740AFC909F04DE2E4CDDE62 Content-Type: text/plain; charset=UTF-8; name="curr" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="curr" Content-length: 1692 Y29tbWl0IDI5NWQ5M2Y2MGJjYmVjNWI5OTU5YTdiMzY1NmYxMGFhMGRmNzFj OWYKQXV0aG9yOiBBbGR5IEhlcm5hbmRleiA8YWxkeWhAcmVkaGF0LmNvbT4K RGF0ZTogICBUdWUgRGVjIDIwIDA2OjEzOjI2IDIwMTYgLTA1MDAKCiAgICAg ICAgICAgIFBSIGMrKy83ODU3MgogICAgICAgICAgICAqIGNvbnN0ZXhwci5j IChjeHhfZXZhbF9zdG9yZV9leHByZXNzaW9uKTogQXZvaWQgYXJyYXkgc2Vs ZgogICAgICAgICAgICByZWZlcmVuY2VzIGluIGluaXRpYWxpemF0aW9uLgoK ZGlmZiAtLWdpdCBhL2djYy9jcC9jb25zdGV4cHIuYyBiL2djYy9jcC9jb25z dGV4cHIuYwppbmRleCBhZWRkMDA0Li5hYzI3OWFkIDEwMDY0NAotLS0gYS9n Y2MvY3AvY29uc3RleHByLmMKKysrIGIvZ2NjL2NwL2NvbnN0ZXhwci5jCkBA IC0zMzEzLDYgKzMzMTMsMTUgQEAgY3h4X2V2YWxfc3RvcmVfZXhwcmVzc2lv biAoY29uc3QgY29uc3RleHByX2N0eCAqY3R4LCB0cmVlIHQsCiAJfQogICAg IH0KIAorICAvKiBJbml0aWFsaXppbmcgYW4gYXJyYXkgZnJvbSBhIHZhcmlh bnQgb2YgaXRzZWxmIGlzIGEgbm9uLWNvbnN0YW50LgorICAgICBUaGlzIGF2 b2lkcyBhdHRlbXBzIGF0IGdlbmVyYXRpbmcgaW5jb3JyZWN0IHNlbGYgcmVm ZXJlbmNlcyBpbgorICAgICBzb21ldGhpbmcgbGlrZTogaW50IGZvb1sxMF0g PSB7IHN0dWZmWzNdPTggfS4gICovCisgIGlmIChUUkVFX0NPREUgKHRhcmdl dCkgPT0gQVJSQVlfUkVGICYmIG9iamVjdCA9PSBjdHgtPm9iamVjdCkKKyAg ICB7CisgICAgICAqbm9uX2NvbnN0YW50X3AgPSB0cnVlOworICAgICAgcmV0 dXJuIHQ7CisgICAgfQorCiAgIC8qIEFuZCB0aGVuIGZpbmQvYnVpbGQgdXAg b3VyIGluaXRpYWxpemVyIGZvciB0aGUgcGF0aCB0byB0aGUgc3Vib2JqZWN0 CiAgICAgIHdlJ3JlIGluaXRpYWxpemluZy4gICovCiAgIHRyZWUgKnZhbHA7 CmRpZmYgLS1naXQgYS9nY2MvdGVzdHN1aXRlL2crKy5kZy9wcjc4NTcyLkMg Yi9nY2MvdGVzdHN1aXRlL2crKy5kZy9wcjc4NTcyLkMKbmV3IGZpbGUgbW9k ZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uODJhYjRlMwotLS0gL2Rldi9udWxs CisrKyBiL2djYy90ZXN0c3VpdGUvZysrLmRnL3ByNzg1NzIuQwpAQCAtMCww ICsxLDkgQEAKKy8vIHsgZGctZG8gY29tcGlsZSB9ICovCisKK3N0YXRpYyBp bnQgYXJyYXlbMTBdID0geyBhcnJheVszXT01LCBhcnJheVs3XT0zIH07CisK K2ludAorbWFpbiAoKQoreworICByZXR1cm4gMDsKK30K --------------0740AFC909F04DE2E4CDDE62--