public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Tobias Burnus <tobias@codesourcery.com>
To: gcc-patches <gcc-patches@gcc.gnu.org>, Jakub Jelinek <jakub@redhat.com>
Subject: Re: OpenMP patch ping
Date: Tue, 6 Sep 2022 17:01:22 +0200	[thread overview]
Message-ID: <a7f88c8a-f732-4761-5a78-bb538f77df11@codesourcery.com> (raw)
In-Reply-To: <c4bd5262-2261-3603-78c7-bfc9d1b731a1@codesourcery.com>

[-- Attachment #1: Type: text/plain, Size: 6689 bytes --]

Follow-up patch ping (updated)

The first listed patches are smaller + should be quicker to be reviewable,
but in terms of priority, it would be good to make some progress on the
larger patches below as well. Especially as the first patches are only
mine ...

Smaller patches
(i) preparing for true reverse offload
  [Patches are rather independent + not complete for offloading.
   I have WIP patch for: finish mapping handling in target.c;
   follow-up to nvptx plugin patch (see there), GCN support
   (stack handling patch + reverse offload func).]
* [Patch][1/3] libgomp: Prepare for reverse offload fn lookup
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600333.html
* [Patch][2/3] GCN: libgomp+mkoffload.cc: Prepare for reverse offload fn lookup
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600340.html
* Re: [Patch][2/3][v2] nvptx: libgomp+mkoffload.cc: Prepare for reverse offload fn lookup
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600527.html
* [Patch] libgomp/nvptx: Prepare for reverse-offload callback handling
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600381.html
* [Patch] libgomp: Add reverse-offload splay tree
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600390.html

(ii) Other smaller patches:
* [Patch] OpenMP/Fortran: Permit end-clause on directive
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600433.html
* [Patch] libgomp.texi: Document libmemkind + nvptx/gcn specifics
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600494.html
* [wwwdocs] gcc-13/changes.html + projects/gomp/: OpenMP update
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600864.html

(iii) And an RFC patch:
* [Patch] OpenMP: Document ompx warnings + add Fortran omx warning [PR106670]
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600490.html



Backlog:


On 16.08.22 19:28, Tobias Burnus wrote:

* [Patch] OpenMP, libgomp, gimple: omp_get_max_teams, omp_set_num_teams, and omp_{gs}et_teams_thread_limit on offload devices
  https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599278.html
[Depends on just-reviewed nearly ready by-device env patch.
Might see an update tomorrow/next days, once the env patch is revised again.]

* [PATCH 0/3] OpenMP SIMD routines

[Part 1/2 + 2/2 are in; still missing is 3/3]
"[PATCH 3/3] vect: inbranch SIMD clones"
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599490.html


[PATCH 0/6] OpenMP 5.0: Fortran "<https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599490.html[PATCH0/6]OpenMP5.0:Fortran>declare mapper" support
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596036.html
Some review might make sense already; the final commit depends on:
"OpenMP 5.0: C & C++ "declare mapper" support (plus struct rework, etc.)"
which is currently being reworked (cf. links in "PPS"); the much revised
patch is now regression free but still needs to be cleaned up, split and
(re)submitted by Julian.



* [PATCH 0/5] [gfortran] Support for allocate directive (OpenMP 5.0)
  https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588367.html
(already older - but I missed to ping it.)

* [PATCH 00/17] openmp, nvptx, amdgcn: 5.0 Memory Allocators
  https://gcc.gnu.org/pipermail/gcc-patches/2022-July/597976.html
  * Unified-Shared Memory & Pinned Memory

Depending on those:

* [PATCH] OpenMP, libgomp: Handle unified shared memory in omp_target_is_accessible.
  https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594187.html

* [PATCH, OpenMP, Fortran] requires unified_shared_memory 1/2: adjust libgfortran memory allocators
  https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599703.html
  (Fortran part, required for ...)
* Re: [PATCH, OpenMP, Fortran] requires unified_shared_memory 2/2: insert USM allocators into libgfortran
  https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601059.html

And finally:

* [PATCH, libgomp] Fix chunk_size<1 for dynamic schedule
  https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599332.html
(Side remark: some other debugging support like showing the mapping being done as stderr output or ... would be nice as well; might depend on a libgomp-debug.so and/or -f...(sanitize=openmp or ...); the other open-source compiler has something similar.)
Tobias

PS: I hope the list above and the one below is somewhat complete...

 * * *

PPS: Tracking patches pending (re)submissions, just that it is not
forgotten on our side:
(revised)
* [PATCH] OpenMP, libgomp: Environment variable syntax extension.
  https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598770.html
Nearly ready – except for minor review comments.

* [PATCH] openmp: fix max_vf setting for amdgcn offloading
  https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598265.html
→ To be updated for review comments.
(Side note: we should at some point find a way to improve target-specific
handling; similar to the are-exceptions-supported issue of PR101544 but
there are more.)

* [OpenMP, nvptx] Use bar.sync/arrive for barriers when tasking is not used
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600818.html
(back to drawing board)

* [PATCH, OpenMP, v4] Implement uses_allocators clause for target regions
  https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596587.html
  * Needs to be revised according to review comments

* Fortran allocatable components handling (needs to be split into separate pieces and submitted
  separately)
  https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593704.html

* [PATCH 00/16] OpenMP: lvalues in "map" clauses and struct handling rework
  https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586600.html
  and January + February updates (search for metadirective)
+ patch review end of May, e.g.
  https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595762.html (+ 4 more emails)

* [PATCH 00/16] OpenMP: lvalues in "map" clauses and struct handling rework
  https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585439.html
  + [PATCH v2 00/11] OpenMP 5.0: C & C++ "declare mapper" support (plus struct rework, etc.)
  https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591973.html

* [PATCH 00/40] OpenACC "kernels" Improvements
  https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586901.html
  (4 simple patches are in by now; could be reviewed, in principle)

-----------------
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:[~2022-09-06 15:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-16 17:28 Tobias Burnus
2022-09-06 15:01 ` Tobias Burnus [this message]
  -- strict thread matches above, loose matches on Subject: below --
2023-01-10 11:37 OpenMP Patch Ping Tobias Burnus
2022-11-24 12:01 Tobias Burnus
2020-11-27 16:09 OpenMP patch ping 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=a7f88c8a-f732-4761-5a78-bb538f77df11@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).