[Patch] libgomp: Add OpenMP's omp_target_memset/omp_target_memset_async [PR120444]

Attached patch adds omp_target_memset and omp_target_memset_async permitting to set (potentially large) data on the device to a certain value - in particular to '\0'. It uses 'memset' on the host (and for shared memory, e.g. via requires unified_shared_memory/self_maps). For nvptx, cuMemsetD8 is

[committed] OpenMP: Support OpenMP 5.0 "declare mapper" directives for C

I have now committed the second declare mapper patch, submitted by Julian at https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629367.html again it is based in the associated OG15 commit (kudos to all doing the rediffs): 69fd51954fc OpenMP: Support OpenMP 5.0 "declare mapper" directives

Re: [PATCH 3/3] OpenMP: Handle more cases in user/condition selector

Sandra Loosemore wrote: Like the attached V2 patch? LGTM. However, I think in metadirective-condition-template.C the "scan-tree-dump" should now be changed to "scan-tree-dump-times", given that there are several tests. Thanks, Tobias

Re: [PATCH 3/3] OpenMP: Handle more cases in user/condition selector

@Jason – The idea is make semantics.cc's maybe_convert_cond callable from parser.cc + pt.cc, i.e. to make it a non-static function. Any reasons not do so? Sandra Loosemore wrote: […] By using the existing front-end hooks for the implicit conversion to bool in conditional expressions, we also ge

[Patch] Fortran: gfc_simplify_{cospi,sinpi} - fix for MPFR < 4.2.0 (was: [PATCH] fortran: add constant input support for trig functions with half-revolutions)

Hi Harald, Harald Anlauf wrote: This breaks bootstrap here on openSUSE Leap 15.6 with mpfr-4.0.2: ../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_expr* gfc_simplify_cospi(gfc_expr*)': ../../gcc-trunk/gcc/fortran/simplify.cc:2305:3: error: 'mpfr_fmod_ui' was not declared in this scop

Re: [PATCH] fortran: add constant input support for trig functions with half-revolutions

Hi Yuao, Yuao Ma wrote: […] Done. LGTM :-) I have now applied it as r16-938-ge8fdd55ec90749. Thanks for the patch! Tobias

Re: [PATCH 2/3] OpenMP: Fix ICE and other issues in C/C++ metadirective error recovery.

Sandra Loosemore wrote: The new testcase included in this patch used to ICE in gcc after diagnosing the first error, and in g++ it only diagnosed the error in the first metadirective, ignoring the second one. The solution is to make error recovery in the C front end more like that in the C++ fro

Re: [PATCH 1/3] OpenMP: Fix ICE in metadirective recovery after error [PR120180]

Sandra Loosemore wrote: It's not clear whether a metadirective in a loop nest is supposed to be valid, but GCC certainly shouldn't be ICE'ing after diagnosing it as an error. gcc/c/ChangeLog PR c/120180 * c-parser.cc (c_parser_omp_metadirective): Only consume the token i

[Patch] libgomp: Add OpenACC's acc_memcpy_device{,_async} routines [PR93226]

We somehow missed to implement these OpenACC 2.6 functions (the Fortran routines are newer: 3.3). It is actually used, at least, by two SPEC hpc/accel (soma + lbm) tests (and OpenACC_VV) - and it was trivial to implement, which was my workaround to make them compile. Besides adding the same-devic

Re: [PATCH] fortran: add constant input support for trig functions with half-revolutions

Yuao Ma wrote: PR113152 If you run your patch through ./contrib/gcc-changelog/git_email.py 0001-fortran-add-constant-input-support-for-trig-function.patch you will notice that the PR is not recognized. The format as mentioned before is "PR component/number". Namely: "PR fortran/113

[committed] c-c++-common/gomp/{attrs-,}metadirective-3.c: Fix expected result [PR118694]

processing the offload code + deciding at runtime whether host fallback, gcn or nvptx offloading is used.) I will backport this also to GCC 15 as it is affected as well. Tobias commit 5d6ed6d604ff949b650e48fa4eaed3ec8b6489c1 Author: Tobias Burnus Date: Mon May 26 19:50:40 2025 +0200 c-

Re: [Patch] OpenMP/C++: Avoid ICE for BIND_EXPR with empty BIND_EXPR_BLOCK [PR120413]

Jakub Jelinek wrote: There is also BIND_EXPR_VARS, dunno if that should be walked instead or in addition. The usage is to ensure that variables are mapped with lambdas (→ closure_vars_accessed.add (…)) but not if they are local variables (→ data->local_decls.add (var)). The 'closure_vars_ac

PING² — Re: PING (and v2) – [Patch] nvptx/nvptx.opt: Update -march-map= for newer sm_xxx

PING² On May 12, 2025, Tobias Burnus wrote: PING. There is actually a minor update as meanwhile CUDA 12.8 was released that added the 'f' suffix and sm_103 and sm_121. Still, the pattern remains the same; hence, a normal PING. On April 25, 2025, Tobias Burnus wrote: The idea of

