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)
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 most purposes, on top of the
patch that To
Andrew Stubbs wrote:
We can move on to COV5 for GCC 15, probably. I'm not aware of any
great blocker, but it sets a minimum LLVM.
And as our testing hardware showed, it also bumps the minimal ROCm to
5.2 (as 5.1 fails with COV5).
Otherwise, as mentioned, COV5 was added to LLVM 14, but as we
Hi all,
Andrew Stubbs wrote:
On 26/01/2024 07:29, Richard Biener wrote:
If you link against prebuilt objects with COV 5 it seems there's no
way to
override the COV version GCC uses? That is, do we want to add
a -mcode-object-version=... option to allow the user to override this
(and
file and writes into an
an AMD GPU object file it creates. And all object files linked together
must have the same ABI version.
gcc/ChangeLog:
* config/gcn/gcn-hsa.h (ABI_VERSION_SPEC): New; creates the
"--amdhsa-code-object-version=" argument.
(ASM_SPEC): Use it; replace previous version
This patch avoids assembler warnings for gfx908 and gfx90a such as
'-xnack-mattr=-sramecc' is not a recognized feature for this target(ignoring
feature)
as we pass -mattr=-xnack-mattr=-sramecc to the llvm-mc assembler.
Solution: Add a space before the second '-mattr='.
OK for mainline?
cc (SET_XNACK_UNSET, TEST_SRAM_ECC_UNSET): New.
(SET_SRAM_ECC_UNSUPPORTED): Renamed to ...
(SET_SRAM_ECC_UNSET): ... this.
(main): Update SRAM_ECC and XNACK for the -march as done in gcn-hsa.h.
Signed-off-by: Tobias Burnus
gcc/config/gcn/mkoffload.cc | 38
(AMD GCN Options): Add gfx1100 to -march/-mtune.
libgomp/ChangeLog:
* testsuite/libgomp.c/declare-variant-4.h: Add variant functions
for gfx1030 and gfx1100.
* testsuite/libgomp.c/declare-variant-4-gfx1100.c: New test.
Signed-off-by: Tobias Burnus
gcc/config.gcc
Updated my email address.
Committed as r14-8374-ged4c7893de2cba.
Tobias
commit ed4c7893de2cbae0a07bb4984e408d57e6db06f3
Author: Tobias Burnus
Date: Tue Jan 23 22:18:57 2024 +0100
MAINTAINERS: Update my email address
ChangeLog:
* MAINTAINERS: Update my email
Kwok Cheung Yeung wrote:
This patch adds support for the indirect clause on the OpenMP 'declare
target' directive in Fortran. As with the C and C++ front-ends, this
applies the 'omp declare target indirect' attribute on affected
function declarations. The C test cases have also been translated
: Document omp_pause_resource{,_all} and omp_target_memcpy*
libgomp/ChangeLog:
* libgomp.texi (Runtime Library Routines): Document
omp_pause_resource, omp_pause_resource_all and
omp_target_memcpy{,_rect}{,_async}.
Co-authored-by: Sandra Loosemore
Signed-off-by: Tobias Burnus
libgomp/libgomp.texi
Slightly changed patch:
nvptx_attach_host_thread_to_device now fails again with an error for
CUDA_ERROR_DEINITIALIZED, except for GOMP_OFFLOAD_fini_device.
I think it makes more sense that way.
Tobias Burnus wrote:
Testing showed that the libgomp.c/target-52.c failed with:
libgomp
OMP_OFFLOAD_memcpy2d,
GOMP_OFFLOAD_memcpy3d, GOMP_OFFLOAD_openacc_async_host2dev,
GOMP_OFFLOAD_openacc_async_dev2host): Update for return-type change.
Signed-off-by: Tobias Burnus
libgomp/plugin/plugin-nvptx.c | 41 +
libgomp/target.c | 7 +--
map=): Add sm_89 and sm_90a.
Signed-off-by: Tobias Burnus
diff --git a/gcc/config/nvptx/nvptx.opt b/gcc/config/nvptx/nvptx.opt
index 09d75fca037..deb006663d7 100644
--- a/gcc/config/nvptx/nvptx.opt
+++ b/gcc/config/nvptx/nvptx.opt
@@ -108,9 +108,15 @@ Target RejectNegative Alias(misa=,sm_80)
ma
n error as the caller does so.
(maybe_unlink, compile_native): Use %<...%> and %qs in fatal_error.
(main): Likewise. Fix 'mkoffload.dbg.o' cleanup.
Signed-off-by: Tobias Burnus
gcc/config/gcn/mkoffload.cc | 32
1 file changed, 16 insertions(+), 16 deletions
.c/declare-variant-4-gfx803.c: Likewise.
Signed-off-by: Tobias Burnus
libgomp/testsuite/libgomp.c/declare-variant-4-fiji.c | 2 ++
libgomp/testsuite/libgomp.c/declare-variant-4-gfx803.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/libgomp/testsuite/libgomp.c/declare-variant-4-fiji.c
Hi Sandra, hi all,
Sandra Loosemore:
On 1/14/24 07:26, Tobias Burnus wrote:
I have some minor nits about typos and copy-editing.
Thanks. That's the downside of doing editing while being sleepy on a
train. Updated and extended version (documenting also omp_target_memcpy)
is attached. Warning
This documents two more OpenMP (5.0) routines, omp_pause_resource and
omp_pause_resource_all.
Comments, remarks, suggestions - to the patch or the documentation in
general?
Tobias
PS: When looking at it, I found an issue in the spec with regards to a
new constant (post TR12, hence, not
Julian Brown wrote:
This patch adds support for parsing general lvalues ("locator list item
types") for OpenMP "map", "to" and "from" clauses to the C front-end,
similar to the previously-posted patch for C++. Such syntax is permitted
for OpenMP 5.0 and above. It was previously posted for
Ups - now attached. Thanks Martin!
Martin Jambor wrote:
On Mon, Jan 08 2024, Tobias Burnus wrote:
The attached patch
there was no patch attached to your message.
Martin
does a tiny updated to the OpenMP features (AMD GCN
now also has an optimized memcpy_rect not only nvptx), but the main
The attached patch does a tiny updated to the OpenMP features (AMD GCN
now also has an optimized memcpy_rect not only nvptx), but the main
change is some shifting around to make it more consistent and better
readable.
I intend to commit this relatively soon; like always, comments and
-g52a2c659ae6c21
Tobiascommit 97a52f69d209f69e755ffad6897c7176da9ac686
Author: Tobias Burnus
Date: Mon Jan 8 15:18:10 2024 +0100
amdgcn: Add gfx1100 to new XNACK defaults in mkoffload
Commit r14-6997-g78dff4c25c1b95 added an arch-dependent
SET_XNACK_OFF vs. SET_XNACK_ANY check
ROCm meanwhile supports also some consumer cards; besides the semi-new
gfx1030, support for gfx1100 was added more recently (in ROCm 5.7.1 for
"Ubuntu 22.04 only" and without parenthesis since ROCm 6.0.0).
GCC has already very limited support for gfx1030 - whose multlib support
is - on
Am 05.01.24 um 13:23 schrieb Julian Brown:
On Wed, 20 Dec 2023 15:31:15 +0100
Tobias Burnus wrote:
Here's a rebased/retested version which fixes those bits (I haven't
adjusted the libgomp.texi bit you noted yet, though).
How does this look now?
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
Hi Sandra,
Tobias Burnus wrote:
(I have now an errant to do - and will continue later with the review.)
First, something a bit unrelated to this patch but affecting related
code (quoting old, existing code):
int
omp_context_selector_matches (tree ctx)
...
case
Tobias Burnus wrote:
Sandra Loosemore wrote:
From: Kwok Cheung Yeung
This patch implements the libgomp runtime support for the dynamic
target_device selector via the GOMP_evaluate_target_device function.
...
+GOMP_evaluate_target_device (int device_num, const char *kind
Hi Sandra,
looks quite okay, but I have a couple of remarks:
Sandra Loosemore wrote:
From: Kwok Cheung Yeung
This patch implements the libgomp runtime support for the dynamic
target_device selector via the GOMP_evaluate_target_device function.
...
--- /dev/null
+++
Hi Andrew,
I just spotted that this define was missing.
OK for mainline?
Tobiasgcn.h: Add builtin_define ("__gfx1030")
gcc/ChangeLog:
* config/gcn/gcn.h (TARGET_CPU_CPP_BUILTINS): Add
builtin_define ("__gfx1030").
diff --git a/gcc/config/gcn/gcn.h b/gcc/config/gcn/gcn.h
index
Hi Sandra,
given that it is "just" a revised patch of previously posted patch and
(code wise not file wise) very localized to OpenMP code - and even there
touching only 'declare ...' code in a simple way:
I would be still fine to have it in GCC 14, but I want to give Jakub a
chance to
Hi all,
updated patch attached - which also fixes some additional issues and
adds omp_target_is_accessible.
On 03.01.24 23:35, Sandra Loosemore wrote:
On 1/3/24 11:31, Tobias Burnus wrote: [...]
I'm not sure about the usability issues, except I think it's generally
easier to change
1 - 100 of 3307 matches
Mail list logo
