From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id 9F8A73857C41; Fri, 24 Jul 2020 22:53:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9F8A73857C41 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=Julian_Brown@mentor.com IronPort-SDR: XSztJ/er2vQ9KdD4BlmG4Bpd4dnkhxcWQEBCCJ00xCgXwuCADY6roOjF1a9Hwqv9bpmxkzbRPQ 007NzAZjstuoYhzFqkVdGZpmoGw4Z6vuZaqWFOAzgKxLll2KLDFuVnuh+EBGjq4oTVcKqbzC+U vx85hiX+1u/Ua1r2IFmdlhxvBm6Dc4HOqaF/ofRONzURdwC1ZrFvmy7VWTTpqSfMQ10RQYBNIl XBnseFTLAq7bDlO1xbM+b5d/0YkPmSFndrl4US8DfqdPRoX+9oUBditiFCxJHawVSPNyVosQJY fSQ= X-IronPort-AV: E=Sophos;i="5.75,392,1589270400"; d="scan'208";a="53442120" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa1.mentor.iphmx.com with ESMTP; 24 Jul 2020 14:53:30 -0800 IronPort-SDR: YDpcY2H05RlkHlwFFlnvPYK71BzEQxM02iaOhmiNkkDWyeVaVa7VkDNZHUWGoGslXK4fNCgSzl H756PL3yTMnpS17jVVWUH91OFSx4iBdzlFRhhpvzqOm0ZyjIzdblBUF3aMXQHehV09Y1Z4VdIu BuKcDdoC0+AAMskPUzYSkWFT08HTTMCgikdzBCNR8o10XyfbDmTcrdBhkGuxZqE5qKU7caeZ/j 38TSguH2PftOJ8vYscJ7t1/8qmw35Xfgk4OErFiE0hgtN98r+mE/tfusn/TOznG8BeR7VSTv6N LFg= Date: Fri, 24 Jul 2020 23:53:23 +0100 From: Julian Brown To: Thomas Schwinge CC: Jakub Jelinek , Tobias Burnus , , , Subject: Re: [PATCH 9/9] [OpenACC] Don't detach for no-op exit data with zero dynamic refcount Message-ID: <20200724235323.746c9f70@squid.athome> In-Reply-To: <87v9id5745.fsf@euler.schwinge.homeip.net> References: <5309b57f3707783cf65c2b6c5b9b784d8e61b760.1592343757.git.julian@codesourcery.com> <87v9id5745.fsf@euler.schwinge.homeip.net> Organization: Mentor Graphics X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-08.mgc.mentorg.com (139.181.222.8) To SVR-IES-MBX-04.mgc.mentorg.com (139.181.222.4) X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 22:53:33 -0000 On Fri, 24 Jul 2020 16:18:34 +0200 Thomas Schwinge wrote: > Hi Julian! > > On 2020-06-16T15:39:45-0700, Julian Brown > wrote: > > This patch fixes a set of XFAILs > > The overall goal of couse is not to resolve XFAILs, but to implement > the expected behavior. :-) Eh, details :-). > > in some recently-added patches by > > skipping a detach operation on "no-op" exit data operations for > > blocks with zero dynamic refcount. > > So this is one aspect of "OpenACC 2.6 > deep copy: attach/detach API routines: no-op behavior". Not quite, I don't think -- that's about pointers (or pointed-to blocks) that are not mapped on the target. With this patch, we have a detach operation with a block with a zero dynamic refcount, but a non-zero structured refcount -- i.e. it's still mapped. So I think the patch is necessary, but not sufficient for the other cases you mention. > > This takes advantage of the ordering of > > detach clauses with respect to associated data-movement clauses: > > i.e., they are grouped together adjacently. > > I'm not convinced that it's sufficient to just special-case these > cases. Instead, per the OpenACC "Data Clause Actions" etc., shouldn't > basically all 'gomp_fatal's that we have on 'attach'/'detach' code > paths turn into no-ops ("no action is taken")? > > > And I'd then again like to bring forward my idea from another review: > > | we may (rather easily?) add a flag variable (ICV; > | initialized from an environment variable) to guard this checking > | behavior? > > Here: to *keep* the 'gomp_fatal's. > > | I suppose we may now have a few libgomp testcases that > | actually do [check things via expected 'gomp_fatal's], > | which wouldn't work any longer [...]. > > Such testcases could then 'dg-set-target-env-var "GOMP_ATTACH_FATAL" > "1"' (better name is desirable), and have one variant with and one > variant without that enabled. > > > Before you start re-working the patch, let's please first get > agreement on what exactly we intend to achieve. Hm, you are probably right about the no-op behaviour for attach operations (but slightly ugh in terms of usability), but I don't think that's really the problem the patch addresses. As for the user-tweakable checking -- yeah maybe it could work, but I don't think I'm going to have time to work on that at the moment. Sorry! HTH, Julian