[committed] libgomp.c-c++-common/metadirective-1.c: Expect 'error:' for nvptx compile [PR118694]

Committed as r16-838-gb3d07ec7ac2ccd. When adding the testcase originally in r15-6963-gfdeceba59bee60 seemingly the compile-time FAIL when nvptx offload compilation is enabled was missed. That's now fixed by using an effective target, avoiding the FAIL. That there is an issue with such code was

[Patch] OpenMP/C++: Avoid ICE for BIND_EXPR with empty BIND_EXPR_BLOCK [PR120413]

This fixes a GCC 12-to-16 Regression related to an unexpected empty BIND_EXPR_BLOCK, where nonetheless aBIND_EXPR exists - just by not walking the hence non-existing variables binding to that block. Any comments before I commit this to mainline? I also intent to backport it relatively soonish to

Re: [PATCH] fortran: add constant input support for trig functions with half-revolutions

Hi, Yuao Ma wrote: I'm pretty swamped for the next couple of days Same issue here - hence, I haven't completed the review ... You're absolutely right that the best way to keep changes minimal is to just rename the `*resolve*` function. I missed the -gfc_resolve_trigd, +gfc_resolve_trig, c

Re: [PATCH] fortran: add constant input support for trig functions with half-revolutions

Hi Yuao, first comments, I still need to look again at some changes, especially at simplify.cc. Yuao Ma wrote: This patch introduces constant input support for trigonometric functions, including those involving half-revolutions. Both valid and invalid inputs have been thoroughly tested, as

Re: [PATCH 6/7] OpenMP: C front end support for "begin declare variant"

Tobias Burnus wrote: As mentioned before, the following error is bogus as there is no requirement to have the base function defined or declared before the variant function (or at all, or to be available in any TU): foo.c: In function ‘my.ompvariant1’: foo.c:4:7: error: no previous declaration

[GCC15][committed] OpenMP - backporting testcases + 2 mapping fixes

The next two commits fix two mapping issues, the rest are test cases that should have been in GCC 15 pre-branch. Namely: r15-9707-g57f73c3956572f   OpenMP/Fortran: Fix allocatable-component mapping of derived-type array comps r15-9706-gab9ca3a8b1af41   OpenMP: Fix mapping of zero-sized arrays w

Re: Add effective-target 'offload_device_usm', 'libgomp.c-c++-common/target-usm-1.c'

Hi Thomas, coming back to the patch itself – having sent comments in previous email. As mentioned, I think you either want to have: * Check whether the runtime knows that USM is supported for the default device (that is a non-host device), i.e. a no-host device is available with 'required uni

[Patch] OpenMP/Fortran: Fix allocatable-component mapping of derived-type array comps

The testcase was found when looking at mapping fails with SPEC HPC's 619.clvleaf_s; however, the variant fixed by the attached patch only showed up when experimenting and not in the SPEC testcase itself. Before the included fix, to be added testcase failed with an ICE. I intent to commit the atta

[Patch] OpenMP: Fix mapping of zero-sized arrays with non-literal size: map(var[:n]), n = 0

[I intent to commit this patch later today or probably tomorrow, unless there are comments, questions or concerns.] The issue showed up for SPEC HPC's 634.hpgmgfv_s benchmark, but only when running with multiple MPI processes. The reason is that in that case, the work is distributed over multiple

