From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12496 invoked by alias); 10 Jun 2013 17:19:45 -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 12479 invoked by uid 89); 10 Jun 2013 17:19:45 -0000 X-Spam-SWARE-Status: No, score=-7.0 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.1 X-Spam-User: qpsmtpd, 2 recipients Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 10 Jun 2013 17:19:44 +0000 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga102.jf.intel.com with ESMTP; 10 Jun 2013 10:17:23 -0700 X-ExtLoop1: 1 Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34]) by fmsmga001.fm.intel.com with ESMTP; 10 Jun 2013 10:20:03 -0700 Received: from fmsmsx101.amr.corp.intel.com ([169.254.1.135]) by FMSMSX103.amr.corp.intel.com ([169.254.3.57]) with mapi id 14.03.0123.003; Mon, 10 Jun 2013 10:19:36 -0700 From: "Iyer, Balaji V" To: "Joseph S. Myers" CC: "gcc-patches@gcc.gnu.org" , Jakub Jelinek , "mpolacek@gcc.gnu.org" Subject: RE: [PATCH] Fix for PR c/57563 Date: Mon, 10 Jun 2013 17:19:00 -0000 Message-ID: References: In-Reply-To: Content-Type: multipart/mixed; boundary="_002_BF230D13CA30DD48930C31D4099330003A42D776FMSMSX101amrcor_" MIME-Version: 1.0 X-Virus-Found: No X-SW-Source: 2013-06/txt/msg00518.txt.bz2 --_002_BF230D13CA30DD48930C31D4099330003A42D776FMSMSX101amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-length: 3008 > -----Original Message----- > From: gcc-patches-owner@gcc.gnu.org [mailto:gcc-patches- > owner@gcc.gnu.org] On Behalf Of Joseph S. Myers > Sent: Monday, June 10, 2013 11:16 AM > To: Iyer, Balaji V > Cc: gcc-patches@gcc.gnu.org; Jakub Jelinek; mpolacek@gcc.gnu.org > Subject: RE: [PATCH] Fix for PR c/57563 >=20 > On Mon, 10 Jun 2013, Iyer, Balaji V wrote: >=20 > > > You don't say what the actual error was, and neither does the origina= l PR. > > > But if it was an ICE from an EXCESS_PRECISION_EXPR getting to the > > > gimplifier, that suggests that c_fully_fold isn't getting called > > > somewhere it should be - and probably calling c_fully_fold is the > > > correct fix rather than inserting a cast. If you can get such ICEs > > > for EXCESS_PRECISION_EXPR, it's quite possible you might get them > > > for C_MAYBE_CONST_EXPR as well (e.g. try using 0 / 0, or compound > > > literals of variably modified type, in various places in the affected > expressions), which should be fixed by using c_fully_fold but not by inse= rting a > cast. > > > > It was not. It was actually a type mismatch between double and long > > double caught in verify_gimple_in_seq function. So, is it OK for trunk? >=20 > A cast still doesn't make sense conceptually. Could you give a more deta= iled > analysis of what the trees look like at this point where you are insertin= g this cast, > and how you get to a mismatch? >=20 > EXCESS_PRECISION_EXPR can be thought of as a conversion operator. It sho= uld > only appear at the top level of an expression. At the point where excess > precision should be removed - the value converted to its semantic type - = either > the expression with excess precision should be folded using c_fully_fold = (if this is > the expression of an expression statement, or otherwise will go inside a = tree > that c_fully_fold does not recurse inside), or the operand of the > EXCESS_PRECISION_EXPR should be converted to the semantic type with the > "convert" function. In neither case is generating a cast appropriate; th= at's for > when the user actually wrote a cast in their source code. I looked into it a bit more detail. It was an error on my side. I was remov= ing the excess precision expr layer instead of fully folding it. I did that= change (i.e. fully fold the expression) and all the errors seem to go away= . Here is the fixed patch that fixes PR c/57563. It passes for 32 bit and 6= 4 bit tests. Here are the changelog entries: gcc/c/ChangeLog 2013-06-10 Balaji V. Iyer * c-array-notation.c (fix_builtin_array_notation_fn): Fully folded excessive precision expressions in function parameters. gcc/testsuite/ChangeLog 2013-06-10 Balaji V. Iyer PR c/57563 * c-c++-common/cilk-plus/AN/builtin_fn_mutating.c (main): Fixed a b= ug in how we check __sec_reduce_mutating function's result. Thanks, Balaji V. Iyer. >=20 > -- > Joseph S. Myers > joseph@codesourcery.com --_002_BF230D13CA30DD48930C31D4099330003A42D776FMSMSX101amrcor_ Content-Type: text/plain; name="patch_fix_pr57563.txt" Content-Description: patch_fix_pr57563.txt Content-Disposition: attachment; filename="patch_fix_pr57563.txt"; size=1441; creation-date="Mon, 10 Jun 2013 17:00:25 GMT"; modification-date="Mon, 10 Jun 2013 16:57:20 GMT" Content-Transfer-Encoding: base64 Content-length: 1957 ZGlmZiAtLWdpdCBhL2djYy9jL2MtYXJyYXktbm90YXRpb24uYyBiL2djYy9j L2MtYXJyYXktbm90YXRpb24uYwppbmRleCBiMTA0MGRhLi45Mjk4YWUwIDEw MDY0NAotLS0gYS9nY2MvYy9jLWFycmF5LW5vdGF0aW9uLmMKKysrIGIvZ2Nj L2MvYy1hcnJheS1ub3RhdGlvbi5jCkBAIC0xNTgsMTAgKzE1OCwxMyBAQCBm aXhfYnVpbHRpbl9hcnJheV9ub3RhdGlvbl9mbiAodHJlZSBhbl9idWlsdGlu X2ZuLCB0cmVlICpuZXdfdmFyKQogICAgIGZ1bmNfcGFybSA9IENBTExfRVhQ Ul9BUkcgKGFuX2J1aWx0aW5fZm4sIDApOwogICAKICAgd2hpbGUgKFRSRUVf Q09ERSAoZnVuY19wYXJtKSA9PSBDT05WRVJUX0VYUFIKLQkgfHwgVFJFRV9D T0RFIChmdW5jX3Bhcm0pID09IEVYQ0VTU19QUkVDSVNJT05fRVhQUgogCSB8 fCBUUkVFX0NPREUgKGZ1bmNfcGFybSkgPT0gTk9QX0VYUFIpCiAgICAgZnVu Y19wYXJtID0gVFJFRV9PUEVSQU5EIChmdW5jX3Bhcm0sIDApOwogCisgIC8q IEZ1bGx5IGZvbGQgYW55IEVYQ0VTU0lWRV9QUkVDSVNJT04gRVhQUiB0aGF0 IGNhbiBvY2N1ciBpbiB0aGUgZnVuY3Rpb24KKyAgICAgcGFyYW1ldGVyLiAg Ki8KKyAgZnVuY19wYXJtID0gY19mdWxseV9mb2xkIChmdW5jX3Bhcm0sIGZh bHNlLCBOVUxMKTsKKyAgCiAgIGxvY2F0aW9uID0gRVhQUl9MT0NBVElPTiAo YW5fYnVpbHRpbl9mbik7CiAgIAogICBpZiAoIWZpbmRfcmFuayAobG9jYXRp b24sIGFuX2J1aWx0aW5fZm4sIGFuX2J1aWx0aW5fZm4sIHRydWUsICZyYW5r KSkKZGlmZiAtLWdpdCBhL2djYy90ZXN0c3VpdGUvYy1jKystY29tbW9uL2Np bGstcGx1cy9BTi9idWlsdGluX2ZuX211dGF0aW5nLmMgYi9nY2MvdGVzdHN1 aXRlL2MtYysrLWNvbW1vbi9jaWxrLXBsdXMvQU4vYnVpbHRpbl9mbl9tdXRh dGluZy5jCmluZGV4IDY2MzU1NjUuLjdjMTk0YzIgMTAwNjQ0Ci0tLSBhL2dj Yy90ZXN0c3VpdGUvYy1jKystY29tbW9uL2NpbGstcGx1cy9BTi9idWlsdGlu X2ZuX211dGF0aW5nLmMKKysrIGIvZ2NjL3Rlc3RzdWl0ZS9jLWMrKy1jb21t b24vY2lsay1wbHVzL0FOL2J1aWx0aW5fZm5fbXV0YXRpbmcuYwpAQCAtNDQs MTEgKzQ0LDExIEBAIGludCBtYWluKHZvaWQpCiAgIG1heF92YWx1ZSA9IGFy cmF5M1swXSAqIGFycmF5NFswXTsKICAgZm9yIChpaSA9IDA7IGlpIDwgMTA7 IGlpKyspCiAgICAgaWYgKGFycmF5M1tpaV0gKiBhcnJheTRbaWldID4gbWF4 X3ZhbHVlKSB7Ci0gICAgICBtYXhfdmFsdWUgPSBhcnJheTNbaWldICogYXJy YXk0W2lpXTsKICAgICAgIG1heF9pbmRleCA9IGlpOwogICAgIH0KICAgICAK LSAgCisgIGZvciAoaWkgPSAwOyBpaSA8IDEwOyBpaSsrKQorICAgIG15X2Z1 bmMgKCZtYXhfdmFsdWUsIGFycmF5M1tpaV0gKiBhcnJheTRbaWldKTsKICAg CiAjaWYgSEFWRV9JTwogICBmb3IgKGlpID0gMDsgaWkgPCAxMDsgaWkrKykg Cg== --_002_BF230D13CA30DD48930C31D4099330003A42D776FMSMSX101amrcor_--