public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Tobias Burnus <tobias@codesourcery.com>
To: Jakub Jelinek <jakub@redhat.com>, gcc-patches <gcc-patches@gcc.gnu.org>
Subject: OpenMP Patch Ping
Date: Tue, 10 Jan 2023 12:37:43 +0100	[thread overview]
Message-ID: <7d2ba3ac-0337-b58b-41a4-ba3100066001@codesourcery.com> (raw)

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
=============

* [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
=================================

* [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
=======================
(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#609031
   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)
====================
(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ß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

             reply	other threads:[~2023-01-10 11:37 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-10 11:37 Tobias Burnus [this message]
2023-01-28 17:36 ` OpenMP Patch Ping – including "[13 Regression]" patches Tobias Burnus
2023-02-07 16:34 ` Tobias Burnus
2023-02-14  9:40   ` Tobias Burnus
  -- strict thread matches above, loose matches on Subject: below --
2022-11-24 12:01 OpenMP Patch Ping Tobias Burnus
2022-08-16 17:28 OpenMP patch ping Tobias Burnus
2022-09-06 15:01 ` Tobias Burnus
2020-11-27 16:09 Tobias Burnus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7d2ba3ac-0337-b58b-41a4-ba3100066001@codesourcery.com \
    --to=tobias@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).