From patchwork Fri Jan 11 19:46:46 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 211413 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]) by ozlabs.org (Postfix) with SMTP id 3392C2C0348 for ; Sat, 12 Jan 2013 06:47:21 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1358538442; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Date:From:To:Cc:Subject:Message-ID:Reply-To: MIME-Version:Content-Type:Content-Disposition:User-Agent: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=K1xX51Q5nCvFcsjSPVIq tgVc+zg=; b=ZaEGvzqG2UjgjUjpUzmjuf0+rhsvwOsHPois8Nlh2De/TkruqeIA EooFqTJegXkuwlti2kCQLaTm1NYJrJjIIswasJL+Q/VAB/V8yv33WKTBcLEoYwLW NmPowPxav+BaqUW1AKDWyZfPprwdgLI96PhVoayPpCw6raLTVve9y/Y= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:MIME-Version:Content-Type:Content-Disposition:User-Agent:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=DGL2uLyd+kuf+BKA0BK0hBY1O371tBcAkTXkQg60+hCeSEi0+BnswXtJML4241 nuy1AxuH7j0SJDBzZLp5iN1KS9/GTrwxZN8DNNH2k5i4cO2suNzR1bykwkxws96N dWuhj4iHoP6mgAh5lHqHo2qV0CmqYZ/HGLfgXn1ruO7M4=; Received: (qmail 21827 invoked by alias); 11 Jan 2013 19:47:10 -0000 Received: (qmail 21747 invoked by uid 22791); 11 Jan 2013 19:47:09 -0000 X-SWARE-Spam-Status: No, hits=-6.4 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, RCVD_IN_DNSWL_HI, RCVD_IN_HOSTKARMA_W, RP_MATCHES_RCVD, SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 11 Jan 2013 19:46:52 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r0BJkoSQ026135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Jan 2013 14:46:50 -0500 Received: from zalov.redhat.com (vpn1-5-128.ams2.redhat.com [10.36.5.128]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r0BJkmll007715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jan 2013 14:46:50 -0500 Received: from zalov.cz (localhost [127.0.0.1]) by zalov.redhat.com (8.14.5/8.14.5) with ESMTP id r0BJklQh011730; Fri, 11 Jan 2013 20:46:48 +0100 Received: (from jakub@localhost) by zalov.cz (8.14.5/8.14.5/Submit) id r0BJklY0011729; Fri, 11 Jan 2013 20:46:47 +0100 Date: Fri, 11 Jan 2013 20:46:46 +0100 From: Jakub Jelinek To: Richard Biener , fortran@gcc.gnu.org Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] Avoid invalid sharing of ADDR_EXPRs (PR fortran/55935) Message-ID: <20130111194646.GH7269@tucnak.redhat.com> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes 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 Hi! As discussed in the PR, the extra verification of location blocks Richard posted recently fails on some Fortran testcases. The problem is that ADDR_EXPRs in static const var initializers contain locations (fixed by the trans-expr.c hunks), and that gimple-fold makes the ADDR_EXPRs shared, so even with the fortran FE hunks alone when the gimplifier sets location we get invalid blocks anyway. In the PR we were discussing putting the unshare_expr at the beginning of canonicalize_constructor_val, unfortunately that breaks Ada bootstrap, because it is undesirable when record_reference calls that function. So this alternative patch moves the unshare_expr calls to gimple-fold.c canonicalize_constructor_val callers. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? Alternatively the get_symbol_constant_value unshare_expr call could move from canonicalize_constructor_val argument to return val; line, both locations have some advantages and disadvantages (the one in patch might create unnecessary garbage if canonicalize_constructor_val returns NULL or non-min_invariant, the other way would create garbage with the trees created by canonicalize_constructor_val itself (they would be created and immediately unshared). 2013-01-11 Jakub Jelinek PR fortran/55935 * gimple-fold.c (get_symbol_constant_value): Call unshare_expr. (fold_gimple_assign): Don't call unshare_expr here. (fold_ctor_reference): Call unshare_expr. * trans-expr.c (gfc_conv_structure): Call unshare_expr_without_location on the ctor elements. Jakub --- gcc/gimple-fold.c.jj 2013-01-11 09:02:55.000000000 +0100 +++ gcc/gimple-fold.c 2013-01-11 15:42:52.485630537 +0100 @@ -202,7 +202,7 @@ get_symbol_constant_value (tree sym) tree val = DECL_INITIAL (sym); if (val) { - val = canonicalize_constructor_val (val, sym); + val = canonicalize_constructor_val (unshare_expr (val), sym); if (val && is_gimple_min_invariant (val)) return val; else @@ -378,7 +378,7 @@ fold_gimple_assign (gimple_stmt_iterator } else if (DECL_P (rhs)) - return unshare_expr (get_symbol_constant_value (rhs)); + return get_symbol_constant_value (rhs); /* If we couldn't fold the RHS, hand over to the generic fold routines. */ @@ -2941,7 +2941,7 @@ fold_ctor_reference (tree type, tree cto /* We found the field with exact match. */ if (useless_type_conversion_p (type, TREE_TYPE (ctor)) && !offset) - return canonicalize_constructor_val (ctor, from_decl); + return canonicalize_constructor_val (unshare_expr (ctor), from_decl); /* We are at the end of walk, see if we can view convert the result. */ @@ -2950,7 +2950,7 @@ fold_ctor_reference (tree type, tree cto && operand_equal_p (TYPE_SIZE (type), TYPE_SIZE (TREE_TYPE (ctor)), 0)) { - ret = canonicalize_constructor_val (ctor, from_decl); + ret = canonicalize_constructor_val (unshare_expr (ctor), from_decl); ret = fold_unary (VIEW_CONVERT_EXPR, type, ret); if (ret) STRIP_NOPS (ret); --- gcc/fortran/trans-expr.c.jj 2013-01-11 09:02:50.000000000 +0100 +++ gcc/fortran/trans-expr.c 2013-01-11 10:43:54.071921147 +0100 @@ -6137,6 +6137,7 @@ gfc_conv_structure (gfc_se * se, gfc_exp gfc_symbol *vtabs; vtabs = cm->initializer->symtree->n.sym; vtab = gfc_build_addr_expr (NULL_TREE, gfc_get_symbol_decl (vtabs)); + vtab = unshare_expr_without_location (vtab); CONSTRUCTOR_APPEND_ELT (v, cm->backend_decl, vtab); } else if (cm->ts.u.derived && strcmp (cm->name, "_size") == 0) @@ -6150,6 +6151,7 @@ gfc_conv_structure (gfc_se * se, gfc_exp TREE_TYPE (cm->backend_decl), cm->attr.dimension, cm->attr.pointer, cm->attr.proc_pointer); + val = unshare_expr_without_location (val); /* Append it to the constructor list. */ CONSTRUCTOR_APPEND_ELT (v, cm->backend_decl, val);