From patchwork Mon Feb 13 20:28:15 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Tobias Burnus X-Patchwork-Id: 1741891 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4PFwsL1czmz23h0 for ; Tue, 14 Feb 2023 07:28:37 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1B90A382E68F for ; Mon, 13 Feb 2023 20:28:34 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id ACB8B3858C27 for ; Mon, 13 Feb 2023 20:28:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ACB8B3858C27 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.97,294,1669104000"; d="diff'?scan'208";a="97960437" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa2.mentor.iphmx.com with ESMTP; 13 Feb 2023 12:28:20 -0800 IronPort-SDR: FGFR422gu3SUhgMGrDEwms6rjWN3oU+UYShs18iUT2DdAFtj59IrqyAsKGLSRK2jUByD4o0HQJ LOOyY3d0RMq6X6gnfDf3ui0cJdMrhrwuL3Gl0VUPYMAs3yxD8IUqDd5GTdWTaHQE4sXaaoEAK/ VluwnMAbdK4pHEvanNTKj446dt6hgMlgjAB/VdWpwh97YhaVIb9Okh1htXXDRduTezVyjrPJ4x bnjBziu5NvDOfzRRFZtFP3HYJq+xQ0Px1NuYZZdYNhvNvHU5ZN6h6Ql7D89Hj9iZUURQXBDGu+ XMg= Message-ID: Date: Mon, 13 Feb 2023 21:28:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Content-Language: en-US To: gcc-patches , Jakub Jelinek From: Tobias Burnus Subject: [Patch] libgomp: Fix 'target enter data' with always pointer X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-12.mgc.mentorg.com (139.181.222.12) To svr-ies-mbx-12.mgc.mentorg.com (139.181.222.12) X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_SHORT, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP 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: , Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Sender: "Gcc-patches" The problem is that GOMP_MAP_ALWAYS_POINTER, there is a lookup for "i - 1" but with 'target enter data', GOMP_MAP_ALWAYS_POINTER and its data were passed as separate entities. I am not sure whether there is a legitimate reason to have two GOMP_MAP_ALWAYS_POINTER in a row; the check in gomp_map_vars_internal seems to indicate that there is. Hence, I assumed there is and I add an 'i > 0' check to that function and also a check the kinds[i] isn't an always pointer (if i+ is) in the caller, i.e. GOMP_target_enter_exit_data. Note that there is a front-end/middle-end issue with regards to 'target exit data', which is the reason that the exit data has been commented out. I plan to fix this separately.* (It is a bug of its own - and this fix is to libgomp and the other is to the FE/ME.) OK for mainline? Tobias (*) Part of the 'alloc' issue has been discussed in the patch: https://gcc.gnu.org/pipermail/gcc-patches/2022-November/604887.html however, during discussion on IRC it turned out that this patch is incomplete. This issue is next on my to-do list. PS: Also *pending* *review* is a simple reverse-offload-only patch and one '!$omp loop' "13 Regression" fix (with the review comments fixed): "[v2] OpenMP/Fortran: Fix loop-iter var privatization with !$OMP LOOP [PR108512]" https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611730.html "[Patch] libgomp: Fix reverse-offload for GOMP_MAP_TO_PSET" https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611617.html (Other pending patches: "OpenMP Patch Ping – including "[13 Regression]", https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611524.html ) ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 libgomp: Fix 'target enter data' with always pointer As GOMP_MAP_ALWAYS_POINTER operates on the previous map item, ensure that with 'target enter data' both are passed together to gomp_map_vars_internal. libgomp/ChangeLog: * target.c (gomp_map_vars_internal): Add 'i > 0' before doing a kind check. (GOMP_target_enter_exit_data): If the next map item is GOMP_MAP_ALWAYS_POINTER map it together with the current item. * testsuite/libgomp.fortran/target-enter-data-3.f90: New test. target.c | 17 +++++++++++++---- testsuite/libgomp.fortran/target-enter-data-3.f90 | 22 ++++++++++++++++++++++ 2 files changed, 35 insertions(+), 4 deletions(-) diff --git a/libgomp/target.c b/libgomp/target.c index c1682caea13..cc8db85957c 100644 --- a/libgomp/target.c +++ b/libgomp/target.c @@ -1480,8 +1480,9 @@ gomp_map_vars_internal (struct gomp_device_descr *devicep, gomp_mutex_unlock (&devicep->lock); gomp_fatal ("always pointer not mapped"); } - if ((get_kind (short_mapkind, kinds, i - 1) & typemask) - != GOMP_MAP_ALWAYS_POINTER) + if (i > 0 + && ((get_kind (short_mapkind, kinds, i - 1) & typemask) + != GOMP_MAP_ALWAYS_POINTER)) cur_node.tgt_offset = gomp_map_val (tgt, hostaddrs, i - 1); if (cur_node.tgt_offset) cur_node.tgt_offset -= sizes[i]; @@ -4085,7 +4086,10 @@ GOMP_target_enter_exit_data (int device, size_t mapnum, void **hostaddrs, GOMP_MAP_VARS_ENTER_DATA); i += j - i - 1; } - else if (i + 1 < mapnum && (kinds[i + 1] & 0xff) == GOMP_MAP_ATTACH) + else if (i + 1 < mapnum + && ((kinds[i + 1] & 0xff) == GOMP_MAP_ATTACH + || ((kinds[i + 1] & 0xff) == GOMP_MAP_ALWAYS_POINTER + && (kinds[i] & 0xff) != GOMP_MAP_ALWAYS_POINTER))) { /* An attach operation must be processed together with the mapped base-pointer list item. */ diff --git a/libgomp/testsuite/libgomp.fortran/target-enter-data-3.f90 b/libgomp/testsuite/libgomp.fortran/target-enter-data-3.f90 new file mode 100644 index 00000000000..5d97566c66c --- /dev/null +++ b/libgomp/testsuite/libgomp.fortran/target-enter-data-3.f90 @@ -0,0 +1,22 @@ +implicit none +type t + integer :: dummy + integer, pointer :: p1(:), p2(:) + integer :: dummy2 +end type t +type(t) :: var +integer :: i +allocate(var%p1(5),var%p2(2:4)) +var%p1 = [22,53,28,6,4] +var%p2 = [46,679,54] + +!$omp target enter data map(to:var%p1, var%p2) +!$omp target + if (.not.associated(var%p1).or.lbound(var%p1,1)/=1.or.ubound(var%p1,1)/=5) stop 1 + if (.not.associated(var%p2).or.lbound(var%p2,1)/=2.or.ubound(var%p2,1)/=4) stop 2 + if (any (var%p1 /= [22,53,28,6,4])) stop 3 + if (any (var%p2 /= [46,679,54])) stop 4 +!$omp end target +!!$omp target exit data map(from:var%p1, var%p2) +end +