From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id 2E78C3858D39; Wed, 2 Nov 2022 12:20:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2E78C3858D39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.95,232,1661846400"; d="scan'208";a="85753322" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa3.mentor.iphmx.com with ESMTP; 02 Nov 2022 04:20:21 -0800 IronPort-SDR: RNfTU6tq05ormtjJpRprcxKTQ6Ok1ddyaBHWVGrXxn0v7cp1jH0KYcTKwO2LWXLzpfr4cnKK2V PMWOBGIooeJZhcMX28KUf92t24cHjICLY0g4tEZBiYW1Z7HaxZ7oxXNbkXvnWJ4KNF7k34cVkx qt5ST86Wcav1G5z9BdMoodu9/PpGRUAZjcRqSheIkMMUepSoy/7DVZADItCqcKThBWLwdIiGh9 9RTt8vh0ccHT1f/YF/1gLYAos2WLRqoNjqf2lHGxbZLLD4UKmemINEovgyWYpg/8TFJOL3eKCf vSU= Date: Wed, 2 Nov 2022 12:20:11 +0000 From: Julian Brown To: Jakub Jelinek via Fortran CC: Jakub Jelinek , Tobias Burnus , , Thomas Schwinge Subject: Re: [PATCH v2 06/11] OpenMP: lvalue parsing for map clauses (C++) Message-ID: <20221102122011.64e750b8@squid.athome> In-Reply-To: References: <62e4e371468638d2f155c528a5c1e597558a56ac.1647619144.git.julian@codesourcery.com> <20221101215038.08a688e1@squid.athome> Organization: Siemens Embedded X-Mailer: Claws Mail 4.1.1git7 (GTK 3.24.34; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: svr-orw-mbx-12.mgc.mentorg.com (147.34.90.212) To svr-ies-mbx-11.mgc.mentorg.com (139.181.222.11) X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, 2 Nov 2022 12:58:37 +0100 Jakub Jelinek via Fortran wrote: > On Tue, Nov 01, 2022 at 09:50:38PM +0000, Julian Brown wrote: > > > I think we should figure out when we should temporarily disable > > > parser->omp_array_section_p = false; > > > and restore it afterwards to a saved value. E.g. > > > cp_parser_lambda_expression seems like a good candidate, the fact > > > that OpenMP array sections are allowed say in map clause doesn't > > > mean they are allowed inside of lambdas and it would be > > > especially hard when the lambda is defining a separate function > > > and the search for OMP_ARRAY_SECTION probably wouldn't be able to > > > discover those. Other spots to consider might be statement > > > expressions, perhaps type definitions etc. > > > > I've had a go at doing this -- several expression types now forbid > > array-section syntax (see new "bad-array-section-*" tests added). > > I'm afraid my C++ isn't quite up to figuring out how it's possible > > to define a type inside an expression (inside a map clause) if we > > forbid lambdas and statement expressions though -- can you give an > > example? > > But we can't forbid lambdas inside of the map clause expressions, > they are certainly valid in OpenMP, and IMNSHO shouldn't disallow > statement expressions, people might not even know they use a > statement expression, they could just use some standard macro which > uses a statement expression under the hood. Though your testcases > look good. I meant "forbid array sections within lambdas and statement expressions" -- FAOD, does that seem reasonable? Technically it might not be that hard to support e.g. a statement expression with an array section on the final expression, but that doesn't work at the moment. Maybe a follow-on patch could support that if we want it? I'll take a look at addressing your other review comments, thanks! Cheers, Julian