From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116075 invoked by alias); 2 Sep 2018 15:16:23 -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 116043 invoked by uid 89); 2 Sep 2018 15:16:22 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=allowing, HTo:U*janus, Weil, Koenig X-HELO: mail-oi0-f68.google.com Received: from mail-oi0-f68.google.com (HELO mail-oi0-f68.google.com) (209.85.218.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 02 Sep 2018 15:16:20 +0000 Received: by mail-oi0-f68.google.com with SMTP id y207-v6so29553803oie.13; Sun, 02 Sep 2018 08:16:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JxVJt++B/qsqRNFEbYnC5cgU7j6Y2QTN9dzFqaYJGzk=; b=gIGu+dE+PfjrikK2Nqcms0dikKh0UOsj2bH5oeRiPwi6RqYgT2oR8fOY6pQMAkKfjN 9QcJ1YC2khPSDIAIqoQEKLBuY+MJbKADOVqiM1z7fwXdEd2fC16qlUXnAEyghbKg6Bia MlXNHucaiFUhrotLR0RgywNnHRjDdyZhwwSbG8PG+6sjlqUKt6zF5n3mHgq3V85hCwQ8 /pULgVLNMpVagzwKZnAi5g76Eq3Kubdb58QRrp2IVeMLdLXY90Axkut+uUwnbcqi3r6J LKUIdppgHmdXySySgZRVYpg7UxGwo14rOUKINMI+LWNf3pZclY3Ahz02CBUn+FW/CfQF mDXA== MIME-Version: 1.0 References: <9F1BA124-0E74-496E-9AAC-53C86052CF5F@gmail.com> In-Reply-To: From: Bernhard Reutner-Fischer Date: Sun, 02 Sep 2018 15:16:00 -0000 Message-ID: Subject: Re: [Patch, Fortran] PR 86935: Bad locus in ASSOCIATE statement To: Janus Weil Cc: Thomas Koenig , gfortran , GCC Patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-09/txt/msg00052.txt.bz2 On Wed, 22 Aug 2018 at 21:37, Janus Weil wrote: > > Am Mi., 22. Aug. 2018 um 17:46 Uhr schrieb Thomas Koenig > : > > > > Hi Janus, > > > > >> Janus, > > >> > > >> On 13 August 2018 21:44:47 CEST, Janus Weil wrote: > > >>> Hi all, > > >>> > > >>> this simple patch improves some of the diagnostics for invalid > > >>> ASSOCIATE statements: > > >>> > > >>> https://github.com/janusw/gcc/commit/2f484479c741abddc8ac473cb0c1b9010397e006 > > >> > > >> Please do not send external references but the patch itself for posterity. > > > > > > "git diff pr86935~1 pr86935 > pr86935.diff" > > > See attachment. > > > > The patch is OK; you might want to take Bernhard's remark about > > the trailing space after "%e" into account. > > I have incorporated Bernhard's remark and committed as r263787. While rebasing my fortran-fe-stringpool branch 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