From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127410 invoked by alias); 20 May 2015 08:43:37 -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 127399 invoked by uid 89); 20 May 2015 08:43:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 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; Wed, 20 May 2015 08:43:36 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t4K8hWgc004151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 20 May 2015 04:43:33 -0400 Received: from tucnak.zalov.cz (ovpn-116-89.ams2.redhat.com [10.36.116.89]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4K8hUrJ015361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 20 May 2015 04:43:32 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id t4K8hT6m014525; Wed, 20 May 2015 10:43:29 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id t4K8hR83014523; Wed, 20 May 2015 10:43:27 +0200 Date: Wed, 20 May 2015 08:56:00 -0000 From: Jakub Jelinek To: Thomas Schwinge Cc: Cesar Philippidis , "gcc-patches@gcc.gnu.org" Subject: Re: [patch,gomp4] error on invalid acc loop clauses Message-ID: <20150520084327.GB1751@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <5556368D.7010904@codesourcery.com> <87mw0zirnq.fsf@schwinge.name> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87mw0zirnq.fsf@schwinge.name> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg01790.txt.bz2 On Wed, May 20, 2015 at 10:23:21AM +0200, Thomas Schwinge wrote: > > + if (gwv && auto_clause) > > + c_parser_error (parser, "incompatible use of clause %"); > > + else if (gwv && seq_clause) > > + c_parser_error (parser, "incompatible use of clause %"); > > + else if (auto_clause && seq_clause) > > + c_parser_error (parser, "incompatible use of clause % and %"); > > + > > block = c_begin_compound_stmt (true); > > stmt = c_parser_omp_for_loop (loc, parser, OACC_LOOP, clauses, NULL); > > block = c_end_compound_stmt (loc, block, true); > > I would have expected such checking to be done in c_omp_finish_clauses -- > But maybe it's also OK to do it here, given that the loop construct is > the only one where these clauses can appear. Jakub, any strong > preference? In the C FE, it is kind of arbitrary, some checks are done during parsing immediately, others are done in c_omp_finish_clauses. In the C++ FE, obviously more care on where things are diagnosed is needed, so many more checks are done in finish_omp_clauses, because we might want to wait until templates are instantiated. > > ..., and this: why not do such nesting checking in > gcc/omp-low.c:check_omp_nesting_restrictions? Currently (changed by > Bernd in internal r442824, 2014-11-29) we're allowing all > OpenACC-inside-OpenACC nesting -- shouldn't that be changed instead of > repeating the checks in every front end (Jakub?)? Yeah, testing nesting restrictions should be done in omp-low.c if possible. Adding ugly hacks to the FEs tracking the current state and duplicating across all 3 FEs is undesirable. Note, in C++ FE we already have sk_omp so some kind of OpenMP binding scope, but I think we don't have anything similar in the C FE. > I see that some checking is also being done gcc/omp-low.c:scan_omp_for: > »gang, worker and vector may occur only once in a loop nest«, and »gang, > worker and vector must occur in this order in a loop nest«. Don't know > if that conceptually also belongs into > gcc/omp-low.c:check_omp_nesting_restrictions? Doesn't look like anything related to construct/region nesting... Jakub