[committed] Fortran: Fix mpfr_tanu use in gfc_simplify_cotand with mpfr 4.2.0+ [PR120225] (was: PING – Re: [Patch] Fortran: Use mpfr_sinu etc. with mpfr 4.2.0+ for degree trigonometric functions [PR12

6-607-gc91c226762b422 and then the fix in r16-608-gaac78fde6aa6ae. Tobias commit aac78fde6aa6ae829679355bc2a65bcadd834e6f Author: Tobias Burnus Date: Wed May 14 09:18:09 2025 +0200 Fortran: Fix mpfr_tanu use in gfc_simplify_cotand with mpfr 4.2.0+ [PR120225] Fix commit r1

PING – Re: [Patch] Fortran: Use mpfr_sinu etc. with mpfr 4.2.0+ for degree trigonometric functions [PR120225]

sinpi etc. functions, cf. https://gcc.gnu.org/PR113152 for Fortran and https://gcc.gnu.org/PR118592 for C23/middle end. Tobias Burnus wrote: C23 added the sinpi, cospi, etc. functions. Therefore, MPFR in 4.2.0 added the mpfr_ counter parts. I assume that those internally use the mpfr_sinu

Re: [PATCH] fortran: map atand(y, x) to atan2d(y, x) [PR113413]

Hi Yuao, Yuao Ma wrote: Following up on your review comments, I have updated the patch. Thanks - LGTM. Two minor comments, but I have already pushed the commit as r16-602-gb239e9cf98ca92 First: * gfortran.dg/dec_math.f90: Add atand(y, x) testcase. Also for the documentation, the

Re: [PATCH] libfortran: Fix up _gfortran_s{max,min}loc1_{4,8,16}_s{1,4} [PR120191]

Jakub Jelinek wrote: There is a bug in _gfortran_s{max,min}loc1_{4,8,16}_s{1,4} which the following testcase shows. The functions return but then crash in the caller. Seems that is because buffer overflows, I believe those functions for if (mask == NULL || *mask) condition being false are sup

Re: [PATCH] libfortran: Fix up _gfortran_s{max,min}loc2_{4,8,16}_s{1,4} [PR120191]

First is slightly confusing as there are three patches for PR120191. In particular, two which look almost identical - one for loc2 (this one) and one for loc1 (the one sent one our later). Jakub pointed out that the remarks after "ok for trunk?" for this patch are obsoleted by the follow up patch

Re: [PATCH] libfortran: Fix up _gfortran_{, m, s}findloc2_s{1, 4} [PR120196]

Hi Jakub, Jakub Jelinek wrote: As mentioned in the PR, _gfortran_{,m,s}findloc2_s{1,4} iterate too many times in the back case if nothing is found. For !back, the loops are for (i = 1; i <= extent; i++) so i is in the body [1, extent] if nothing is found, but for back it is for (i = extent; i >

Re: [PATCH] fortran, v2: Fix up minloc/maxloc lowering [PR120191]

seems they are on the library side, so I'll post it incrementally. 2025-05-12 Jakub Jelinek Daniil Kochergin Tobias Burnus PR fortran/120191 * trans-intrinsic.cc (strip_kind_from_actual): Remove. (gfc_conv_intrinsic_minmaxloc):

[Patch, RFC] git_update_version.py: Support vendor-branch version bumps (was: [RFC] Enable automatic ChangeLog updates on devel/omp/gcc-15 branch)

Hi Sandra, hello world, Sandra Loosemore wrote: I have created the devel/omp/gcc-15 (aka "OG15") branch, ... For previous branches we'd been using ChangeLog.omp files paralleling the normal ChangeLog files, that were updated manually and committed with the corresponding patch.  In preparing

Re: libgomp: Add a few more OpenMP/USM test cases

Thomas Schwinge wrote: On 2025-05-12T17:03:29+0200, I wrote: "Add effective-target 'offload_device_usm', 'libgomp.c-c++-common/target-usm-1.c'" On top, we could then add the attached "libgomp: Add a few more OpenMP/USM test cases"? These all PASS for GCN gfx90a with 'HSA_XNACK=1'. For the c

Re: Add effective-target 'offload_device_usm', 'libgomp.c-c++-common/target-usm-1.c'

Hi, I concur that it would be useful to have information about USM suport something. I am less sure what we should test for. Q1: Does the default device support USM (and is not the host)? Q2: Is there a device that support 'requires unified_shared_memory'? At a glance, the answer for both is id

PING (and v2) – [Patch] nvptx/nvptx.opt: Update -march-map= for newer sm_xxx

PING. There is actually a minor update as meanwhile CUDA 12.8 was released that added the 'f' suffix and sm_103 and sm_121. Still, the pattern remains the same; hence, a normal PING. On April 25, 2025, Tobias Burnus wrote: The idea of -march-map= is to simply and future proof selec

[Patch] Fortran: Use mpfr_sinu etc. with mpfr 4.2.0+ for degree trigonometric functions [PR120225]

C23 added the sinpi, cospi, etc. functions. Therefore, MPFR in 4.2.0 added the mpfr_ counter parts. I assume that those internally use the mpfr_sinu, mpfr_cosu, ... functions, which are also user accessible. In any case, MPFR makes the ...u functions available and explicitly documents that for u

Re: [PATCH] fortran: map atand(y, x) to atan2d(y, x)

Hi all, hi Yuao, first, thanks for your patch - you are awesome! I believe it fixes the issue reported by Steven in problem report (PR) 113414, https://gcc.gnu.org/PR113413 Thus: * * * [Linking PR numbers] In order to correlate commits to issued (and get them automatically linked), the commit

Re: [PATCH, fortran] Fix simple typo in libgfortran

Hi Yuao, Yuao Ma wrote: Thanks for the tip! I ran the git_check_commit.py script, and it reported "OK." However, when I regenerated the ChangeLog, the function name wasn't included automatically. Usually 'git diff' shows the function name in the '@@' line, but that does not always work – ei

Re: [PATCH, fortran] Fix simple typo in libgfortran

Hi Yuao, Yuao Ma wrote: I'm writing to express my sincere gratitude for the opportunity to participate in Google Summer of Code with GCC this year. I am very enthusiastic about this program and fully committed to making a valuable contribution and fulfilling my responsibilities. Welcome an

Re: [PATCH] fortran: Fix up minloc/maxloc lowering [PR120191]

Jakub Jelinek wrote: This unfortunately only fixes some of the cases in the new testcase. We indeed should drop the kind argument from what is passed to the library, but need to do it not only when one uses the argument name for it (so kind=4 etc.) but also when one passes all the arguments to t

[committed] libgomp.{c, fortran}/interop-{hip, cuda}: Fix dg-run target selection

e. Thanks to Sandra for reporting the issue! Tobias commit 94e63410474a36655e1800387eabd73a6f930048 Author: Tobias Burnus Date: Fri May 9 10:57:44 2025 +0200 libgomp.{c,fortran}/interop-{hip,cuda}: Fix dg-run target selection While the tests checked whether the CUDA/HIP runtime is

Re: [PATCH 6/7] OpenMP: C front end support for "begin declare variant"

Hi all, hi Sandra, I am wondering whether such an example (see attachment) should also be added, confirming that always the correct function is called. (It mixes base/variant calls in various ways, also thanks to 'dispatch novariants(true)'.) I expected it to pass – as the code should fall

[committed] libgomp.fortran/map-alloc-comp-9{,-usm}.f90: Add unified_shared_memory variant

lf mapping for devices. Depending on the access pattern, way how USM is implemented and location of host vs. device process, copying (mapping) or direct access (self map) is faster. Additionally, copying might run into storage-size issues. commit 9565076f9b810541aeb63cb621d694326aa12216 Author: Tob

Re: [PATCH 6/7] OpenMP: C front end support for "begin declare variant"

On February 10, 2025, Sandra Loosemore wrote: […] When not using the variant function, having it limited to the TU means that that there are now warnings like: warning: ‘f.ompvariant1’ defined but not used [-Wunused-function] 4 | int f(int i) { | ^ I think that's okay - both

Re: [PATCH 3/7] OpenMP: Support functions for nested "begin declare variant"

Hi Sandra, hello world, see other email from today in this thread regarding a C++ module test case + C++ module issues and a parser issues. Regarding the patch itself: On February 10, 2025, Sandra Loosemore wrote: This patch adds functions for variant name mangling and context selector mergin

Re: [PATCH 4/7] OpenMP: Add flag for code elision to omp_context_selector_matches.

On February 10, 2025, Sandra Loosemore wrote: The "begin declare variant" has different rules for determining whether a context selector cannot match for purposes of code elision than we normally use; it excludes the case of a constant false "condition" selector for the "user" set. Namely: "If

Re: [PATCH 3/7] OpenMP: Support functions for nested "begin declare variant"

Hi Sandra, hello world, On Feburary 10, 2025, Sandra Loosemore wrote: This patch adds functions for variant name mangling and context selector merging that are shared by the C and C++ front ends. The OpenMP specification says that name mangling is supposed to encode the context selector for the

Re: 'libgomp.c/interop-hsa.c': GCN offloading only

Thomas Schwinge wrote: I've pushed to trunk branch commit 85ad0d84fcec720c1d94b9bda9a617ced70ba5d2 "'libgomp.c/interop-hsa.c': GCN offloading only", see attached. Thanks! If nvptx offloading compilation is enabled in addition to GCN, the former ICEs: during RTL pass: final [...]/l

Re: [PATCH] OpenMP, GCN: Add interop-hsa testcase

Andrew Stubbs wrote: This testcase ensures that the interop HSA support is sufficient to run a kernel manually on the same device. It reuses an OpenMP kernel in order to avoid all the complication of compiling a custom kernel in Dejagnu (although, this does mean matching the OpenMP runtime envir

[Patch] nvptx/nvptx.opt: Update -march-map= for newer sm_xxx

The idea of -march-map= is to simply and future proof select the best -march for a certain arch, without requiring that the compiler has support for it (like having a special multilib for it) - while -march= sets the actually used '.target' (and the compiler might actually generate specialized cod

[committed] libgomp/testsuite: Fix hip_header_nvidia check, add workaround to test

warning, only) libgomp/testsuite/libgomp.c/interop-hip-nvidia-full.c and (work around required in addition) testsuite/libgomp.c/interop-hipblas-nvidia-full.c commit 8ef0518bce489c4c0c252a0e0c44193c5f7cf777 Author: Tobias Burnus Date: Thu Apr 24 18:26:30 2025 +0200 libgomp/testsuite: Fix

[Patch] libgomp: Add additional OpenMP interop runtime tests

The attached patch adds a bunch of tests for OpenMP's interop; namely: * One test checks whether nowait/depend works * The rest checks that the returns cuda/cuda_driver and hip objects work. * This requires that he CUDA and HIP runtimes are found, best also the header files and/or hipfort For

[committed] OpenMP: Add libgomp.fortran/target-enter-data-8.f90

r16-92-gc9a8f2f9d39a31 Tobias commit c9a8f2f9d39a317ed67fb47157a995ea03c182d4 Author: Tobias Burnus Date: Wed Apr 23 09:03:00 2025 +0200 OpenMP: Add libgomp.fortran/target-enter-data-8.f90 Add another testcase for Fortran deep mapping of allocatable componen

Re: [PATCH] c++: Fix OpenMP support with C++20 modules [PR119864]

Jason Merrill wrote: On 4/22/25 11:04 AM, Tobias Burnus wrote: The question is why does this code trigger at all, given that there is OpenMP but no offload code at all? And how to fix it in case there is offload code and modules are used. This seems to be because of:   if

Re: [PATCH] c++: Fix OpenMP support with C++20 modules [PR119864]

Jason Merrill wrote: This is OK with a FIXME; presumably if we want to support running static constructors on the offload target we will eventually want to support that in modules as well. Well, the code that added support for static constructors on the offload target exposed the issue. Thus

[committed (Apr 17 to GCC 15 mainline)] libgomp.texi: For HIP interop, mention cpp defines to set

://gcc.gnu.org/onlinedocs/libgomp/Foreign-runtime-support-for-Nvidia-GPUs.html Tobias commit 4bff3f0b89af9a9aad69b8f85859c0a3667533ae Author: Tobias Burnus Date: Thu Apr 17 10:21:05 2025 +0200 libgomp.texi: For HIP interop, mention cpp defines to set The HIP header files recognize the

Re: [wwwdocs][Patch] gcc-15/changes: Fortran + offload (C++) update | project/gomp: GCC 15 update

Gerald Pfeifer wrote: On Thu, 17 Apr 2025, Tobias Burnus wrote: * https://gcc.gnu.org/projects/gomp/ This is a no-brainer. Well, it still adds GCC 16 … It does make me wonder whether we really need/want distinct docs for minor releases or shouldn't better keep just one for the branch

[wwwdocs][Patch] gcc-15/changes: Fortran + offload (C++) update | project/gomp: GCC 15 update

Hi all, @Fortraners: Comments to the added 'do concurrent' item? @Thomas: Are you fine with this C++ wording? @Andrew: Likewise for C++ and ROCm bump? Anyone: comments are welcome. Affected pages: * https://gcc.gnu.org/gcc-15/changes.html * https://gcc.gnu.org/projects/gomp/ Cheers, Tobia

Re: [PATCH] Docs: Document omp::allocator::* and ompx::allocator::* allocators.

Alex wrote: Here is a follow up patch for documentation of the omp.h allocators, I'm not super happy with it but I wanted to get eyes on it before I go to sleep tonight. I want the table in there somewhere but I'm not confident that where I put it was the right place. I think having the C++ te

[wwwdocs][committed] gcc-15 + projects/gomp: OpenMP update

Update the OpenMP entry in the GCC 15 release notes and the status at the OpenMP project page. * https://gcc.gnu.org/gcc-15/changes.html * https://gcc.gnu.org/projects/gomp/ Tobias commit 5937699869cfc15d57d8ba5913109701dcf7a64b Author: Tobias Burnus Date: Tue Apr 15 23:50:57 2025 +0200

[committed] libgomp.texi (gcn, nvptx): Mention self_maps alongside USM

d asr15-9506-g1ff4a22103767c Tobias commit 1ff4a22103767cd0133f0c1db6e85220f28ab3fa Author: Tobias Burnus Date: Tue Apr 15 23:19:50 2025 +0200 libgomp.texi (gcn, nvptx): Mention self_maps alongside USM libgomp/ChangeLog: * libgomp.texi (gcn, nvptx): Mention self_map

Re: [PATCH] OpenMP: omp.h omp::allocator C++ Allocator interface

Alex wrote: Tested on x86_64-pc-linux-gnu, this is only a library addition (and a few tests) so it shouldn't cause any major impacts. I also tested libgomp C to ensure the conditional compile was working. Namely, the change is only to omp.h(.in) - effective for __cplusplus >= 201103L. Note th

Re: OpenACC: Support GCC/C++-special 'default(_GCC_firstprivate)' clause [PR119692]

Hi Thomas, Thomas Schwinge wrote: To allow me to progress with other work items, is the attached "OpenACC: Support GCC/C++-special 'default(_GCC_firstprivate)' clause [PR119692]" OK to push to trunk branch, with a few test cases added? I assume this patch has been withdrawn. (Collateral from

[Patch] Fortran: Add code gen for do,concurrent's LOCAL/LOCAL_INIT [PR101602]

This patch is essentially the one of PR101602, comment 6. Thus, it has the same issues as that patch: * LOCAL for derived-type variables with default initalizers do not work (not initialized) * LOCAL/LOCAL_INIT for assumed-shape arrays fails (need some 'malloc'/'free' calls + some more other

[Patch] OpenMP: Fix append_args handling in modify_call_for_omp_dispatch

While the tree dump looked fine to a C coder, passing an array argument requires the '&' to take the address. Additionally, it makes sense to associate the call line number to the library calls - making the stepping through in the debugger more consistent. I was considering putting the init/clean

[Patch] libgomp: Add -Wno-c-binding-type for omp_lib.f90 compilation

Let's finally fix this issue. gfortran tries to make sure that BIND(C) functions are really compatible with C, e.g. by nagging (warning) when 'integer' instead of 'integer(kind=c_int)' is used, with c_int coming from the ISO_C_binding module. While making sense, in general, to use those - it doe

[committed] libgomp.texi: Add GCN doc for omp_target_memcpy_rect

GPUs; for nvptx, I moved the bullet point down; in the current version, the API call comes between the stack memory and memory allocation bullets, which seems to be misplaced. Additionally, I added a crossref to the two API functions. Tobias commit 0c63c7524bd523ea82933e90689b63d80e16d67e Auth

Re: [PATCH] OpenMP: 'interop' construct - add ME support + target-independent libgomp

Paul-Antoine Arras wrote: Thanks Sandra and Jakub for your comments. Likewise thanks to them and to you for the patch. Minor comments: include/ChangeLog: * gomp-constants.h (GOMP_DEVICE_DEFAULT_OMP_61): Define. (GOMP_INTEROP_FLAG_TARGET): Define. (GOMP_INTEROP_FLAG_TA

[committed] gcc/testsuite/g++.dg/gomp/append-args-8.C: Fix scan-dump-tree (was: [Linaro-TCWG-CI] gcc-15-8972-g7e286b56545: 3 regressions on aarch64)

eck master-aarch64, after: | commit gcc-15-8972-g7e286b56545 We track this bug report underhttps://linaro.atlassian.net/browse/GNU-1554. Please let us know if you have a fix.commit e0886d8ad4c51919c349d0b31f2bec3acbc79e14 Author: Tobias Burnus Date: Sun Mar 30 09:55:29 2025 +0200 gcc/testsu

Re: [PATCH] OpenMP: Create additional interop objects with append_args.

Hi Sandra, Sandra Loosemore wrote: This patch adds support for the case where #pragma omp declare variant with append_args is used inside a #pragma omp dispatch interop that specifies fewer interop args than required by the variant; new interop objects are implicitly created and then destroyed a

Re: [PATCH] OpenMP: Require target and/or targetsync init modifier [PR118965]

Sandra Loosemore wrote: As noted in PR 118965, the initial interop implementation overlooked the requirement in the OpenMP spec that at least one of the "target" and "targetsync" modifiers is required in both the interop construct init clause and the declare variant append_args clause. ... whic

[committed] OpenMP: Reorder diagnostic in modify_call_for_omp_dispatch [PR119559]

Reorder to the diagnostic to avoid issues when nappend < ninteropfor the case no append_args arguments at all (nappend == 0) and one interop clause to dispatch (ninterop == 1) Committed as r15-9120-gde92ac6f11e605. Tobias commit de92ac6f11e605987421fe1443b5b81ff172dbb6 Author: Tob

[committed] OpenMP: modify_call_for_omp_dispatch - fix invalid memory access after 'error' [PR119541]

allow this - hence, GCC diagnoses this error, but the append code was still executed, leading to the issue. Committed asr15-9063-gf3899e0fd3f9aa Thanks to Filip for testing with an ASAN-instrumentedGCC and reporting this issue! Tobias commit f3899e0fd3f9aa6b579a21e87b50c61ea5c448df Author: Tobias Burnus

[wwwdocs] gcc-15/changes.html + projects/gomp/: OpenMP update for interop

This patch updates both https://gcc.gnu.org/gcc-15/changes.html#openmp and https://gcc.gnu.org/projects/gomp/ for the current OpenMP implementation status. It also fixes a typo and intents to actually commit the change that mentions the support for aarch64 to nvptx offloading, cf. https://gcc.gnu

[Patch] OpenMP: Fix C++ template handling with append_args' prefer_type modifier

When Sandra implemented the GOMP_interop call in gimplify.cc for declare_variant's append_args, she run into an ICE because the C++ template substitution for prefer_type did not work. Her solution was to add a sorry to defer the implementation, which now the attached patch does. Actually, the hea

[Patch, v3] libgomp.texi: Document supported OpenMP 'interop' types for nvptx and gcn

suggested below -- a normal, non-typewriter font for the value, except for the first one which is an identifier (enum/parameter). * I use now an example, illustrating how to obtain the value. * * * Tobias Burnus wrote: For the string-valued constants in the table, please include the quotes

Re: [PATCH] OpenMP: Create additional interop objects with append_args.

Sandra Loosemore wrote: On 3/23/25 14:28, Tobias Burnus wrote: Thus, please useGOMP_DEVICE_DEFAULT_OMP_61 for: […] Done. (B) prefer_type & Fortran […] This turned out to be an accidental redefinition of a variable that shadowed one of the same name in an outer scope.  I added a simpli

Re: [Patch, v2] libgomp.texi: Document supported OpenMP 'interop' types for nvptx and gcn

Sandra Loosemore wrote: I find the part about the "associated named constant" really confusing; I am not sure those are for property identifiers or property values. Can you give an example, or actually list the named constants individually? Well, the property is called 'dev_num'; the identif

[Patch] install.texi: gcn - suggest to use Newlib with simd math fix [PR119325]

A GCC 15 regression turned out to be a bug in Newlib related to undefined behavior that just started to trigger in some cases. As it is now fixed, it makes IMHO sense to mention that Newlib commit in GCC's install documentation for AMD GPUs. Comments, suggestions to the attached patch? Tobias

[Patch, v2] libgomp.texi: Document supported OpenMP 'interop' types for nvptx and gcn

On August 24, 2024 Tobias Burnus wrote: [...] it documents the code added at "[patch][rfc] libgomp: Add OpenMP interop support to nvptx + gcn plugin", https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661207.html Quite some time has passed and those features are now on main

[Patch] omp-general.cc: Remove 'if' around call to always 'true' returning function [PR118627]

I intent to commit this a bit later today as obvious, unless there are comments. This is about two functions unconditionally return 'true'. Both appear (also) in an 'if' condition that is pointless. (The second one also appears in two other calls without an 'if', so far for consistency.) Beside

[committed] libgomp: Save OpenMP device number when initializing the interop object (was: [Patch] libgomp/plugin/plugin-nvptx.c: Fix device used for stream creation)

the testcase actually uses the returned CUDA context or device stream. The context was already handled, the stream creation hasn't. Something to check in a future testcase. Tobiascommit 4d5d1a7326c8509a4a6fc94eedc3ba22d68f806f Author: Tobias Burnus Date: Mon Mar 24 19:52:10 2025 +0100

[Patch] libgomp/plugin/plugin-nvptx.c: Fix device used for stream creation

When re-reading the current plugin code, I noticed that 'interop' created the cuStream created in the current CUDA context (current CUDA device) and not on the specified device. That's obviously the same if there is only a single nvptx device. The patch mimics what other code in the plugin use

[committed] libgomp.fortran/get-mapped-ptr-1.f90: Use -6 for non-conf dev number

c264df142a850b47135c0c4639d3a539b23149c5 Author: Tobias Burnus Date: Sat Mar 22 00:36:44 2025 +0100 libgomp.fortran/get-mapped-ptr-1.f90: Use -6 for non-conf dev number This is a fix for the GOMP_interop commit r15-8654-g99e2906ae255fc that added GOMP_DEVICE_DEFAULT_OMP_61 alias

Re: [Patch] libgomp/plugin: Add initial interop support to nvptx + gcn

67284e28 Author: Tobias Burnus Date: Fri Mar 21 21:39:42 2025 +0100 libgomp/plugin: Add initial interop support to nvptx + gcn The interop directive operates on an opaque object that represents a foreign runtime. This commit adds support for this to the two offloading plugin

[Patch] testsuite/lib/libgomp.exp: compile with -fdiagnostics-plain-output

I tried to match in dg-warning the whole string, including [-OpenMP], but it failed. I turned out that that was because of -fdiagnostics-urls ... Solution do what other testsuites do: Use -fdiagnostics-plain-output. Unless there are further comments, I intent to commit the attached patch later

[committed] Move gfortran.dg/gomp/declare-variant-mod-1*.f90 to libgomp.fortran/ [PR115271] (was: [Patch] Fortran: Store OpenMP's 'declare variant' in module file [PR115271])

sue does not manifest for in-tree testing when the system provides what is needed.) Committed as r15-8085-g2d5c1e5149809f. Thanks for the report! Tobias commit 2d5c1e5149809f978ea2c07517de13fdbb925de6 Author: Tobias Burnus Date: Mon Mar 17 10:12:44 2025 +0100 Move gfortran.dg/

[Patch] libgomp/plugin: Add initial interop support to nvptx + gcn

This patch requires the to be submitted GOMP_interop patch, which handles the generic libgomp parts. But once it is available, this patch adds support for the foreign runtimes cuda/cuda_driver/hip for nvptx and hip/hsa for gcn. The patch is based on my old RFC patch https://gcc.gnu.org/pipermail/

Re: [Patch] Fortran: Store OpenMP's 'declare variant' in module file [PR115271]

Hi Thomas, Thomas Koenig wrote: Attached is a long overdue bug fix, given that OpenMP's declare variant is supported in gfortran sincer12-4409-g724ee5a0093da4 (Oct 2021). (and in C/C++ since r10-3744-g94e7f906ca5c73, Oct 2019). While 'omp declare simd' was already handled in the .mod file, 'de

Re: [Patch] Fortran: Store OpenMP's 'declare variant' in module file [PR115271]

I wonder why sometimes my line breaks are preserved and at other times all eaten. Next try ... Tobias Burnus wrote: Hi Thomas, Thomas Koenig wrote: Just one question - as this will change the module file, will we still be compatible with reading gfortran 8 to gfortran 14-written module

[committed] contrib/gcc-changelog: Fix Git.AutoInterrupt - sys.meta_path is None exception

1-1-e935b27eb...@chromium.org/T/#u At least, the exception is gone after adding a 'repo.close()' before the function returns. Committed asr15-8068-g254549d2bb9bb3. Tobias commit 254549d2bb9bb3c2719dec597427919c59514fc3 Author: Tobias Burnus Date: Sat Mar 15 08:53:18 2025 +0100

[Patch] Fortran: Store OpenMP's 'declare variant' in module file [PR115271]

Attached is a long overdue bug fix, given that OpenMP's declare variant is supported in gfortran sincer12-4409-g724ee5a0093da4 (Oct 2021). (and in C/C++ since r10-3744-g94e7f906ca5c73, Oct 2019). While 'omp declare simd' was already handled in the .mod file, 'declare variant' was not. It is eas

Re: [PATCH] OpenMP/C: Store location in cp_parser_omp_var_list for kind=0 [PR118579]

Sandra Loosemore wrote: This patch is the C equivalent of commit r15-6512-gcf94ba812ca496 for C++, to improve the location information for individual items in an OpenMP variable list. LGTM – thanks for the patch, improving the diagnostic and reducing the differences between C and C++ for when

Re: [PATCH] OpenMP: Integrate dynamic selectors with dispatch argument handling [PR118457]

Hi Sandra, hello world, sorry for the belated review. Sandra Loosemore wrote: Support for dynamic selectors in "declare variant" was developed in parallel with support for the adjust_args/append_args clauses and the dispatch construct; they collided in a bad way. This patch fixes the "sorry" f

Re: [Patch] Fortran: Improve gfc_array_kind for assumed rank; gfc_tree_array_size on 'tree'

Just to be clear: the following touches generic Fortran code and, hence, needs Fortran FE review (still pending): Tobias Burnus wrote: (1) gfc_tree_array_size now can determine the array size not only from the passed Fortran gfc_expr but also using a descriptor, passed as gimple 'tree&#

[Patch] Fortran: Improve gfc_array_kind for assumed rank; gfc_tree_array_size on 'tree'

The attached patch does some ground-laying work for OpenMP deep mapping - touching common gfortran code. It does so by: (1)gfc_tree_array_size now can determine the array size not only from the passed Fortran gfc_expr but also using a descriptor, passed as gimple 'tree'. (2) Adds missingGFC_

[committed] gfortran.dg/gomp/metadirective-3.f90

-g8d922a80396b0c, cf. attachment. Tobias commit 8d922a80396b0cc9f5311d79aa760412dd018848 Author: Tobias Burnus Date: Tue Feb 18 15:48:39 2025 +0100 gfortran.dg/gomp/metadirective-3.f90: xfail on offload_nvptx Currently, 'target' with a nested metadirective creating a 'teams

[wwwdocs][committed] projects/gomp/: Update OpenMP implementation status

eady supported since a while (GCC 13; correct in the .texi file) and having a link directly to the OpenMP section makes sense, now that it is available. (Thanks!) Tobias commit 08114aefac17271a87eeaa6394f1874bf90604ab Author: Tobias Burnus Date: Tue Feb 18 10:27:27 2025 +0100 projects/

[Patch] OpenMP/Fortran: extend 'adjust_args' clause, fixes for it and declare variant [PR115271]

Hi all, on the fixes side: If a function only appeared in an INTERFACE block, the declare variant handling wasn't triggered - i.e. all diagnostic handled there wasn't. Additionally, when it was written as such in a module - and the module got used, it wasn't active such that the wrong (the non v

[wwwdocs] gcc-15/changes.html: Update AMD GPU (GCN) section for new gfx*

Update https://gcc.gnu.org/gcc-15/changes.html#amdgcn for the newly added generic support and the GPUs compatible with the generic devices. OK? To have clickable links: In the patch, both https://gcc.gnu.org/onlinedocs/gcc/AMD-GCN-Options.html and https://gcc.gnu.org/install/specific.html#amd

Re: [PATCH 1/7] OpenMP: Bug fixes for comparing context selectors

Sandra Loosemore wrote: gcc/ChangeLog * omp-general.cc (omp_context_selector_props_compare): Handle arbitrary expressions in the "user" and "device_num" selectors. (omp_context_selector_set_compare): Detect mismatch when one selector specifies a score and the other

Re: [PATCH 2/7] OpenMP: Pass a 3-way flag to omp_check_context_selector instead of a bool.

Namely, this patch replaces bool by the newly added enum 'OMP_CTX_{METADIRECTIVE,{BEGIN_,}DECLARE_VARIANT}'. Sandra Loosemore wrote: The OpenMP "begin declare variant" directive has slightly different requirements for context selectors than regular "declare variant", so something more than a bo

  1   2   3   4   5   6   7   8   9   10   >