From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51358 invoked by alias); 25 Jun 2019 13:17:48 -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 51342 invoked by uid 89); 25 Jun 2019 13:17:48 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.6 required=5.0 tests=AWL,BAYES_00,KAM_COUK,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.1 spammy=H*i:sk:1cd500c, H*f:sk:1cd500c X-HELO: imap1.codethink.co.uk Received: from imap1.codethink.co.uk (HELO imap1.codethink.co.uk) (176.9.8.82) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 25 Jun 2019 13:17:46 +0000 Received: from [167.98.27.226] (helo=[10.35.6.54]) by imap1.codethink.co.uk with esmtpsa (Exim 4.84_2 #1 (Debian)) id 1hflKQ-0002Ql-7L; Tue, 25 Jun 2019 14:17:42 +0100 Subject: Re: [PATCH] Automatics in equivalence statements To: Jeff Law , Bernhard Reutner-Fischer , Steve Kargl Cc: fortran , gcc-patches References: <01b19cf0-7854-90a7-a2cd-14750dfcf543@codethink.co.uk> <20190621141011.GB49159@troutmask.apl.washington.edu> <20190624101930.7cf804b1@nbbrfq.loc> <1cd500c2-14b6-b758-710a-b95c75c746f9@redhat.com> From: Mark Eggleston Message-ID: <0cc2093c-29f5-1c6b-07c5-c2f931c20674@codethink.co.uk> Date: Tue, 25 Jun 2019 13:17:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <1cd500c2-14b6-b758-710a-b95c75c746f9@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2019-06/txt/msg01551.txt.bz2 On 25/06/2019 00:17, Jeff Law wrote: > On 6/24/19 2:19 AM, Bernhard Reutner-Fischer wrote: >> On Fri, 21 Jun 2019 07:10:11 -0700 >> Steve Kargl wrote: >> >>> On Fri, Jun 21, 2019 at 02:31:51PM +0100, Mark Eggleston wrote: >>>> Currently variables with the AUTOMATIC attribute can not appear in an >>>> EQUIVALENCE statement. However its counterpart, STATIC, can be used in >>>> an EQUIVALENCE statement. >>>> >>>> Where there is a clear conflict in the attributes of variables in an >>>> EQUIVALENCE statement an error message will be issued as is currently >>>> the case. >>>> >>>> If there is no conflict e.g. a variable with a AUTOMATIC attribute and a >>>> variable(s) without attributes all variables in the EQUIVALENCE will >>>> become AUTOMATIC. >>>> >>>> Note: most of this patch was written by Jeff Law >>>> >>>> Please review. >>>> >>>> ChangeLogs: >>>> >>>> gcc/fortran >>>> >>>>     Jeff Law  >>>>     Mark Eggleston  >>>> >>>>     * gfortran.h: Add check_conflict declaration. >>> This is wrong. By convention a routine that is not static >>> has the gfc_ prefix. >>> >> Furthermore doesn't this export indicate that you're committing a >> layering violation somehow? > Possibly. I'm the original author, but my experience in our fortran > front-end is minimal. I fully expected this patch to need some tweaking. > > We certainly don't want to recreate all the checking that's done in > check_conflict. We just need to defer it to a later point -- > find_equivalence seemed like a good point since we've got the full > equivalence list handy and can accumulate the attributes across the > entire list, then check for conflicts. > > If there's a concrete place where you think we should be doing this, I'm > all ears. > Any suggestions will be appreciate. >>>     * symbol.c (check_conflict): Remove automatic in equivalence conflict >>>     check. >>>     * symbol.c (save_symbol): Add check for in equivalence to stop the >>>     the save attribute being added. >>>     * trans-common.c (build_equiv_decl): Add is_auto parameter and >>>     add !is_auto to condition where TREE_STATIC (decl) is set. >>>     * trans-common.c (build_equiv_decl): Add local variable is_auto, >>>     set it true if an atomatic attribute is encountered in the variable >> atomatic? I read atomic but you mean automatic. > Yes. > >>>     list.  Call build_equiv_decl with is_auto as an additional parameter. >>>     flag_dec_format_defaults is enabled. >>>     * trans-common.c (accumulate_equivalence_attributes) : New subroutine. >>>     * trans-common.c (find_equivalence) : New local variable dummy_symbol, >>>     accumulated equivalence attributes from each symbol then check for >>>     conflicts. >> I'm just curious why you don't gfc_copy_attr for the most part of accumulate_equivalence_attributes? >> thanks, > Simply didn't know about it. It could probably significantly simplify > the accumulation of attributes step. Using gfc_copy_attr causes a great many "Duplicate DIMENSION attribute specified at (1)" errors. This is because there is a great deal of checking done instead of simply keeping track of the attributes used which is all that is required for determining whether there is a conflict in the equivalence statement. Also, the final section of accumulate_equivalence_attributes involving SAVE, INTENT and ACCESS look suspect to me. I'll check and update the patch if necessary. > Jeff > > > -- https://www.codethink.co.uk/privacy.html