From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 1D32F3834C2C; Wed, 7 Dec 2022 15:17:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1D32F3834C2C 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.96,225,1665475200"; d="scan'208";a="88833367" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa4.mentor.iphmx.com with ESMTP; 07 Dec 2022 07:17:09 -0800 IronPort-SDR: ZqlMXinjdbAPi9TFiVaKCSPXtw69jEczsx8yRMoGGePUKgtSvzNv00uwKhftFsTZrFo/5QKSBl 7SZpjwpvWauWi+QrErnl6fUnmHn6jvj3QnplsqDs5l+nxmPbfTv5XFxlxNf6IC1rvWxW3QkqAW sYMObLn13ilsHNtecY2TzNFqqYecshYKcRCWgXsl4e2bfCNwIfonq0Y/zSDVYalgCQ3P1uccQT /EKwc3ZFHBQTufSHxLnMtiP50mDojgj+XdgZUpsbUb1Fj0TROVlRBoM1F/pmGcmXXSaRfSa5Ea wfI= Date: Wed, 7 Dec 2022 15:16:57 +0000 From: Julian Brown To: Tobias Burnus CC: , , Jakub Jelinek , Chung-Lin Tang Subject: Re: [PATCH v5 2/4] OpenMP/OpenACC: Rework clause expansion and nested struct handling Message-ID: <20221207151657.7340469c@squid.athome> In-Reply-To: <65824aa6-be83-3c74-871e-6571008f2d25@codesourcery.com> References: <8fcf3df1b40ea77cbb8088962cbcdf6935d2ded3.1666088224.git.julian@codesourcery.com> <65824aa6-be83-3c74-871e-6571008f2d25@codesourcery.com> 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-13.mgc.mentorg.com (147.34.90.213) To svr-ies-mbx-11.mgc.mentorg.com (139.181.222.11) X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,KAM_SHORT,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, 7 Dec 2022 15:54:42 +0100 Tobias Burnus wrote: > Hi Julian, > > If I understand Deepak's comment (on OpenMP.org's omp-lang list, sorry > it is a nonpublic list) correctly, the following wording implies that > a 'from: s.w[z:4]' for a pointer 's.w' also implies a mapping of > 's.w' - if 's' is used inside the target region and, thus, gets > implicitly mapped. > > [TR11 157:21-26] (approx. [5.2 154:22-27], [5.1 352:17-22], [5.0 > 320:22-27]) > > "If a list item with an implicit data-mapping attribute does not have > any corresponding storage in the device data environment prior to a > task encountering the construct associated with the map clause, and > one or more contiguous parts of the original storage are either list > items or base pointers to list items that are explicitly mapped on > the construct, only those parts of the original storage will have > corresponding storage in the device data environment as a result of > the map clauses on the construct." Hmmm... IIRC that is a different conclusion than the one we have understood previously, leading to e.g. the patch here (Chung-Lin CC'ed): https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570075.html Follow-on discussion then questioned whether the change was really the intention of the spec, but we thought it was. Has that changed now? (I think actually changing the behaviour is a matter of flipping a switch, but let's make sure we choose the right setting!) Thanks, Julian