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 3279C3858CDA for ; Tue, 10 Jan 2023 11:37:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3279C3858CDA 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.96,315,1665475200"; d="scan'208";a="96386924" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa1.mentor.iphmx.com with ESMTP; 10 Jan 2023 03:37:47 -0800 IronPort-SDR: OpcPqQNOqIJIzne5WwfampalYmSay1Vx/9mckfYmjfTznRCf3OLWNsXmSwGcyfudzm7cGUFBTa F+5O/jeJJbF9DX+r9lGSKFvvf82bXWEXAFsj90rxm/K0h9Gkb2enOlZ8Nw+6W2OCnFa6MAa/FS IM9yu/AaYN7++aoOihpiq8wch/GNx1XxttNe95xZzhpqC3ybU1aj22TrFwXOjKxH04iw+lxTy2 4rOkrG64WMzU9WVT0csuj8PSDcr4ZGL/QMQEdoHhQG07ioP4g9KIgMiN0a1LoUiPWLuHGj0KL4 URM= Message-ID: <7d2ba3ac-0337-b58b-41a4-ba3100066001@codesourcery.com> Date: Tue, 10 Jan 2023 12:37:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Content-Language: en-US To: Jakub Jelinek , gcc-patches From: Tobias Burnus Subject: OpenMP Patch Ping Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable 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=-5.4 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,KAM_SHORT,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi all, hello Jakub, Below is the updated list to last ping, https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607178.html NOTE to the list below: I have stopped checking older patches. I know some more are pending review, others need to be revised. I will re-check, once the below listed patches have been reviewed. Cf. old list. Thanks for the reviews done in between the last ping and now! * * * Small patches =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * [Patch] Fortran: Extend align-clause checks of OpenMP's allocate clause https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608401.html Tue Dec 13 16:38:22 GMT 2022 * [Patch] OpenMP: Parse align clause in allocate directive in C/C++ https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608404.html Tue Dec 13 17:44:27 GMT 2022 * Re: [Patch] libgomp.texi: Reverse-offload updates (was: [Patch] libgomp: = Handle OpenMP's reverse offloads) https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608245.html Thu Nov 24 12:01:04 GMT 2022 (Side note: wwwdocs also needs to be updated for the latter patch and some other patches done in the meanwhile.) Fortran allocat(e,ors) prep patch =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D * [Patch] Fortran/OpenMP: Add parsing support for allocators/allocate direc= tive (was: [Patch] Fortran/OpenMP: Add parsing support for allocators direc= tive) https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608904.html Wed Dec 21 15:51:25 GMT 2022 (Remark: While written from scratch, it is kind of a follow-up to Abid's pa= tch [PATCH 1/5] [gfortran] Add parsing support for allocate directive (Open= MP 5.0) you/Jakub reviewed on Tue Oct 11 12:13:14 GMT 2022, i.e. https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603258.html - For the actual implementation of 'allocators', we still have to solve the= issues raised in the review for '[PATCH 2/5] [gfortran] Translate allocate dire= ctive (OpenMP 5.0).'. at https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603279.html (a= nd earlier in the thread); implementing 'omp allocate' (Fortran/C/C++) seems to be easier but no on= e has started implementing it so far - only parsing support exists. - The USM patches on semi-USM system run into a similar issue as 'allocator= s' and for it, some ME omp_allocate is added.) Mapping related patches =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (Complex but GCC needs a revision badly as it fixing several bugs and missi= ng functionality.) * Complete patch set was just re-submitted by Julian, overiew patch is [PATCH v6 00/11] OpenMP: C/C++ lvalue parsing, C/C++/Fortran "declare ma= pper" support https://gcc.gnu.org/pipermail/gcc-patches/2022-December/thread.html#6090= 31 Fri Dec 23 12:12:53 GMT 2022 * Note: For 10/11 of the set, there was a follow up this Monday [PATCH v6 10/11] OpenMP: Support OpenMP 5.0 "declare mapper" directives = for C https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609566.html [As it relates to one patch in the series: '[Patch] Fortran/OpenMP: Fix DT struct-component with 'alloc' and array = descr' That's mine, needs to be updated (WIP) and fixes array descriptor/alloc-str= ing-length var issues, where descriptor/string length may need to be handled explicitly on= data entering map, i.e. string lengths/allocator may require 'to:' instead of 'alloc:' - and o= n data exit mapping, the current code might add a bogus 'alloc:'. - Idea is to handle this expli= citly in fortran/trans-openmp.cc instead of auto-adding it in the ME. Status: WIP - removed in ME but not all cases are handled yet in FE.) Fortran deep mapping (allocatable components) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (Old patch of March 2022, but first part now properly but belated submitted= - today): [Patch][1/2] OpenMP: Add lang hooks + run-time filled map arrays for Fortra= n deep mapping of DT https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609637.html Tobias ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 201= , 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaf= t: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955