From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2975 invoked by alias); 29 Apr 2016 08:15:49 -0000 Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: fortran-owner@gcc.gnu.org Received: (qmail 2945 invoked by uid 89); 29 Apr 2016 08:15:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_00,KAM_ASCII_DIVIDERS,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=HX-Envelope-From:sk:ebotcaz, H*F:U*ebotcazou, magnitude, HContent-Transfer-Encoding:7Bit X-Spam-User: qpsmtpd, 2 recipients X-HELO: smtp.eu.adacore.com Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 29 Apr 2016 08:15:47 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 88EAC814AD; Fri, 29 Apr 2016 10:15:44 +0200 (CEST) Received: from smtp.eu.adacore.com ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROf8MUNXetBc; Fri, 29 Apr 2016 10:15:44 +0200 (CEST) Received: from polaris.localnet (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id 421EA814AC; Fri, 29 Apr 2016 10:15:44 +0200 (CEST) From: Eric Botcazou To: Richard Biener Cc: gcc-patches@gcc.gnu.org, jason@redhat.com, fortran@gcc.gnu.org Subject: Re: [PATCH] Fix type field walking in gimplifier unsharing Date: Fri, 29 Apr 2016 08:15:00 -0000 Message-ID: <1996638.VYKIi6TYiV@polaris> User-Agent: KMail/4.14.10 (Linux/3.16.7-35-desktop; KDE/4.14.9; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-SW-Source: 2016-04/txt/msg00068.txt.bz2 > The following works (for the testcase): > > Index: gcc/cp/decl.c > =================================================================== > --- gcc/cp/decl.c (revision 235547) > +++ gcc/cp/decl.c (working copy) > @@ -10393,8 +10393,11 @@ grokdeclarator (const cp_declarator *dec > && (decl_context == NORMAL || decl_context == FIELD) > && at_function_scope_p () > && variably_modified_type_p (type, NULL_TREE)) > - /* Force evaluation of the SAVE_EXPR. */ > - finish_expr_stmt (TYPE_SIZE (type)); > + { > + TYPE_NAME (type) = build_decl (UNKNOWN_LOCATION, TYPE_DECL, > + NULL_TREE, type); > + add_decl_expr (TYPE_NAME (type)); > + } > > if (declarator->kind == cdk_reference) > { > > and I have a similar fix for the Fortran FE for one testcase I > reduced to > > character(10), dimension (2) :: implicit_result > character(10), dimension (2) :: source > implicit_result = reallocate_hnv (LEN (source)) > contains > FUNCTION reallocate_hnv(LEN) > CHARACTER(LEN=LEN), DIMENSION(:), POINTER :: reallocate_hnv > END FUNCTION reallocate_hnv > end > > Index: fortran/trans-array.c > =================================================================== > --- fortran/trans-array.c (revision 235547) > +++ fortran/trans-array.c (working copy) > @@ -1094,6 +1094,16 @@ gfc_trans_create_temp_array (stmtblock_t > info->descriptor = desc; > size = gfc_index_one_node; > > + /* Emit a DECL_EXPR for the variable sized array type in > + GFC_TYPE_ARRAY_DATAPTR_TYPE so the gimplification of its type > + sizes works correctly. */ > + tree arraytype = TREE_TYPE (GFC_TYPE_ARRAY_DATAPTR_TYPE (type)); > + if (! TYPE_NAME (arraytype)) > + TYPE_NAME (arraytype) = build_decl (UNKNOWN_LOCATION, TYPE_DECL, > + NULL_TREE, arraytype); > + gfc_add_expr_to_block (pre, build1 (DECL_EXPR, > + arraytype, TYPE_NAME (arraytype))); > + > /* Fill in the array dtype. */ > tmp = gfc_conv_descriptor_dtype (desc); > gfc_add_modify (pre, tmp, gfc_get_dtype (TREE_TYPE (desc))); Great. We do exactly that in the Ada compiler (but of course the number of places where we need to do it is an order of magnitude larger). > I wonder if we can avoid allocating the TYPE_DECL by simply also > allowing TREE_TYPE as operand of a DECL_EXPR (to avoid adding > a 'TYPE_EXPR'). I agree that DECL_EXPR + TYPE_DECL is a bit heavy, but I'm not sure that the benefit would be worth introducing the irregularity in the IL. -- Eric Botcazou