From patchwork Mon Jun 10 17:19:36 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: 250321 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 940F22C0095 for ; Tue, 11 Jun 2013 03:19:52 +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=g6cM2l3MsyIOdUOF M4Hmhv9uGRQeqelaszwfjb0yY7E6kG+oJ1y6u7LcPtKjJQXjKTyPJRJy0is96eM5 +ccex/CDXSoTZc2ilv6/eE7s6bxyb0POZim5KHyMZFwWFjK2Qsv0eab9fmxrAkdQ voLy7ZX0hgfg1xN+m3/jRyyixqY= 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=v1IfMBS2Jo9Pbbgppnfgdu XoSJQ=; b=mUgZ/CPwnuuMUaSjnJYdrBCuatSx3a4ZE1UHxMWYxsmRTNDqcSSyOv 9IUXdemOV2/PqLqD52jPvQxfo9DEuqo3Y368OEgcN1Y6/aQ4nKxXIy/GhHCQ0WEM NUqp4AzxVGfUIZf0OhoVdAlaa9hAkYSU/kWepTm52dls+g4xaWeG4= 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-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 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:36 +0000 Message-ID: References: In-Reply-To: MIME-Version: 1.0 X-Virus-Found: No > -----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 > > On Mon, 10 Jun 2013, Iyer, Balaji V wrote: > > > > You don't say what the actual error was, and neither does the original 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 inserting 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? > > A cast still doesn't make sense conceptually. Could you give a more detailed > analysis of what the trees look like at this point where you are inserting this cast, > and how you get to a mismatch? > > EXCESS_PRECISION_EXPR can be thought of as a conversion operator. It should > 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; that'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 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: 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 bug in how we check __sec_reduce_mutating function's result. 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 index b1040da..9298ae0 100644 --- a/gcc/c/c-array-notation.c +++ b/gcc/c/c-array-notation.c @@ -158,10 +158,13 @@ fix_builtin_array_notation_fn (tree an_builtin_fn, tree *new_var) 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++)