From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id 04D12389043A; Thu, 4 Jun 2020 13:58:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 04D12389043A 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: Nx9ZBMkBSHIRfCdsDfJjmzuidT2GExmyk0W3IZchJIQU4FJLjGNah0aUdNAZMcIu0JRCkObOBC EM2VOfCUEbk2xZZBzAPPtbad3uxjiE5GTiCgBs87/cZ/VA8DbYYdqNPcqyCnBvTsbq517qdF/w 8GQxAZdb8xCUFjaeudebHHzjNGVVYyQ3oW76Ho6i+RhLj+DLE9hLa4q5h8GYMAdXZ1uF88dVKJ RBmN+2ZhBXQGAUWdyOtDpLPu/IkKDX0GXm+05BY8TwEG4lCduysl1bvzjPsjrYcWiOYivKaSoD rNA= X-IronPort-AV: E=Sophos;i="5.73,472,1583222400"; d="scan'208";a="49459256" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa2.mentor.iphmx.com with ESMTP; 04 Jun 2020 05:58:23 -0800 IronPort-SDR: bBx2fvD/1NOAgKe3l0kviBl1KNl6k5hUx8+K/YfycAtYUWMva/X5e8xvNLFFlh1kKEPcmyzDyT N/09XHFS1wdgwBRDH4Vw3idPbzVXZVhBibNziC487Qz6OYd6Mv0AFs4Tqr/Ycg/Uj2ZrXcRI6D oQe0wpO1wpEhw5UVavK47D6zRuqGt4jBD7fyXmYgvORxxq6DU+wIpph37Hr9gnaM6+JzWOK+pY 5gbyxn0RGm/aUilwiCCk+2JJfMuXkwMsjvsdNjKiNFrBJvq4hL4lkXyr9c1eQHQDv1meP/iJsw DLY= Date: Thu, 4 Jun 2020 14:58:14 +0100 From: Julian Brown To: Thomas Schwinge CC: , , Jakub Jelinek , Tobias Burnus Subject: Re: [PATCH] Fix component mappings with derived types for OpenACC Message-ID: <20200604145814.49e14a48@squid.athome> In-Reply-To: <87ftbw9kqh.fsf@euler.schwinge.homeip.net> References: <20200110014945.5643ace5@squid.athome> <20200128134100.59084c89@squid.athome> <87ftbw9kqh.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="UTF-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-03.mgc.mentorg.com (139.181.222.3) To SVR-IES-MBX-04.mgc.mentorg.com (139.181.222.4) X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Thu, 04 Jun 2020 13:58:28 -0000 On Tue, 19 May 2020 14:23:34 +0200 Thomas Schwinge wrote: > Hi! >=20 > On 2020-01-28T13:41:00+0000, Julian Brown > wrote: > > On Fri, 24 Jan 2020 10:58:49 +0100 > > Tobias Burnus wrote: =20 > >> the gfortran part is rather obvious and it and the test case look > >> fine to me =E2=86=92 OK. > >> The oacc-mem.c also looks okay, but I assume Thomas needs to=20 > >> rubber-stamp it. =20 > > > > I understand that Thomas is unavailable for the time being, so > > won't be able to use his rubber-stamp powers. I added the offending > > libgomp code to start with though, so I think I can go ahead and > > commit the patch. I'll hold off for 24 hours though in case there > > are any objections (Jakub?). =20 >=20 > So, in the end you didn't commit this, and now we've got the > "un-fixed" OpenACC/Fortran code generation in the GCC 10.1 release, > so have to deal with it in one way or another going forward, > regarding libgomp ABI compatibility. (Ideally), we need to make sure > that "un-fixed" GCC 10.1-built executables continue to work "as good > as before" when dynamically linked/running against "fixed" GCC 10.1+ > shared libraries. >=20 > Do we get such desired behavior by the patch quoted below? In > particular: removing the 'GOMP_MAP_STRUCT' handling code, but leaving > in the empty 'case GOMP_MAP_STRUCT:' as a no-op, so that we don't run > into 'default:' case 'goacc_exit_data_internal UNHANDLED kind'? Is > that sufficient? >=20 > Is my understanding correct that "fixed" GCC won't generate such > 'GOMP_MAP_STRUCT' anymore (I have't studied in detail), and this empty > 'case GOMP_MAP_STRUCT:' only remains in here for backwards > compatibility? In this case, please add a comment to the code, > stating this. Otherwise, please add a comment why "do nothing" is > appropriate for 'GOMP_MAP_STRUCT'. In particular, for both > scenarios, why we don't need to skip the following 'sizes[i]' > mappings? I'm not sure if I got the threading right, but I've now followed up on this discussion here: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547300.html Thanks, Julian