From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) by sourceware.org (Postfix) with ESMTPS id 6BC313858C27 for ; Wed, 27 Oct 2021 19:45:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6BC313858C27 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1mfor4-0000qS-Tl for fortran@gcc.gnu.org; Wed, 27 Oct 2021 21:44:58 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: fortran@gcc.gnu.org From: Harald Anlauf Subject: Re: [Patch, Fortran] PR 86935: Bad locus in ASSOCIATE statement Date: Wed, 27 Oct 2021 21:44:52 +0200 Message-ID: References: <9F1BA124-0E74-496E-9AAC-53C86052CF5F@gmail.com> <20211027194058.2764dfdb@nbbrfq> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 In-Reply-To: <20211027194058.2764dfdb@nbbrfq> Content-Language: en-US Cc: gcc-patches@gcc.gnu.org X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00, FORGED_MUA_MOZILLA, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2021 19:45:02 -0000 Hi Bernhard, Am 27.10.21 um 19:40 schrieb Bernhard Reutner-Fischer via Fortran: > AFAICS current trunk still has this issue. > Any takers? > thanks, can you create a PR tracking this issue? AFAICS PR86935 has been fixed for gcc-9+. Harald > On Sun, 2 Sep 2018 17:16:07 +0200 > Bernhard Reutner-Fischer wrote: > >> i spotted one >> (pre-existing) possible inconsistency that i did overlook back then: >> >> gfc_match_associate () reads >> ... >> if (gfc_match (" %e", &newAssoc->target) != MATCH_YES) >> { >> /* Have another go, allowing for procedure pointer selectors. */ >> gfc_matching_procptr_assignment = 1; >> if (gfc_match (" %e", &newAssoc->target) != MATCH_YES) >> { >> gfc_error ("Invalid association target at %C"); >> goto assocListError; >> } >> gfc_matching_procptr_assignment = 0; >> } >> >> i.e. we retry a match, but in the second attempt we turn on procptr >> assignment matching and if that works, we turn procptr assignment >> matching off again. >> But if we fail that retry, we forget to turn it off again. >> I suppose we should: >> >> $ svn diff -x -p gcc/fortran/match.c >> Index: gcc/fortran/match.c >> =================================================================== >> --- gcc/fortran/match.c (revision 264040) >> +++ gcc/fortran/match.c (working copy) >> @@ -1898,13 +1898,16 @@ gfc_match_associate (void) >> if (gfc_match (" %e", &newAssoc->target) != MATCH_YES) >> { >> /* Have another go, allowing for procedure pointer selectors. */ >> + match m; >> + >> gfc_matching_procptr_assignment = 1; >> - if (gfc_match (" %e", &newAssoc->target) != MATCH_YES) >> + m = gfc_match (" %e", &newAssoc->target); >> + gfc_matching_procptr_assignment = 0; >> + if (m != MATCH_YES) >> { >> gfc_error ("Invalid association target at %C"); >> goto assocListError; >> } >> - gfc_matching_procptr_assignment = 0; >> } >> newAssoc->where = gfc_current_locus; >> >> >> Untested. Maybe someone wants to give it a whirl... >> If it wrecks havoc then leaving it set deliberately deserves at least a comment. >> >> PS: It would be nice to get rid of gfc_matching_procptr_assignment, >> gfc_matching_ptr_assignment, gfc_matching_prefix, FWIW. >> cheers, >>> >>> Thanks everyone! >>> >>> Cheers, >>> Janus > >