From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30477 invoked by alias); 25 Oct 2018 19:12:53 -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 30461 invoked by uid 89); 25 Oct 2018 19:12:53 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=locate, UD:index.htm, indexhtm, index.htm X-HELO: mail-qk1-f195.google.com Received: from mail-qk1-f195.google.com (HELO mail-qk1-f195.google.com) (209.85.222.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 25 Oct 2018 19:12:51 +0000 Received: by mail-qk1-f195.google.com with SMTP id o89so6452265qko.0 for ; Thu, 25 Oct 2018 12:12:51 -0700 (PDT) Return-Path: Received: from [192.168.1.132] (209-6-216-142.s141.c3-0.smr-cbr1.sbo-smr.ma.cable.rcncustomer.com. [209.6.216.142]) by smtp.gmail.com with ESMTPSA id 46-v6sm7385212qtv.73.2018.10.25.12.12.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Oct 2018 12:12:49 -0700 (PDT) Subject: Re: [PATCH, OpenACC] Support C++ "this" in OpenACC directives (PR66053) To: Julian Brown , Jakub Jelinek Cc: Nathan Sidwell , gcc-patches List , "Joseph S. Myers" References: <20180830153134.544d4bef@squid.athome> <96042fb6-3ab5-1f4c-47e7-9940ebe212e1@acm.org> <20180831142008.GS2218@tucnak> <20180903195021.1fd65130@squid.athome> From: Jason Merrill Message-ID: <63071709-ee60-3880-7d43-c510c3d09939@redhat.com> Date: Thu, 25 Oct 2018 20:08:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20180903195021.1fd65130@squid.athome> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-10/txt/msg01623.txt.bz2 On 9/3/18 7:50 PM, Julian Brown wrote: > On Fri, 31 Aug 2018 16:20:08 +0200 > Jakub Jelinek wrote: > >> On Fri, Aug 31, 2018 at 10:04:07AM -0400, Nathan Sidwell wrote: >>> On 08/30/2018 04:27 PM, Jason Merrill wrote: >>> >>>> On Thu, Aug 30, 2018 at 3:31 PM, Julian Brown >>>> wrote: >>>>> "Apart from parsing, it's necessary to prevent the "cannot take >>>>> the address of 'this', which is an rvalue expression" error >>>>> from appearing >>> >>> Breaking a rather fundamental language attribute does not seem wise. >>> >>>> Why does referring to this[0:1] require making 'this' addressable? >>>> Surely what we're interested in is the value of 'this', not the >>>> address. >>> Yes, transferring the this pointer is very unlikely to be what the >>> user wants -- the object being referred to contains the data. It >>> might be wise to look at the DR's and changes relating to lambdas >>> and this capture. Those changes now make it much harder to simply >>> capture the pointer unintentionally. >> >> Yeah, I agree we shouldn't try to make this addressable. >> Does OpenACC try to map the base of the array section (rather than >> what e.g. OpenMP does, privatize the pointer base instead and assign >> the pointer the new value inside of the region)? >> Even if it is mapped, can't it be mapped by taking an address of a >> temporary initialized from this? > > For OpenACC, two mappings are created for an array section: one for the > data (to, from, tofrom, etc.) and a firstprivate pointer with a bias to > locate the (possibly virtual) zero'th element of the array. I think > that's the same as OpenMP. > > For the test case given, it's sufficient to merely allow "this" to be > used as the base pointer for an array section. That usage doesn't > require "this" to be made addressable. > > The this[0:1] syntax is accepted by PGI > (https://www.pgroup.com/resources/docs/18.4/x86/openacc-gs/index.htm, > 2.4 C++ Classes in OpenACC) -- in order to copy "the class itself" to > the accelerator. > > Referring to class member variables in OpenACC clauses (as the example > in that section does also) is still problematic in GCC, though. > > PGI also allows the user to specify just "this" in OpenACC clauses, > which presumably does the same thing as specifying this[0:1]. For PGI, > but not for OpenACC <= 2.5, that seems to follow a general case for > pointers to structs (2.3. C Structs in OpenACC), "A pointer to a scalar > struct is treated as a one-element array, and should be shaped as > r[0:1]". That's notably different from OpenMP 4.5, which treats plain > mapped pointers as zero-length array sections, and also differs from > the current behaviour of GCC (which bizarrely, IIUC, is to copy the > bits of the host pointer verbatim to the target). OpenACC 2.5 arguably > leaves the behaviour unspecified for pointers without an explicit array > section. > > The attached patch allows basic class-wrapping-an-array kinds of > usages, anyway. Re-tested with offloading to nvptx and bootstrapped. OK > to apply? > > Thanks, > > Julian > > 2018-09-03 Joseph Myers > Julian Brown > > PR C++/66053 > > * semantics.c (handle_omp_array_sections_1): Allow array > sections with "this" pointer for OpenACC. > OK. Jason