From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id A56323858D28 for ; Sat, 28 Jan 2023 17:36:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A56323858D28 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,254,1669104000"; d="scan'208";a="94893830" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa3.mentor.iphmx.com with ESMTP; 28 Jan 2023 09:36:37 -0800 IronPort-SDR: cgViaZNvdL18gkjokXXCrduhJ8Qc4cU4jUmYzeGx8Hi8rSY7ItqInP0zQi0NjWfZ7jTh4SuJuI s27hh6NyIE6ulCVzWBo66rUMuINZj/hpq+KflSaE0SZfp3TMRsvLH7TJIn/OD6hoJUa+QjhQIv modoCszs9R21LnrPycHkHq/rCfxhW9+HTTPZkxOR/U3u3nIcliZedrHgn/0qH12lLeZGuRVxYZ ci8QCXh+GOZqL5zsTTomAnlymG7RRuRH11tlb3JssG/pS1Yoll0DYhCZ488hcVqx6kNYeHwj2c kqI= Message-ID: <75669240-a7d4-f5b1-a554-01a7b8cb5879@codesourcery.com> Date: Sat, 28 Jan 2023 18:36:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: =?UTF-8?Q?OpenMP_Patch_Ping_=e2=80=93_including_=22=5b13_Regression?= =?UTF-8?Q?=5d=22_patches?= Content-Language: en-US From: Tobias Burnus To: Jakub Jelinek , gcc-patches References: <7d2ba3ac-0337-b58b-41a4-ba3100066001@codesourcery.com> In-Reply-To: <7d2ba3ac-0337-b58b-41a4-ba3100066001@codesourcery.com> 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-14.mgc.mentorg.com (139.181.222.14) 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: "[13 Regression]" OpenMP Fortran patches: [Patch] OpenMP/Fortran: Fix loop-iter var privatization with !$OMP LOOP [PR= 108512] https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610531.html [Patch][v2] OpenMP/Fortran: Partially fix non-rect loop nests [PR107424] https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610584.html Additionally, there several more patches pending, see below. Of those: The first two small ones are very simple; especially the first one I regard as obvious! The third one is a documentation patch. The others are of varying complexity but I think some would be still suitab= le for the current stage, including some which have been pinged since October = :-( Tobias PS: The mentioned patches: On 10.01.23 12:37, Tobias Burnus wrote: > 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 > directive (was: [Patch] Fortran/OpenMP: Add parsing support for > allocators directive) > 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 patch > [PATCH 1/5] [gfortran] Add parsing support for allocate directive > (OpenMP 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 > directive (OpenMP 5.0).'. > at > https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603279.html > (and earlier in the thread); > implementing 'omp allocate' (Fortran/C/C++) seems to be easier but > no one has started implementing > it so far - only parsing support exists. > - The USM patches on semi-USM system run into a similar issue as > 'allocators' 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 > missing 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 mapper" support > https://gcc.gnu.org/pipermail/gcc-patches/2022-December/thread.html#60903= 1 > 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-string-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 on data exit mapping, > the current code might add a bogus 'alloc:'. - Idea is to handle this > explicitly > 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 > Fortran 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