From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71555 invoked by alias); 18 Dec 2018 13:06:22 -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 71083 invoked by uid 89); 18 Dec 2018 13:06:21 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=tackle, ort 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 ESMTP; Tue, 18 Dec 2018 13:06:19 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7A23B85541; Tue, 18 Dec 2018 13:06:18 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-117-214.ams2.redhat.com [10.36.117.214]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DF011600C9; Tue, 18 Dec 2018 13:06:17 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id wBID6FZT016093; Tue, 18 Dec 2018 14:06:15 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id wBID6Dc5016092; Tue, 18 Dec 2018 14:06:13 +0100 Date: Tue, 18 Dec 2018 13:06:00 -0000 From: Jakub Jelinek To: Julian Brown Cc: Cesar Philippidis , "gcc-patches@gcc.gnu.org" , Tom de Vries , Fortran List Subject: Re: [patch] various OpenACC reduction enhancements - FE changes Message-ID: <20181218130613.GM23305@tucnak> Reply-To: Jakub Jelinek References: <20181204125724.GL12380@tucnak> <20181213141131.0a5b65c1@squid.athome> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181213141131.0a5b65c1@squid.athome> User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg01299.txt.bz2 On Thu, Dec 13, 2018 at 02:11:31PM +0000, Julian Brown wrote: > > Any reason for the above (ditto in C), rather than just adding > > && ort != C_ORT_ACC to the while loop condition for CPP_OPEN_SQUARE? > > (, . or * after id-expression is like any other unhandled > > characters... > > I think the reason was that 'decl' ('t' in the C version) is not set to > error_mark_node if the while loop is skipped, and then the gimplifier > gets confused. I've tried to tackle this in another way, by checking > there aren't any stray characters before the next comma or > close-parenthesis. > > I'm not sure if you were objecting to the error message too -- with the > current patch, the user will just get e.g.: > > error: expected ')' before '.' token > > if they try to use an unsupported type of construct as a reduction > target. > @@ -12004,7 +12005,8 @@ c_parser_omp_variable_list (c_parser *parser, > case OMP_CLAUSE_REDUCTION: > case OMP_CLAUSE_IN_REDUCTION: > case OMP_CLAUSE_TASK_REDUCTION: > - while (c_parser_next_token_is (parser, CPP_OPEN_SQUARE)) > + while (ort != C_ORT_ACC > + && c_parser_next_token_is (parser, CPP_OPEN_SQUARE)) > { > tree low_bound = NULL_TREE, length = NULL_TREE; > > @@ -12074,6 +12076,10 @@ c_parser_omp_variable_list (c_parser *parser, > } > } > } > + if (ort == C_ORT_ACC > + && c_parser_next_token_is_not (parser, CPP_COMMA) > + && c_parser_next_token_is_not (parser, CPP_CLOSE_PAREN)) > + t = error_mark_node; > break; > default: > break; I still don't understand this at all, sorry. So, t is guaranteed to be non-error_mark_node before entering this spot. If you have reduction (decl[0]) etc. vs. reduction (decl), why do you care whether it is added to the returned list or not for error recovery? If it is something that causes ICE in the gimplifier, then user could have written just reduction (decl) or reduction (decl, ) and have it added to the list anyway, so the bug would be that it isn't diagnosed as something incorrect in c_finish_omp_clauses (or whatever the problem with it is). If there is any kind of garbage after the decl, it will just return to the caller at that point and the caller should do the error recovery, the same for reduction (decl[0]) as well as for reduction (decl, [0]). Jakub