Kwok Cheung Yeung wrote:
Subject: [PATCH 03/11] openmp: Add support for iterators in 'target update'
clauses (C/C++)
This adds support for iterators in 'to' and 'from' clauses in the
'target update' OpenMP directive.
* * *
+ c_parser_error (parser, "% or % clause with modifier "
+
Hi Kwok,
thanks for the patch; looks quite good, but I have a couple of remarks:
Kwok Cheung Yeung wrote:
Date: Sat, 3 May 2025 20:24:26 +
Subject: [PATCH 02/11] openmp: Add support for iterators in map clauses
(C/C++)
This adds preliminary support for iterators in map clauses within Op
PING⁴
June 25, 2025, Tobias Burnus wrote:
PING³
June 2, 2025 Tobias Burnus wrote:
Tobias Burnus wrote:
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, t
Kwok Cheung Yeung wrote:
Date: Wed, 27 Nov 2024 21:49:12 +
Subject: [PATCH 01/11] openmp: Refactor handling of iterators
Move code to calculate the iteration size and to generate the iterator
expansion loop into separate functions.
Use OMP_ITERATOR_DECL_P to check for iterators in clause de
Kwok Cheung Yeung wrote:
This patch fixes an ICE due to a null-pointer dereference when finding
the symbol for the procedure name in a declare variant directive,
which occurs because the result of gfc_find_sym_tree is being
dereferenced unconditionally. The result is now checked, and the
symbo
Now, finally pushed as r16-2213-g451b6dbf475959.
Tobias
On June 27, 2025, Tobias Burnus wrote:
Background: In real-world code, one can find:
!$ACC DECLARE COPYIN(c1es, c2es, ...)
as here for the ICON weather model. This clearly implies that other
compilers accept and, potentially, require
On Sunday, July 6, 2025, Yuao Ma wrote:
>>> Since I don't have root/sudo permissions on my devbox, I manually
downloaded
>>> and compiled the autoconf 2.69 tarball. This means there might be some
minor
>>> discrepancies compared to the version shipped with OS distributions.
In principle, having a
Background: In real-world code, one can find:
!$ACC DECLARE COPYIN(c1es, c2es, ...)
as here for the ICON weather model. This clearly implies that other
compilers accept and, potentially, require those. For better
compatibility with real-world use, the just released OpenACC 3.4 now
permits PARAME
Hi Yuao,
Yuao Ma wrote:
>//but the testcases don't seem to be conditionalized on this. Would the
>//new tests fail if gcc is built against an insufficiently recent version
>//of mpfr,
…
The test case is indeed conditionalized, though in a different manner
than you
might expect. The condition
PING³
June 2, 2025 Tobias Burnus wrote:
Tobias Burnus wrote:
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
, but that's probably
overkill until we need it.
I think it would good to properly use the right sc0/sc1/nt for memory
access, but I concur that's something for a bit later.
Tobias
commit 750bc2899844d662aee93476f2da63fce68535d9
Author: Tobias Burnus
Date: Tue Jun 24 23:55:27
This patch adds the OpenACC routines acc_attach and acc_detach.
However, in order to avoid the generation of a temporary, which
breaks this feature, a special case had to be added to
gfc_trans_call.
Otherwise, I think it completes the Fortran additions of existing
C/C++ functions, by adding this
This is more based on documentation reading that on testing
as still only limited MI300 testing has been done and seemingly
this code does not usually get touched.
MI300's "9.1.10 Memory Scope and Temporal Control" distinguishes
between scalar memory (9.1.10.1) for which a single control bit exis
252cafa5045498a0e0c480ee6d48c136232
Author: Tobias Burnus
Date: Mon Jun 23 23:24:56 2025 +0200
OpenACC: Add 'if' clause to 'acc wait' directive
OpenACC 3.0 added the 'if' clause to four directives; this patch only adds
it to 'acc wait'.
ently look as follows:
https://gcc.gnu.org/onlinedocs/libgomp/Memory-allocation.html and
https://gcc.gnu.org/onlinedocs/libgomp/OMP_005fALLOCATOR.html
Tobias Burnus wrote:
Alex wrote:
Here is a follow up patch for documentation of the omp.h allocators,
[…]
I want the table in there somewhere bu
he attached patch, which
assumes a sufficiently new nvptx-tools (and has no xfails).
→ r16-1536-gea43b99537591b
Tobias
commit ea43b99537591b1103da3961c61f1cbfae968859
Author: Tobias Burnus
Date: Tue Jun 17 11:33:09 2025 +0200
OpenMP: Fix implicit 'declare target'
This fixes an issue with implicit declare target.
'' has:
template … endl() { ... }
...
extern template ostream& endl(ostream&);
which leads to a decl that is 'extern' but still
has the full function body available.
Result: On the offload side, 'endl' is present
but the functions it calls
Hi Yuao,
Yuao Ma wrote:
Fixed in this patch. Thinking about tex is always a pain...
> Additionally, I think all "half-revolutions" should be "half
revolutions"
Thanks! I have another nit:
* intrinsic.texi: Add new doc. Reorder doc for atand.
The first part is not really clear. I hav
Hi Yuao,
Yuao Ma wrote:
This patch is a follow-up to commit r16-938-ge8fdd55ec90749. In this
patch, we
add intrinsic documentation for the newly added trig functions with
half-revolutions. We also reorder the documentation for `atand` to
place it in
correct alphabetical order.
When I try to
This add experimental support for AMD Instinct MI300. It has been
tested to support hello world, but not yet much beyond (to come).
OK for mainline?
Tobias
gcn: Add experimental MI300 (gfx942) support
As gfx942 and gfx950 belong to gfx9-4-generic, the latter two are also added.
Note that there
libgomp.texi
[and hence onlinedocs/libgomp]. But that's for another day.)
Tobias
commit 152a09eae9d5852e2f628c3e8b3156bf744e63cf
Author: Tobias Burnus
Date: Tue Jun 10 06:21:12 2025 +0200
gcc-16/changes.html + projects/gomp/: OpenMP/OpenACC update
* gcc-16/changes.html: Add O
Most builtins in omp-builtins.def is marked as LEAF. At a glance,
that's surprising but looking at the functions, it turns out
that most of them just call 'gomp_thread ()' which is a simple
inline function such that no function call remains.
However, that's not true for all - and omp_get_mapped_p
I have now pushed those patches as:
r16-1262-g387209938d2c47
OpenMP: Add omp_get_initial_device/omp_get_num_devices builtins
r16-1261-g214b5d66c54613
builtins.def: Enable OpenMP/OpenACC builtins also with -fno-nonansi-builtins
Tobias
Currently, using the ISO version of C and C++ will disable the
OpenMP and OpenACC intrinsics, which is rather surprising. The
reason is that those imply -fno-nonansi-builtins and the
OpenMP/OpenACC are marked as non-ansi builtins.
While the latter is true, -fopenmp/-fopenacc seems to be rather
or
As a user reported, --with=arch= did not support the newer devices,
as we forgot to update the list.
While we still have lists to update, this one can be replaced by
checking directly against the .def file.
There was another list that we didn't update - in install.texi:
https://gcc.gnu.org/insta
Sandra Loosemore wrote:
gcc/ChangeLog
PR c++/120518
* omp-general.cc (omp_device_num_check): Look inside a
CLEANUP_POINT_EXPR when trying to optimize special cases.
LGTM. Thanks,
Tobias
[…]
+ tree t = *device_num;
+ if (TREE_CODE (t) == CLEANUP_POINT_EXPR)
+t =
This came up when looking at some context selectors that use 'target_device',
but is largely unrelated to it. (target_device has its own special casing).
Namely, it makes omp_get_initial_device and omp_get_num_devices PURE,
which attributes don't permit for Fortran - based on the state that
the n
Hi Sandra, hello world,
Sandra Loosemore wrote:
On 6/2/25 12:15, Tobias Burnus wrote:
The problem is that 'int'/'int*' became 'omp_interop_rc_t ret_code'
and 'omp_interop_rc_t *ret_code'.
...
I think the patch just confuses readers, as-is. Plus it h
Joseph Myers wrote:
On Sun, 1 Jun 2025, Yuao Ma wrote:
For MPFR versions older than 4.2.0, we've included our own folding functions.
I think the normal practice in GCC would be to avoid the optimizations
when the MPFR support is absent, instead of working around the absence
with possibly less a
Not really new - but as the topic came up elsewhere (OpenMP issue 4455),
I had a second thought about this and I think it make sense to add a note.
GCC uses the OpenMP 6.0 version.
The problem is that 'int'/'int*' became 'omp_interop_rc_t ret_code'
and 'omp_interop_rc_t *ret_code'.
For C++, pas
Tobias Burnus wrote:
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 Bu
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
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
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
@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
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
Hi Yuao,
Yuao Ma wrote:
[…]
Done.
LGTM :-) I have now applied it as r16-938-ge8fdd55ec90749.
Thanks for the patch!
Tobias
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
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
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
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
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-
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²
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 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
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
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
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
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
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
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
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
[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
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
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
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
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
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
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 >
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):
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
://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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
1 - 100 of 1404 matches
Mail list logo
