From patchwork Mon Jun 10 22:15:58 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Iyer, Balaji V" X-Patchwork-Id: 250403 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "localhost", Issuer "www.qmailtoaster.com" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 8900B2C008C for ; Tue, 11 Jun 2013 08:16:25 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id:references:in-reply-to :content-type:mime-version; q=dns; s=default; b=WvVr/3HVr2lPN4oL zbwgF9Q1Ze+Jb9fYNxFGcPKatiBQdVF55qEmh2ezXuEeRW7PqSXuLzxdggptlq+B AlFV4HkJqHGLQDGbByawnVTJ/3+003iP4CtRvqj8XcFSc1BpV829YTg/B0jSj+Mq IDSYleqLKUm5J1pua3uQJl98n+E= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id:references:in-reply-to :content-type:mime-version; s=default; bh=/+t22rf51Tcz49do8KV2sR krFSw=; b=rKs/Ofgvyi7wowDnSbo1pwijvDh5Lf00sqg7NPDHnmGE+j3RCgpqa0 GJAvIL40XdXWW+O1wpnEKm41ecKKBXJ5wEl9faZ7jNynKhJyNqKj10Gg2kdbm7Q7 UMSZYMZmECHf+j2Cs2tXSJWbYbqooKWGR/Bybw9SQ8aRYvyitlq/M= Received: (qmail 6607 invoked by alias); 10 Jun 2013 22:16:02 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 6571 invoked by uid 89); 10 Jun 2013 22:16:02 -0000 X-Spam-SWARE-Status: No, score=-7.1 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 mga11.intel.com (HELO mga11.intel.com) (192.55.52.93) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 10 Jun 2013 22:16:01 +0000 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 10 Jun 2013 15:16:41 -0700 X-ExtLoop1: 1 Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36]) by fmsmga002.fm.intel.com with ESMTP; 10 Jun 2013 15:15:58 -0700 Received: from fmsmsx153.amr.corp.intel.com (10.19.17.7) by FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 10 Jun 2013 15:15:58 -0700 Received: from fmsmsx101.amr.corp.intel.com ([169.254.1.135]) by FMSMSX153.amr.corp.intel.com ([169.254.9.202]) with mapi id 14.03.0123.003; Mon, 10 Jun 2013 15:15:58 -0700 From: "Iyer, Balaji V" To: Joseph 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 22:15:58 +0000 Message-ID: References: In-Reply-To: MIME-Version: 1.0 X-Virus-Found: No > -----Original Message----- > From: Joseph Myers [mailto:joseph@codesourcery.com] > Sent: Monday, June 10, 2013 5:18 PM > To: Iyer, Balaji V > Cc: gcc-patches@gcc.gnu.org; Jakub Jelinek; mpolacek@gcc.gnu.org > Subject: RE: [PATCH] Fix for PR c/57563 > > On Mon, 10 Jun 2013, Iyer, Balaji V wrote: > > > I looked into it a bit more detail. It was an error on my side. I was > > removing 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 64 bit tests. Here are the changelog entries: > > This version is better, but if removing an EXCESS_PRECISION_EXPR there caused > problems, why is it OK to remove CONVERT_EXPR and NOP_EXPR like you still > do - won't that also cause type mismatches (at least if the conversions are to > types that count as sufficiently different for GIMPLE purposes - say conversions > between 32-bit and 64-bit integers)? Maybe you actually need to fold without > removing any such wrappers first at all? I looked into it and they were an artifact of previous implementation. Those while loops were not even being entered. Thus, I took them out. Here is a fixed patch. Thanks, Balaji V. Iyer. > > -- > Joseph S. Myers > joseph@codesourcery.com diff --git a/gcc/c/c-array-notation.c b/gcc/c/c-array-notation.c old mode 100644 new mode 100755 index b1040da..3285969 --- a/gcc/c/c-array-notation.c +++ b/gcc/c/c-array-notation.c @@ -143,25 +143,18 @@ fix_builtin_array_notation_fn (tree an_builtin_fn, tree *new_var) || an_type == BUILT_IN_CILKPLUS_SEC_REDUCE_MUTATING) { call_fn = CALL_EXPR_ARG (an_builtin_fn, 2); - while (TREE_CODE (call_fn) == CONVERT_EXPR - || TREE_CODE (call_fn) == NOP_EXPR) + if (TREE_CODE (call_fn) == ADDR_EXPR) call_fn = TREE_OPERAND (call_fn, 0); - call_fn = TREE_OPERAND (call_fn, 0); - identity_value = CALL_EXPR_ARG (an_builtin_fn, 0); - while (TREE_CODE (identity_value) == CONVERT_EXPR - || TREE_CODE (identity_value) == NOP_EXPR) - identity_value = TREE_OPERAND (identity_value, 0); func_parm = CALL_EXPR_ARG (an_builtin_fn, 1); } else func_parm = CALL_EXPR_ARG (an_builtin_fn, 0); - while (TREE_CODE (func_parm) == CONVERT_EXPR - || TREE_CODE (func_parm) == EXCESS_PRECISION_EXPR - || TREE_CODE (func_parm) == NOP_EXPR) - func_parm = TREE_OPERAND (func_parm, 0); - + /* Fully fold any EXCESSIVE_PRECISION EXPR that can occur in the function + parameter. */ + func_parm = c_fully_fold (func_parm, false, NULL); + location = EXPR_LOCATION (an_builtin_fn); if (!find_rank (location, an_builtin_fn, an_builtin_fn, true, &rank)) diff --git a/gcc/testsuite/c-c++-common/cilk-plus/AN/builtin_fn_mutating.c b/gcc/testsuite/c-c++-common/cilk-plus/AN/builtin_fn_mutating.c index 6635565..7c194c2 100644 --- a/gcc/testsuite/c-c++-common/cilk-plus/AN/builtin_fn_mutating.c +++ b/gcc/testsuite/c-c++-common/cilk-plus/AN/builtin_fn_mutating.c @@ -44,11 +44,11 @@ int main(void) max_value = array3[0] * array4[0]; for (ii = 0; ii < 10; ii++) if (array3[ii] * array4[ii] > max_value) { - max_value = array3[ii] * array4[ii]; max_index = ii; } - + for (ii = 0; ii < 10; ii++) + my_func (&max_value, array3[ii] * array4[ii]); #if HAVE_IO for (ii = 0; ii < 10; ii++)