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 C267A384B07D for ; Mon, 6 Jun 2022 13:19:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C267A384B07D 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.91,280,1647331200"; d="scan'208";a="76726692" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa3.mentor.iphmx.com with ESMTP; 06 Jun 2022 05:19:33 -0800 IronPort-SDR: G0ambwgZdV4yUSkB+kNJjZHVOt8AiDSGeuzP5My75xynvhR+9YBPVh7C/FBVYt4oV/+KpWQNlF dZt3WpGTAcR6UH+O+D7nkSO3h3pQfdvH9U8/pgBe1BBxHivDZ4GaoFcsvmjy2NFjdDXnSZkFGs yDbY3gFhTuaxoid5YghAjUta31fflA7y7DW+D8GREINx8WGlrWZM44GXL06ah0W0m8Jk8lzz8p pHx8afcTCQYv7RgCr+Xi3AGd5BA7mK8DxroIZamMtGMa4sD024nE4ey0/LL0fdVooPR3+UzZoq MtU= Message-ID: <58c6df9a-467a-1dc3-9386-b44af5515894@codesourcery.com> Date: Mon, 6 Jun 2022 21:19:18 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH, OpenMP, v2] Implement uses_allocators clause for target regions Content-Language: en-US To: Jakub Jelinek , Tobias Burnus , gcc-patches , Hafiz Abid Qadeer , Andrew Stubbs References: <46d77e14-080c-db6c-4032-e12899c5d059@codesourcery.com> <9c0945fa-1054-095e-86ae-a9d8dd1ab625@codesourcery.com> From: Chung-Lin Tang In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: svr-orw-mbx-08.mgc.mentorg.com (147.34.90.208) To svr-orw-mbx-10.mgc.mentorg.com (147.34.90.210) X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2022 13:19:35 -0000 On 2022/5/31 6:02 PM, Jakub Jelinek wrote: > 5) for C++, we should handle FIELD_DECLs, but it shouldn't be hard, just > look how it is handled for private too > > Jakub About private() for non-static members, is it really working right now? A simple test: struct C { omp_allocator_handle_t a; void foo (void) { #pragma omp target private (a) a = (omp_allocator_handle_t) 0; } }; int main (void) { C c; c.foo (); return 0; } After C++ front-end processing we get: { omp_allocator_handle_t D.2823 [value-expr: ((struct C *) this)->a]; #pragma omp target private(D.2823) { { <>>>>; } } } The OMP field privatization seems to be doing something here. However gimplify turns this into: void C::foo (struct C * const this) { omp_allocator_handle_t a [value-expr: ((struct C *) this)->a]; #pragma omp target num_teams(1) thread_limit(0) private(a) \ map(alloc:MEM[(char *)this] [len: 0]) map(firstprivate:this [pointer assign, bias: 0]) { this->a = 0; } } This doesn't look quite right for private clause. I don't quite expect a zero-length mapping of this[:0], nor reverting the gimple to use "this->a" for a private copy. Chung-Lin