Andre Vehreschild wrote:
PS That's good news about the funding. Maybe we will get to see "built in"
coarrays soon?
You hopefully will see Nikolas work on the shared memory coarray support, if
that is what you mean by "built in" coarrays. I will be working on the
distributed memory coarray
Hi Gerald,
Gerald Pfeifer wrote:
Looks like a janitorial task to fix the absolute links, possibly
excluding those with /git, /onlinedocs, /wiki – or assuming that the
main page is GCC.gnu.org, relying on the redirects.
It's on my list. A first quick check indicates there isn't much to do,
Hi Gerald,
Gerald Pfeifer wrote:
+++ b/htdocs/gcc-15/changes.html
+
+ https://gcc.gnu.org/projects/gomp/;>OpenMP
Can you please make this a relative link, i.e. "../projects/gomp/"?
Good point. I thought such links should be absolute because of
(www.)GNU.org, i.e.
Sandra Loosemore wrote:
On 6/6/24 06:06, Tobias Burnus wrote:
+@item I/O within OpenMP target regions and OpenACC compute regions
is supported
+ using the C library @code{printf} functions.
+ Additionally, the Fortran @code{print}/@code{write}
statements are
+ supported within
Hi Thomas,
regarding the commit r15-1070-g3a4775d4403f2e / https://gcc.gnu.org/r15-1070
First, thanks for adding I/O support to nvptx offloading.
I have a wording nit, to be confirmed by a native speaker:
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
...
+@item I/O within OpenMP
Hi Andrew, hi Jakub, hello world,
Andrew Stubbs wrote:
Compared to the previous v3 posting of this patch, the enumeration of
the "ompx" allocators have been moved to start at "100"
100 is a bad value - as can be seen below.
As Jakub suggested at
GCC 15 now supports unified-shared memory and the tile/unroll constructs
in OpenMP.
Updates https://gcc.gnu.org/gcc-15/changes.html
and https://gcc.gnu.org/projects/gomp/
Comments?
Tobias
gcc-15/changes.html + projects/gomp: update for new OpenMP features
GCC 15 now supports unified-shared
Regarding
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653417.html , are
there any …
Tobias Burnus wrote:
Comments or fine as is?
Tobias
with mainline's USM being much slower with ~30%
than OG13 with 12%.
Tobias Burnus wrote:
I have now tried it on my laptop with
BabelStream,https://github.com/UoB-HPC/BabelStream
Compiling with:
echo "#pragma omp requires unified_shared_memory" > omp-usm.h
cmake -DMODEL=omp -DCMAKE_CXX_C
Andrew Stubbs wrote:
PS: I would love to do some comparisons [...]
Actually, I think testing only data transfer is fine for this, but we
might like to try some different access patterns, besides straight
linear copies.
I have now tried it on my laptop with
Andrew Stubbs wrote:
On 03/06/2024 17:46, Tobias Burnus wrote:
Andrew Stubbs wrote:
+ /* If USM has been requested and is supported by all devices
+ of this type, set the capability accordingly. */
+ if (omp_requires_mask & GOMP_REQUIRES_UNIFIED_SHARED_ME
Andrew Stubbs wrote:
+ /* If USM has been requested and is supported by all devices
+ of this type, set the capability accordingly. */
+ if (omp_requires_mask & GOMP_REQUIRES_UNIFIED_SHARED_MEMORY)
+ current_device.capabilities |= GOMP_OFFLOAD_CAP_SHARED_MEM;
+
Somehow, I was one year ahead. The commit wasn't 2025-03-25 but in 2024.
Committed as obvious, also to avoid future confusions.
Tobias
commit 16fb3abf0fb4b88ee0e27732db217909fa429a81
Author: Tobias Burnus
Date: Mon Jun 3 12:56:39 2024 +0200
install.texi (gcn): Fix date of recommended
Richard Biener wrote:
install.texi also has the issue that it's not pre-packaged in a
easy to discover and readable file in the release tarballs and that
the online version is only for trunk.
I always wondered why it is not included at
https://gcc.gnu.org/onlinedocs/ — it would then also be
Richard Biener wrote:
On Mon, 3 Jun 2024, Tobias Burnus wrote:
Thomas Schwinge wrote:
In the following, I have then reconsidered that stance; we may actually
"Implement global constructor, destructor support in a conceptually
simpler way than using 'collect2' (the program): impl
Comments or fine as is?
Tobias
gcc-15/changes.html (nvptx): Constructors are now supported
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index b59fd3be..b3305079 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -85,7 +103,14 @@ a
Hi Thomas, hi Tom,
any comment regarding this patch?
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650007.html
Tobias
Am 25.04.24 um 12:51 schrieb Tobias Burnus:
Motivated by a surprise of a colleague that with -m32,
no offload dumps were created; that's because mkoffload
does
Thomas Schwinge wrote:
In the following, I have then reconsidered that stance; we may actually
"Implement global constructor, destructor support in a conceptually
simpler way than using 'collect2' (the program): implement the respective
functionality in the nvptx-tools 'ld'". The latter is
Hi Sandra,
some observations/comments, but in general it looks good.
Sandra Loosemore wrote:
This patch adds the OMP_METADIRECTIVE tree node and shared tree-level
support for manipulating metadirectives. It defines/exposes
interfaces that will be used in subsequent patches that add front-end
Now that unified-shared memory works (with some devices), mark it as 'Y'
and link to the device-specific chapter. While there is always room for
improvement (like having opt-in partial support for managed-memory
semi-USM devices), it works sufficienty for a 'Y'.
Additionally, I saw that 5.2
This patch depends (on the libgomp/target.c parts) of the patch
"[patch] libgomp: Enable USM for some nvptx devices",
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652987.html
AMD GPUs that are either APU devices or MI200 [or MI300X]
(with HSA_XNACK=1 set) can access host memory; the
Jakub Jelinek wrote:
I mean, if we want to add something, maybe better would an -include like
option that instead of including a file includes it directly.
gcc --include-inline '#pragma omp requires unified_shared_memory' ...
Likewise for Fortran, but there the question is whether it should be
Jakub Jelinek wrote:
How is that option different from
echo '#pragma omp requires unified_shared_memory' > omp-usm.h
gcc -include omp-usm.h
?
I mean with -include you can add anything you want, not just one particular
directive, and adding a separate option for each is just weird.
For C/C++,
Tobias Burnus wrote:
While most of the nvptx systems I have access to don't have the
support for
CU_DEVICE_ATTRIBUTE_PAGEABLE_MEMORY_ACCESS_USES_HOST_PAGE_TABLES, one
has:
Actually, CU_DEVICE_ATTRIBUTE_PAGEABLE_MEMORY_ACCESS is sufficient. And
I finally also found the proper webpage
While most of the nvptx systems I have access to don't have the support
for CU_DEVICE_ATTRIBUTE_PAGEABLE_MEMORY_ACCESS_USES_HOST_PAGE_TABLES,
one has:
Tesla V100-SXM2-16GB (as installed, e.g., on ORNL's Summit) does support
this feature. And with that feature, unified-shared memory support
-fopenmp-force-usm can be useful for some badly written code. Explicity
using 'omp requires' makes more sense but still. It might also make
sense for testing purpose.
Unfortunately, I did not see a simple way of testing it. When trying it
manually, I looked at the 'a.xamdgcn-amdhsa.c'
Improve test coverage by removing 'prune-output' given that the features
are implemented in the meanwhile.
Comments, suggestions? Otherwise I will commit the patch as obvious.
Tobias
testsuite/*/gomp: Remove 'dg-prune-output "not supported yet"'
gcc/testsuite/ChangeLog:
*
Let's make https://gcc.gnu.org/gcc-15/changes.html a bit more useful …
While there were several useful Fortran commits already, only one seems
to be about a new feature.
Thus, document selected_logical_kind and the ISO_FORTRAN_ENV additions.
Comments or suggestions before I commit it?
Tobias
Hi PA, hi all,
two remarks while quickly browsing the code:
Paul-Antoine Arras:
+ if (n->sym->ts.type != BT_DERIVED
+ || !n->sym->ts.u.derived->ts.is_iso_c)
+ {
+ gfc_error ("argument list item %qs in "
+
Hi Bernhard,
rep.dot@gmail.com wrote:
library such as @url{http://opencoarrays.org} needs to be linked.
Maybe use https?
Works, but as the certificate is not valid, it requires to ignore the
errors in a browser, which is a worse user experience.
The error is, e.g.,
"curl: (60) SSL
Hi Jakub,
Jakub Jelinek wrote:
On Mon, May 20, 2024 at 08:31:02AM +0200, Tobias Burnus wrote:
Hmm, there were now two daily bumps: [...] I really wonder why.
Because I've done it by hand.
Okay, that explains it.
I still do not understand why it slipped through at the first place; I
tried
pts? Does
it ignore the errors? Or what goes wrong here? Any idea?
TobiasFrom f56b1764f2b5c2c83c6852607405e5be0a763a2c Mon Sep 17 00:00:00 2001
From: Tobias Burnus
Date: Sun, 19 May 2024 08:17:42 +0200
Subject: [PATCH] contrib/gcc-changelog/git_update_version.py: Improve diagnostic
contrib/Chang
That is for https://gcc.gnu.org/PR115150 – a GCC 12/13/14/15 regression,
caused when switching from a libgomp call to inline code and missing the
corner case of zero-size arrays ...
OK for mainline + all affected branches?
Tobias
Fortran: Fix SHAPE for zero-size arrays
PR fortran/115150
I noticed that gfortran's coarray support did not link to the
http://www.opencoarrays.org/
As that library is needed to support parallelization, it makes sense to
have the link.
Motivated by someone claiming at ISC-HPC that GCC only supports a single
image.
And also motivated by Damian's
errors? Or what goes wrong here? Any idea? Tobias
From f56b1764f2b5c2c83c6852607405e5be0a763a2c Mon Sep 17 00:00:00 2001
From: Tobias Burnus
Date: Sun, 19 May 2024 08:17:42 +0200
Subject: [PATCH] contrib/gcc-changelog/git_update_version.py: Add ignore
commit, improve diagnostic
contrib/Chang
Minor update – to include GCC 14 and update mainline to 15.
I also replaced the doc links to the latest release; shouldn't matter
for the status but it is nicer nonetheless.
Tobias
commit 6d76756d2070040c35e7991a626805a736edea1d
Author: Tobias Burnus
Date: Tue May 14 09:34:47 2024 +0200
Motivated by a surprise of a colleague that with -m32,
no offload dumps were created; that's because mkoffload
does not process host binaries when the are 32bit (i.e. ilp32).
Internally, that done as follows: The host compiler passes to
'mkoffload' the used host ABI, i.e. -foffload-abi=ilp32 or
Richard Biener wrote:
I do wonder whether hot-patching the ELF header from the libgomp plugin
with the actual micro-subarch would be possible to make the driver happy.
For completeness, there is also the possibility to play with an
environment variable as in HSA_OVERRIDE_GFX_VERSION=9.0.0 or
When clicking on the GCC..1x links at
https://gcc.gnu.org/projects/gomp/#omp5.0 , I noticed that the GCC 13
and 14 links did not link to the OpenMP changes.
It turned out that in GCC 12 and before (see commit message for
details), the OpenMP and OpenACC changes are under "New Languages and
I experimented with some variants to make clearer that each of RDNA2 and
RNDA3 applies to two card types, but at the end I settled on the
fewest-word version.
Comments, remarks, suggestions? (To this change or in general?)
Current version: https://gcc.gnu.org/gcc-14/changes.html#amdgcn
Jerry D wrote:
See attached updated patch.
It turned rather quickly out that this patch – committed as
r14-9822-g93adf88cc6744a – caused regressions.
Namely, real-world code use tab(s) as separator instead of spaces.
[For instance, PR114304 which contains a named-list input file from SPEC
Hi Jerry, hello world,
Jerry D wrote:
On 4/5/24 10:47 AM, Jerry D wrote:
On 4/4/24 2:41 PM, Tobias Burnus wrote:
I think for the current testcases, I like the patch – the question
is only what's about:
',3' as input for 'comma' (or '.3' as input for 'point')
[...]
But for 'comma
Hi Jerry,
I think for the current testcases, I like the patch – the question is
only what's about:
',3' as input for 'comma' (or '.3' as input for 'point')
For 'point' – 0.3 is read and ios = 0 (as expected)
But for 'comma':
* GCC 12 reads nothing and has ios = 0.
* GCC 13/mainline has
I find it confusing to see multiple in a row without content.
Actually, both have as content, but those are commented out as
actual news is missing ...
See https://gcc.gnu.org/gcc-14/changes.html and see the last entry at
the bottom of the page and "Operating Systems" somewhere in between.
Minor OpenACC 2.7 update to https://gcc.gnu.org/gcc-14/changes.html#openacc
The 'readonly' modifier is now in (well, since March), albeit more 2.7
features are in the pipeline...
Comments, remarks, suggestions before I commit it?
Tobias
gcc-14/changes.html: Mention OpenACC 2.7's 'readonly'
Found when testing my own change via https://validator.w3.org/nu/#file
Committed as obvious.
Tobias
commit c9e275660a19c804dd8c591c73cb9b169a9d7573
Author: Tobias Burnus
Date: Thu Apr 4 22:07:28 2024 +0200
gcc-14/changes.html: Fix HTML syntax
W3.org's HTML checker complained
Hi Jerry,
Jerry D wrote:
The attached log entry and patch (git show) fixes this issue by adding
logic to handle spaces in eat_separators. One or more spaces by
themselves are a valid separator. So in this case we look at the
character following the spaces to see if it is a comma or semicolon.
TR12 update:
* I misplaced one implemented in GCC 14 in one of the last commits
* Same update as just proposed for libgomp.texi:
- Renaming of 'coexecute' to 'workdistribute'
(Post TR12 change to avoid confusion with Fortran's co_min,
co_broadcast, ... intrinsic procedures for
Hi all,
this patch updates the OpenMP TR12 status (to-do) items:
(a) 'coexecute', added in TR12, was renamed after TR12 to
'workdistribute'. Reason: Feedback that 'co...' reminds
of Fortran coarrays and the its intrinsic procedures:
co_broadcast, co_max, co_min, co_reduce, co_sum
Nvptx's mkoffload.cc contains 14 'fatal_error' calls and one 'warning_at' call,
which stands out more clearly (color, bold) when enabling
diagnostic_color_init
which this patch does. — Additionally, the call gcc_init_libintl permits that
the already translated error messages also show up as
Found when working with -save-temps and looking at 'mkoffload'
with a GCC configured for both nvptx and gcn offloading.
Before (for 'a.out') for mkoffload:a.offload_args now: a.amdgcn-amdhsa.offload_args
and a.nvptx-none.offload_args
OK for mainline?
Tobias
PS: The code does not free the
Hi Jakub, hello world
Jakub Jelinek wrote:
On Wed, Apr 03, 2024 at 11:09:19AM +0200, Tobias Burnus wrote:
@@ -3954,8 +3956,8 @@ on the GPU.
To enable support for GCN3 Fiji devices (gfx803), GCC has to be configured
with
@option{--with-arch=@code{fiji}} or
@option{--with-multilib-list
Update for the GCN Newlib commit 7dd4eb1db "amdgcn: Implement proper locks",
https://sourceware.org/git/?p=newlib-cygwin.git;a=commit;h=7dd4eb1db
And change future to past tense regarding the LLVM 18 release.
OK for mainline?
Thanks,
Tobias
GCN: install.texi update for Newlib change and LLVM
This patch handles --with-arch= in GCN's mkoffload.cc
While mkoffload mostly does not know this and passes it through to the GCN lto1
compiler,
it writes an .o file with debug information - and here the -march= in the ELF
flags must
agree with the one in the other files. Hence, it uses now the
Richard Biener wrote:
I'll follow up with the libgomp testing test summary for archival
purposes. I still see linker errors for testcases using -g
(the ld: ^[[0;31merror: ^[[0mincompatible mach:
/tmp/ccr0oDpD.mkoffload.dbg.o^M kind)
Hmm, odd – can you try compile with -save-temp and look at
Hi Andrew,
Andrew Stubbs wrote:
This is more-or-less what I was planning to do myself, but as I want
to include all the other features that get parametrized in gcn.cc,
gcn.h, gcn-hsa.h, gcn-opts.h, I hadn't got around to it yet.
Unfortunately, I think the gcn.opt and config.gcc will always
Given the large number of AMD GPU ISAs and the number of files which
have to be adapted, I wonder whether it makes sense to consolidate this
a bit, especially in the light that we may want to support more in the
future.
Besides using some macros, I also improved the diagnostic if the object
Hi all, hi Thomas & Chung-Lin,
Thomas Schwinge wrote:
But I realized another thing: don't we have to handle the 'readonly'
modifier also in Fortran module files, that is, next to the OpenACC
'declare' 'copyin' handling in 'gcc/fortran/module.cc':
'AB_OACC_DECLARE_COPYIN' etc.?
I bet so; it is
Hi all, hi Thomas & Chung-Lin,
Thomas Schwinge wrote:
But I realized another thing: don't we have to handle the 'readonly'
modifier also in Fortran module files, that is, next to the OpenACC
'declare' 'copyin' handling in 'gcc/fortran/module.cc':
'AB_OACC_DECLARE_COPYIN' etc.?
I bet so; it is
Hi Kwok,
On January 22, 2024, Kwok Cheung Yeung wrote:
There was a bug in the declare-target-indirect-2.c libgomp testcase
(testing indirect calls in offloaded target regions, spread over
multiple teams/threads) that due to an errant fallthrough in a switch
statement resulted in only one
Hi Chung-Lin, hi Thomas, hello world,
some thoughts glancing at the patch.
Chung-Lin Tang wrote:
There is still some shortcomings in the current state, mainly that only explicit-shaped
arrays can be used (like its C counterpart). Anything else is currently a bit more
complicated in the
Hi Chung-Lin,
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641669.html
Chung-Lin Tang wrote:
this patch implements reductions for arrays and structs for OpenACC. Following
the pattern for OpenACC reductions [...]
(Stumbled over while looking at the Fortran patch, but applying to
in texinfo. It clearly wasn't
done on purpose in GCC, though. Hence:
Committed as obvious.
Tobias
commit ef79c64cb5762c86ee04ddfcedb7fe31eaa3bac8
Author: Tobias Burnus
Date: Tue Mar 12 15:42:50 2024 +0100
libgomp/libgomp.texi: Fix @node order in @menu
While texinfo 7.0.3 does
Jakub Jelinek wrote:
So firstprivate clause handling remaps them then if declare target indirect
is used? If so, the patch looks reasonable to me.
[I have now updated the patch to turn the testcase to ensure
that is also keeps works at runtime.]
OpenMP leaves it a bit open when the remapping
Using dummy procedures in a target region with 'defaultmap(none)' leads to:
Error: 'g' not specified in enclosing 'target'
and this cannot be fixed by using 'firstprivate' as non-pointer dummy routines
are rejected as "Error: Object 'g' is not a variable".
Fixed by doing the same for mapping
Hi Thomas,
Am 08.03.24 um 12:15 schrieb Thomas Schwinge:
OK to push
"Fix 'char' initialization, copy, check in
'libgomp.oacc-fortran/acc-memcpy.f90'",
see attached?
OK.
I think there was some remaining code around the problem that
HUGE(1_int8) = 127 and '-128_int8' is invalid because in
Hi Thomas,
Thomas Schwinge wrote:
/* Return the number of GCN devices on the system. */
int
-GOMP_OFFLOAD_get_num_devices (void)
+GOMP_OFFLOAD_get_num_devices (unsigned int omp_requires_mask)
{
if (!init_hsa_context ())
return 0;
+ /* Return -1 if no omp_requires_mask cannot be
Hi Thomas,
first, I have the feeling we talk about (more or less) the same code
region and use the same words – but we talk about rather different
things. Thus, you confuse me (and possibly Andrew) – and my reply
confuses you.
Thomas Schwinge wrote:
On 2024-03-07T12:43:07+0100, Tobias
Hi,
Thomas Schwinge wrote:
An issue with libgomp GCN plugin 'GCN_SUPPRESS_HOST_FALLBACK' (which is
different from the libgomp-level host-fallback execution):
+failure:
+ if (suppress_host_fallback)
+GOMP_PLUGIN_fatal ("GCN host fallback has been suppressed");
+ GCN_WARNING ("GCN target
Found when glancing at it: A typo and an omission.
Committed. Seehttps://gcc.gnu.org/projects/gomp/#omp5.2 for the result.
Tobias
commit f99d0f3a2c61ad6677170b9068d511c20ba1bfe1
Author: Tobias Burnus
Date: Thu Mar 7 11:40:57 2024 +0100
projects/gomp/: Fix typo, mark an item
Hi Sandra,
Sandra Loosemore wrote:
On 3/1/24 08:23, Tobias Burnus wrote:
Maybe the proposed wording will help others to avoid this pitfall.
(Or is this superfluous as -foffload= is not much used and, even if,
no one then remembers or finds this none?)
Well, I spent a long time looking
Hi,
Sandra Loosemore wrote:
On 3/1/24 17:29, Sandra Loosemore wrote:
On 3/1/24 08:23, Tobias Burnus wrote:
Aside: Shouldn't all the HTML documents start with a and
before
the table of content? Currently, it has:
Top (GNU libgomp)
and the body starts with
Short Table of Contents
I
'shared' argument could be false was missed. The
respective check has now been added.
2024-03-01 Jakub Jelinek
Tobias Burnus
PR c++/110347
gcc/ChangeLog:
* gimplify.cc (omp_notice_variable): Fix 'shared' arg to
lang_hooks.decls.omp_disregard_value_expr for
(first)private in target
Not very often, but do I keep running into issues (fails, segfaults)
related to testing programs compiled with a GCC without offload
configured and then using the system libraries. - That's equivalent
to having the system compiler (or any offload compiler) and
compiling with -foffload=disable.
Hi Thomas,
Thomas Schwinge wrote:
On 2024-02-27T20:11:30+0100, Tobias Burnus wrote:
The attached patch updates the manual to match OpenACC 3.3
specification for the implemented routines.
But not update references to OpenACC 3.3, too?
As the change is not really visible (except when using
Hi all, hi John & Thomas
John David Anglin wrote:
On 2024-02-29 6:02 p.m., Thomas Schwinge wrote:
I wonder: shouldn't that cap at 50 threads happen inside libgomp,
generally, instead of per test case and user code (!)?
Per my
understanding, OpenMP 'num_threads' specifies a *desired* number
Hi Iain, hello world,
Thomas Schwinge wrote:
On 2024-01-16T15:00:16+, Iain Sandoe wrote:
...
diff --git a/gcc/lto-section-names.h b/gcc/lto-section-names.h
index a743deb4efb..1cdadf36ec0 100644
--- a/gcc/lto-section-names.h
+++ b/gcc/lto-section-names.h
...
@@ -35,8 +39,14 @@ extern
Minor update for older and more recent changes.
Comments?
Tobias
gcc-14/changes.html + projects/gomp/: OpenMP + OpenACC update
Update OpenMP for two meanwhile implemented features (lvalue-expr in map,
indirect now also in Fortran).
Update OpenACC for one new feature (Fortran interface to
Hi Thomas,
(Regarding 'call acc_attach(x)' – the problem is that one needs the
address of '' and 'x'; while 'x' is readily available, for '' no
temporary variable has to get involved – and there are plenty of ways
temporaries can get introduced; for most cases, an interface exists that
When checking something else, I noticed that there was one warning in
openmp.cc that did not use OPT_Wopenmp.
I intent to commit the attached patch later today as obvious.
Tobias
Fortran/Openmp: Use OPT_Wopenmp for gfc_match_omp_depobj warning
gcc/fortran/ChangeLog:
* openmp.cc
I just encountered 'arch(nvptx64)'. I think it makes sense to support
it as alias for 'nvptx' in the context selector for better compatibility.
Comments, remarks, suggestions?
Tobias
PS: See the LLVM documentation below. I do note that those are not identical
as LLVM uses 'nvptx' for 32bit
While waiting for some testing to finish, I got distracted and added the
very low hanging OpenACC 3.3 fruits, i.e. those Fortran routines that directly
map to their C counter part.
Comments, remarks?
Tobias
OpenACC: Add Fortran routines
When debugging a linker issue, leading to a mismatch in the number of
host/device functions, I was surprised by seeing one additional entry.
Well, it turned out to be due to the ICV variable.
This patch makes it more consistent. The "+1" is returned since
r12-2769-g0bac793ed6bad2 (for the
cating whether it
is called for a target region or not.
2024-02-16 Tobias Burnus
Jakub Jelinek
PR c++/110347
gcc/cp/ChangeLog:
* cp-gimplify.cc (cxx_omp_disregard_value_expr): Add new
Boolean argument and use it.
* cp-tree.h (cxx_omp_disregard_value_expr): Update prototy
The following works with PARALLEL but not with TARGET.
OpenMP states the following is supposed to work:
A = 5; // == this->A
B = 6; // == this->B
C[44] = 7; // == this->C; assume 'int C[100]'
#pragma firstprivate(A,C) private(B)
{
A += 5; // Now: A is 10.
B = 7;
The following works with PARALLEL but not with TARGET.
OpenMP states the following is supposed to work:
A = 5; // == this->A
B = 6; // == this->B
C[44] = 7; // == this->C; assume 'int C[100]'
#pragma firstprivate(A,C) private(B)
{
A += 5; // Now: A is 10.
B = 7;
C[44]
Hi Jakub,
Jakub Jelinek wrote:
Of course it makes me wonder to what extent we actually do support the
OpenMP 5.1 target_device device_num trait with constant or non-constant
device num:
Answer: If one removes some early errors such that the compiler
continues a bit further, one gets:
36 |
Jakub Jelinek wrote:
Isn't all this caused just by the missing check that condition trait has a
constant expression?
IMHO that is the way to handle it in GCC 14.
Concur – how about the following patch?
Tobias
PS: See PR113904 for follow up tasks. / Instead of '.AND.' etc. I could
have also
Inomp_resolve_declare_variant, a code path generates a new decl for the
base function – in doing so, it ignores the assembler name. As the
included Fortran example shows, this will lead to a linker error.
Solution: Also copy over the assembler name. Comments, suggestions,
remarks before I
}
+! { dg-xfail-run-if "Requires libgomp bug fix pending review" { offload_device
} }
Thanks,
Tobias
On 06/02/2024 9:03 am, Tobias Burnus wrote:
LGTM. I just wonder whether there should be a value test and not just
a does-not-crash-when-called test for the latter testcase, i.e.
+++
Kwok Cheung Yeung wrote:
As previously discussed, this version of the patch adds code to emit a
warning when a directive like this:
!$omp declare target indirect(.true.)
is encountered (i.e. a target directive containing at least one
clause, but no to/enter clause, which appears to violate
Hi Thomas,
Thomas Schwinge wrote:
On 2024-01-23T10:55:16+0100, Tobias Burnus wrote:
plugin/plugin-nvptx.c: Fix fini_device call when already shutdown [PR113513]
The following issue was found when running libgomp.c/target-52.c with
nvptx offloading when the dg-set-target-env-var was honored
Andrew Stubbs wrote:
/tmp/ccrsHfVQ.mkoffload.2.s:788736:27: error: value out of range
.amdhsa_next_free_vgpr 516
^~~ [Obviously, likewise
forlibgomp.c++/..
Hmm, supposedly there are 768 registers allocated in groups of 12, on
gfx1100
plus_): Only
define for !TARGET_RDNA2_PLUS.
Signed-off-by: Tobias Burnus
gcc/config/gcn/gcn-valu.md | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/config/gcn/gcn-valu.md b/gcc/config/gcn/gcn-valu.md
index cd027f8b369..23b441f8e8b 100644
--- a/gcc/config/gcn/gcn-valu.md
+++
gcn-amdhsa-offload-tree-dump optimized "= gfx1100 \\(\\);"
Committed as obvious as r14-8488-gcb366731e767e2
Tobias
commit cb366731e767e2dec158c8c4a495fe2ccbd550ff
Author: Tobias Burnus
Date: Mon Jan 29 11:06:15 2024 +0100
libgomp.c/declare-variant-4.h: Fix used variant function
/changes.html (amdgcn): Update for gfx1030/gfx1100
Signed-off-by: Tobias Burnus
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index a04b62ff..2d777f52 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -329,6 +329,11 @@ a work-in-progress.
AMD Radeon (GCN
gcc/ChangeLog:
* doc/install.texi (amdgcn): Recommend LLVM 15+ and newlib 4.4+,
but keep requiring only newlib 4.3+ and, if gfx1100 is disabled,
LLVM 13.0.1+.
Signed-off-by: Tobias Burnus
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 5747b5a12fe..c7794439107 100644
--- a/gcc/
Hi Richard,
Richard Biener wrote:
Looks good to me.
Thanks - I will commit it after lunch to see whether someone else has
additional comments.
+@item gfx1030
+Compile for RDNA2 gfx1030 devices (GFX10 series).
+
+@item gfx1100
+Compile for RDNA3 gfx1100 devices (GFX11 series).
Btw, "GFX10"
Now with patch ...
Tobias Burnus wrote:
Hi all, hi Richard & Andrew,
Am 24.01.24 um 17:01 schrieb Tobias Burnus:
This patch obviously depends on Andrew's; he wrote in the previous
email of this thread regarding his patch:
Andrew Stubbs wrote:
This is enough to get gfx1100 working for
Jakub Jelinek wrote:
On Fri, Jan 26, 2024 at 01:00:28PM +0100, Richard Biener wrote:
libgomp/
* plugin/plugin-gcn.c (suitable_hsa_agent_p): Filter out
agents with unsupported ISA.
...
@@ -1443,6 +1445,13 @@ suitable_hsa_agent_p (hsa_agent_t agent)
switch (device_type)
1 - 100 of 3336 matches
Mail list logo
