From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104417 invoked by alias); 24 Jun 2016 15:53:38 -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 104396 invoked by uid 89); 24 Jun 2016 15:53:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 24 Jun 2016 15:53:30 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 380E064095; Fri, 24 Jun 2016 15:53:29 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-51.ams2.redhat.com [10.36.116.51]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5OFrRc2018751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 24 Jun 2016 11:53:28 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id u5OFrPvV018682; Fri, 24 Jun 2016 17:53:25 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id u5OFrMMP018681; Fri, 24 Jun 2016 17:53:22 +0200 Date: Fri, 24 Jun 2016 15:53:00 -0000 From: Jakub Jelinek To: Cesar Philippidis Cc: gcc-patches@gcc.gnu.org, Fortran List Subject: Re: OpenACC wait clause Message-ID: <20160624155322.GD7387@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20160607111307.GQ7387@tucnak.redhat.com> <5756E1B6.605@codesourcery.com> <20160607150252.GS7387@tucnak.redhat.com> <57636CF5.40400@codesourcery.com> <20160617143438.GB7387@tucnak.redhat.com> <576D54F9.9030008@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <576D54F9.9030008@codesourcery.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2016-06/txt/msg00089.txt.bz2 On Fri, Jun 24, 2016 at 08:42:49AM -0700, Cesar Philippidis wrote: > >> @@ -1328,7 +1328,8 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, uint64_t mask, > >> && gfc_match ("wait") == MATCH_YES) > >> { > >> c->wait = true; > >> - match_oacc_expr_list (" (", &c->wait_list, false); > >> + if (match_oacc_expr_list (" (", &c->wait_list, false) == MATCH_NO) > >> + needs_space = true; > >> continue; > >> } > >> if ((mask & OMP_CLAUSE_WORKER) > > > > I think it is still problematic. Most of the parsing fortran FE errors are deferred, > > meaning that if you don't reject the whole gfc_match_omp_clauses, then no > > diagnostics is actually emitted. > > What exactly is the problem here? Do you want more precise errors or do > you want to keep the errors generic and deferred? The problem is that if you ignore MATCH_ERROR and don't reject the stmt, then invalid source will be accepted, which is not acceptable. I admit the Fortran OpenMP/OpenACC error recovery and diagnostics is not very good, but it generally follows the model done elsewhere in the Fortran FE. So, I think before changing anything substantial first the bugs in there (where MATCH_ERROR is ignored) should be fixed (something that can be also backported), and only afterwards we should be discussing some plan to improve the infrastructure (like for clauses if there are any non-fatal errors in the parsing emit the diagnostics immediately, don't add the clauses to the FE IL and don't reject the whole stmt). Jakub