From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36403 invoked by alias); 26 Mar 2018 09:19:19 -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 36314 invoked by uid 89); 26 Mar 2018 09:19:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.1 required=5.0 tests=BAYES_00,GIT_PATCH_2,GIT_PATCH_3,KAM_ASCII_DIVIDERS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=concerned, curious X-HELO: userp2120.oracle.com Received: from userp2120.oracle.com (HELO userp2120.oracle.com) (156.151.31.85) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 26 Mar 2018 09:19:09 +0000 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w2Q94iNR095944; Mon, 26 Mar 2018 09:19:07 GMT Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2120.oracle.com with ESMTP id 2gxwwm06eh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 26 Mar 2018 09:19:06 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w2Q9J5U3010927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 26 Mar 2018 09:19:06 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w2Q9J5Fe006861; Mon, 26 Mar 2018 09:19:05 GMT Received: from [192.168.1.4] (/80.181.236.138) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Mar 2018 02:19:04 -0700 Subject: Re: [C++ Patch] PR 84632 ("[8 Regression] internal compiler error: tree check: expected record_type or union_type or qual_union_type, have array_type in reduced_constant_expression_p...") To: Jason Merrill Cc: "gcc-patches@gcc.gnu.org" References: <8a93abd6-69ae-4ff5-5332-eb8791d492f1@oracle.com> <4c45f0a6-c4e1-4124-f7e6-d01073e36975@oracle.com> <3ef910c9-fa3a-bd25-66bc-069437169304@oracle.com> <8ec9f4c3-ef14-426e-1758-9711cf04343c@oracle.com> From: Paolo Carlini Message-ID: <13d89e96-c14f-fa02-0258-aeb8895513fc@oracle.com> Date: Mon, 26 Mar 2018 10:30:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------FA67A5519661BF205BAD6795" X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8843 signatures=668695 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803260101 X-IsSubscribed: yes X-SW-Source: 2018-03/txt/msg01378.txt.bz2 This is a multi-part message in MIME format. --------------FA67A5519661BF205BAD6795 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1853 Hi, On 23/03/2018 13:39, Jason Merrill wrote: > On Fri, Mar 23, 2018 at 6:13 AM, Paolo Carlini wrote: >> On 22/03/2018 23:26, Jason Merrill wrote: >>> On Thu, Mar 22, 2018 at 5:39 PM, Paolo Carlini >>> wrote: >>>> ... with patch ;) >>>> >>>> If you are curious where the heck that INDIRECT_REF is coming from, is >>>> coming from the gimplifier, cp_gimpliify_expr, via build_vec_init. Grrr. >>> Hmm, maybe build_vec_init should call itself directly rather than via >>> build_aggr_init in the case of multidimensional arrays. >> Yes, arranging things like that seems doable. However, yesterday, while >> fiddling with the idea and instrumenting the code with some gcc_asserts, I >> noticed that we have yet another tree code to handle, TARGET_EXPR, as in >> lines #41, #47, #56 of ext/complit12.C, and in that case build_aggr_init is >> simply called by check_initializer via build_aggr_init_full_exprs, the >> "normal" path. Well, unless we want to adjust/reject complit12.C too, which >> clang rejects, in fact with errors on lines #19 and #29 too. The below >> passes testing. > I think I'd like to allow TARGET_EXPR here, with a comment about > compound literals, but avoid INDIRECT_REF with that build_vec_init > change. I see. Having run the full testsuite a number of times with additional gcc_asserts, I'm very confident that something as simple as the below is fine, at least as far as the testsuite + variants of lambda-array.C is concerned. In it I'm also proposing a gcc_assert verifying that the very idea of not using any diagnostic conditional makes sense for the internally generated INDIRECT_REFs: in the existing build_aggr_init if the types were different from_array would be zero and, for INDIRECT_REF as init, the condition true. Thanks, Paolo. /////////////////////// --------------FA67A5519661BF205BAD6795 Content-Type: text/plain; charset=UTF-8; name="patch_84632_4" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="patch_84632_4" Content-length: 4620 SW5kZXg6IGNwL2luaXQuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBj cC9pbml0LmMJKHJldmlzaW9uIDI1ODg0NikKKysrIGNwL2luaXQuYwkod29y a2luZyBjb3B5KQpAQCAtMTY4OCwxNCArMTY4OCw2IEBAIGJ1aWxkX2FnZ3Jf aW5pdCAodHJlZSBleHAsIHRyZWUgaW5pdCwgaW50IGZsYWdzLCB0CiAJfQog ICAgICAgZWxzZQogCXsKLQkgIC8qIEFuIGFycmF5IG1heSBub3QgYmUgaW5p dGlhbGl6ZWQgdXNlIHRoZSBwYXJlbnRoZXNpemVkCi0JICAgICBpbml0aWFs aXphdGlvbiBmb3JtIC0tIHVubGVzcyB0aGUgaW5pdGlhbGl6ZXIgaXMgIigp Ii4gICovCi0JICBpZiAoaW5pdCAmJiBUUkVFX0NPREUgKGluaXQpID09IFRS RUVfTElTVCkKLQkgICAgewotCSAgICAgIGlmIChjb21wbGFpbiAmIHRmX2Vy cm9yKQotCQllcnJvciAoImJhZCBhcnJheSBpbml0aWFsaXplciIpOwotCSAg ICAgIHJldHVybiBlcnJvcl9tYXJrX25vZGU7Ci0JICAgIH0KIAkgIC8qIE11 c3QgYXJyYW5nZSB0byBpbml0aWFsaXplIGVhY2ggZWxlbWVudCBvZiBFWFAK IAkgICAgIGZyb20gZWxlbWVudHMgb2YgSU5JVC4gICovCiAJICBpZiAoY3Zf cXVhbGlmaWVkX3AgKHR5cGUpKQpAQCAtMTcwNSwxNCArMTY5NywxNyBAQCBi dWlsZF9hZ2dyX2luaXQgKHRyZWUgZXhwLCB0cmVlIGluaXQsIGludCBmbGFn cywgdAogCSAgZnJvbV9hcnJheSA9IChpdHlwZSAmJiBzYW1lX3R5cGVfcCAo VFJFRV9UWVBFIChpbml0KSwKIAkJCQkJICAgICAgVFJFRV9UWVBFIChleHAp KSk7CiAKLQkgIGlmIChpbml0ICYmICFmcm9tX2FycmF5Ci0JICAgICAgJiYg IUJSQUNFX0VOQ0xPU0VEX0lOSVRJQUxJWkVSX1AgKGluaXQpKQorCSAgaWYg KGluaXQgJiYgIUJSQUNFX0VOQ0xPU0VEX0lOSVRJQUxJWkVSX1AgKGluaXQp CisJICAgICAgJiYgKCFmcm9tX2FycmF5CisJCSAgfHwgKFRSRUVfQ09ERSAo aW5pdCkgIT0gQ09OU1RSVUNUT1IKKwkJICAgICAgLyogQ2FuIGhhcHBlbiwg ZWcsIGhhbmRsaW5nIHRoZSBjb21wb3VuZC1saXRlcmFscworCQkJIGV4dGVu c2lvbiAoZXh0L2NvbXBsaXQxMi5DKS4gICovCisJCSAgICAgICYmIFRSRUVf Q09ERSAoaW5pdCkgIT0gVEFSR0VUX0VYUFIpKSkKIAkgICAgewogCSAgICAg IGlmIChjb21wbGFpbiAmIHRmX2Vycm9yKQotCQlwZXJtZXJyb3IgKGluaXRf bG9jLCAiYXJyYXkgbXVzdCBiZSBpbml0aWFsaXplZCAiCi0JCQkgICAid2l0 aCBhIGJyYWNlLWVuY2xvc2VkIGluaXRpYWxpemVyIik7Ci0JICAgICAgZWxz ZQotCQlyZXR1cm4gZXJyb3JfbWFya19ub2RlOworCQllcnJvcl9hdCAoaW5p dF9sb2MsICJhcnJheSBtdXN0IGJlIGluaXRpYWxpemVkICIKKwkJCSAgIndp dGggYSBicmFjZS1lbmNsb3NlZCBpbml0aWFsaXplciIpOworCSAgICAgIHJl dHVybiBlcnJvcl9tYXJrX25vZGU7CiAJICAgIH0KIAl9CiAKQEAgLTQzNzEs NyArNDM2NiwxOSBAQCBidWlsZF92ZWNfaW5pdCAodHJlZSBiYXNlLCB0cmVl IG1heGluZGV4LCB0cmVlIGluaQogCSAgICBlbHRfaW5pdCA9IGNwX2J1aWxk X21vZGlmeV9leHByIChpbnB1dF9sb2NhdGlvbiwgdG8sIE5PUF9FWFBSLAog CQkJCQkgICAgIGZyb20sIGNvbXBsYWluKTsKIAkgIGVsc2UgaWYgKHR5cGVf YnVpbGRfY3Rvcl9jYWxsICh0eXBlKSkKLQkgICAgZWx0X2luaXQgPSBidWls ZF9hZ2dyX2luaXQgKHRvLCBmcm9tLCAwLCBjb21wbGFpbik7CisJICAgIHsK KwkgICAgICBpZiAoVFJFRV9DT0RFICh0eXBlKSA9PSBBUlJBWV9UWVBFCisJ CSAgJiYgZnJvbSAmJiBUUkVFX0NPREUgKGZyb20pID09IElORElSRUNUX1JF RikKKwkJeworCQkgIGdjY19hc3NlcnQgKHNhbWVfdHlwZV9pZ25vcmluZ190 b3BfbGV2ZWxfcXVhbGlmaWVyc19wCisJCQkgICAgICAodHlwZSwgVFJFRV9U WVBFIChmcm9tKSkpOworCQkgIGVsdF9pbml0ID0gYnVpbGRfdmVjX2luaXQg KHRvLCBOVUxMX1RSRUUsIGZyb20sCisJCQkJCSAgICAgLypleHBsaWNpdF92 YWx1ZV9pbml0X3A9Ki9mYWxzZSwKKwkJCQkJICAgICAvKmZyb21fYXJyYXk9 Ki8xLCBjb21wbGFpbik7CisJCX0KKwkgICAgICBlbHNlCisJCWVsdF9pbml0 ID0gYnVpbGRfYWdncl9pbml0ICh0bywgZnJvbSwgMCwgY29tcGxhaW4pOwor CSAgICB9CiAJICBlbHNlIGlmIChmcm9tKQogCSAgICBlbHRfaW5pdCA9IGNw X2J1aWxkX21vZGlmeV9leHByIChpbnB1dF9sb2NhdGlvbiwgdG8sIE5PUF9F WFBSLCBmcm9tLAogCQkJCQkgICAgIGNvbXBsYWluKTsKSW5kZXg6IHRlc3Rz dWl0ZS9nKysuZGcvaW5pdC9hcnJheTQ5LkMKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gdGVzdHN1aXRlL2crKy5kZy9pbml0L2FycmF5NDkuQwkobm9u ZXhpc3RlbnQpCisrKyB0ZXN0c3VpdGUvZysrLmRnL2luaXQvYXJyYXk0OS5D CSh3b3JraW5nIGNvcHkpCkBAIC0wLDAgKzEsNiBAQAorLy8gUFIgYysrLzg0 NjMyCisvLyB7IGRnLWFkZGl0aW9uYWwtb3B0aW9ucyAiLXciIH0KKworY2xh c3MgeworICAmYTsgIC8vIHsgZGctZXJyb3IgImZvcmJpZHMgZGVjbGFyYXRp b24iIH0KK30gYlsyXSA9IGI7ICAvLyB7IGRnLWVycm9yICJpbml0aWFsaXpl ZCIgfQpJbmRleDogdGVzdHN1aXRlL2crKy5kZy90b3J0dXJlL3ByNzA0OTku Qwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB0ZXN0c3VpdGUvZysrLmRn L3RvcnR1cmUvcHI3MDQ5OS5DCShyZXZpc2lvbiAyNTg4NDYpCisrKyB0ZXN0 c3VpdGUvZysrLmRnL3RvcnR1cmUvcHI3MDQ5OS5DCSh3b3JraW5nIGNvcHkp CkBAIC0xLDUgKzEsNSBAQAogLy8geyBkZy1kbyBjb21waWxlIH0KLS8vIHsg ZGctYWRkaXRpb25hbC1vcHRpb25zICItdyAtZnBlcm1pc3NpdmUgLVduby1w c2FiaSIgfQorLy8geyBkZy1hZGRpdGlvbmFsLW9wdGlvbnMgIi13IC1Xbm8t cHNhYmkiIH0KIC8vIHsgZGctYWRkaXRpb25hbC1vcHRpb25zICItbWF2eCIg eyB0YXJnZXQgeDg2XzY0LSotKiBpPzg2LSotKiB9IH0KIAogdHlwZWRlZiBk b3VibGUgX19tMjU2ZCBfX2F0dHJpYnV0ZV9fICgoX192ZWN0b3Jfc2l6ZV9f ICgzMiksIF9fbWF5X2FsaWFzX18pKTsKQEAgLTMwLDcgKzMwLDcgQEAgc3Ry dWN0IEZvbyB7CiB0ZW1wbGF0ZTx0eXBlbmFtZSBUeD4gIAogX19hdHRyaWJ1 dGVfXygoX19hbHdheXNfaW5saW5lX18pKSBpbmxpbmUgdm9pZCBpbmxpbmVG dW5jKFR4IGh4W10pIHsKICAgICBUeCB4ID0gaHhbMF0sIHkgPSBoeFsxXTsK LSAgICBUeCBsYW1bMV0gPSAoeCp5KTsKKyAgICBUeCBsYW1bMV0gPSB7KHgq eSl9OwogfQogCiB2b2lkIEZvb0JhckZ1bmMgKCkgewo= --------------FA67A5519661BF205BAD6795--