I got confused myself when reading
https://gcc.gnu.org/onlinedocs/libgomp/OpenMP-Context-Selectors.html
Especially with regards to other platforms like PowerPC.
It turned out that the list is complete, kind of. For 'arch' and 'isa'
those are the only ones - if we want to have more, it has to be
I was checking one of those functions - and now ended up documenting
some of them. Still to be documented are omp_target_{is_accessible,memcpy*}.
I did run into some possibly questionable code for corner cases and have
filed https://gcc.gnu.org/PR111707 for those. The documentation matches
the cu
Just that it doesn't get forgotten, the attached patch needs to be
applied on top.
It handles 'tile'/'unroll' directive names in the 'contains'/'absent'
clauses of the 'assume'/'assumes' directives.
Currently, we don't do anything with it after parsing; hence, no further
changes are required. (W
Strictly structured blocks are '!$omp ' directly
followed by 'BLOCK ... END BLOCK', i.e. a Fortran block construct.
I did run into this issue because 'integer :: n; n = 5; !$omp ...;
block; integer :: A(n)' was not accepted.
Well, it turned out that was because the BLOCK handling was not quite r
Hi David,
your commit breaks compilation with GCC < 6, here with GCC 5.2:
gcc/analyzer/access-diagram.cc: In member function 'void ana::boundaries::add(const
ana::access_range&, ana::boundaries::kind)':
gcc/analyzer/access-diagram.cc:655:20: error: 'kind' is not a class, namespace,
or enumerat
Hi David,
On 09.10.23 16:08, David Malcolm wrote:
On Mon, 2023-10-09 at 12:09 +0200, Tobias Burnus wrote:
The following works:
(A) Using "kind == boundaries::kind::HARD" - i.e. adding
"boundaries::"
(B) Renaming the parameter name "kind" to something else - like
The attached patch adds 'omp allocate' support for stack/automatic variables
variables for Fortran.
I had originally a pure FE version for Fortran, which failed with
'defaultmap'/'default';
I then thought I could simply piggyback on the existing C/C++ support.
But it turns out that Fortran is c
This patch improves the documentation by completing the description of
the remaining so far undocumented OpenMP Memory-Management Routines
(except for the two function added in TR11, which are also unimplmeneted).
Current online version:
https://gcc.gnu.org/onlinedocs/libgomp/Memory-Management-Ro
I noticed that while OMP_DEFAULT_DEVICE was updated a ref to
OMP_TARGET_OFFLOAD (→ mandatory case) was missing. And
OMP_TARGET_OFFLOAD wasn't updated at all for those changes.
I hope the new version is clearer.
Current versions:
https://gcc.gnu.org/onlinedocs/libgomp/OMP_005fDEFAULT_005fDEVICE.h
On 13.10.23 13:01, Jakub Jelinek wrote:
On Tue, Oct 10, 2023 at 06:46:35PM +0200, Tobias Burnus wrote:
+++ b/gcc/gimplify.cc
@@ -1400,23 +1400,53 @@ gimplify_bind_expr (tree *expr_p, gimple_seq *pre_p)
+ else if (errorcount
+ || (align == NULL_TREE
; Registergericht
München, HRB 106955
commit fd6b17a4892684f286274d874f0029604feda7e5
Author: Tobias Burnus
Date: Sat Oct 14 20:09:34 2023 +0200
libgomp.fortran/allocate-6.f90: Run with -fdump-tree-gimple
libgomp/
* testsuite/libgomp.fortran/allocate-6.f90: Add missing
When browsing libgomp doc, I came across
https://gcc.gnu.org/onlinedocs/libgomp/Enabling-OpenMP.html
First, I found especially the Fortran part difficult to read. Secondly,
it missed the C++ attribute syntax. And I also missed a reference to
-fopenmp-simd.
The attached patch tries to improve thi
I was recently suggesting someone to use ACC_DEVICE_TYPE; I did not point to the
documentation it only contains the title:
https://gcc.gnu.org/onlinedocs/libgomp/ACC_005fDEVICE_005fTYPE.html
Admittedly, there is also "Reference:" pointing to the OpenACC specification,
but the latter just states
On 14.10.23 22:08, Sandra Loosemore wrote:
Can we please rewrite this whole section in the present tense?
How about the following patch?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Gesch
Hi Sandra,
thanks for the comments.
On 15.10.23 00:46, Sandra Loosemore wrote:
+Semicolon separated list of dynamic libraries to be loaded as
profiling library.
s/Semicolon separated/Semicolon-separated/
There's also a semantic issue with "list of dynamic libraries"
(plural) and "profiling l
#x27;*$' Fortran fixed-form variant. I think the most
important bit is that '!$' is also supported by -fopenmp-simd as that's not
covered by the OpenMP specification.
Otherwise:
On 14.10.23 23:46, Sandra Loosemore wrote:
On 10/14/23 13:43, Tobias Burnus wrote:
The attached patc
While mkoffload ensures that there is always a -march=, nvptx's
cc1 can also be run directly.
In my case, I wanted to know which target-specific #define are
available; hence, I did run:
accel/nvptx-none/cc1 -E -dM < /dev/null
which gave an ICE. After some debugging, the reasons was
clear (missi
Yesterday, someone was confused because the signal handler did not work.
It turned out that the created Fortran procedure used as handler used
pass by reference - and 'signal' passed the it by value.
This patch adds the 'passed by value' to the wording:
"@var{HANDLER} to be executed with a sing
Hi Harald,
On 16.10.23 20:31, Harald Anlauf wrote:
Hi Tobias,
Am 16.10.23 um 19:11 schrieb Tobias Burnus:
OK for mainline?
I think the patch qualifies as obvious.
While at it, you might consider removing the comment a few lines below
the place you are changing,
@c TODO: What should the
Hi Kwok, hi Jakub, hi all,
some first comments based on both playing around and reading the
patch - and some generic comments to any patch reader.
In general, the patch looks good. I just observe:
* There is an issue with [[omp::decl(...)]]'
* () - there is a C/C++ inconsistency in
what is e
On 17.10.23 15:34, Jakub Jelinek wrote:
On Tue, Oct 17, 2023 at 03:12:46PM +0200, Tobias Burnus wrote:
C++11 (and C23) attribute do not seem to be properly handled:
[[omp::decl (declare target,indirect(1))]]
int foo(void) { return 5; }
[[omp::decl (declare target indirect)]]
int bar(void
7 00:00:00 2001
From: Tobias Burnus
Date: Tue, 17 Oct 2023 19:35:18 +0200
Subject: [PATCH] fortran/intrinsic.texi: Add 'intrinsic' to SIGNAL example
gcc/fortran/ChangeLog:
* intrinsic.texi (signal): Add 'intrinsic :: signal, sleep' to
the example to make it safer.
---
Hi Thomas,
On 18.10.23 11:44, Thomas Schwinge wrote:
No need to change anything now, but in case that's useful later:
[...]
..., just noting that '{ target c }', '{ target c++ }' are trivial to
implement; see libgomp OpenACC testing:
libgomp/testsuite/libgomp.oacc-c/c.exp:proc check_effective_t
On 18.10.23 11:36, Jakub Jelinek wrote:
On Wed, Oct 18, 2023 at 11:12:44AM +0200, Thomas Schwinge wrote:
+FAIL: gfortran.dg/gomp/allocate-13.f90 -O (internal compiler error:
tree code 'statement_list' is not supported in LTO streams)
Any references to GENERIC code in clauses etc. shoul
On 19.10.23 11:49, Andrew Stubbs wrote:
OK to commit?
(I think as maintainer you don't need approval - but of course comments
by others can be helpful; I hope mine are. Additionally, Gerald (CCed)
helps with keeping the webpages in good shape (thanks!).)
gcc-14: mark amdgcn fiji deprecated
d
uld not affect real-world users.
The XNACK feature allows memory load instructions to restart safely following
a page-miss interrupt. This is useful for shared-memory devices, like APUs,
and to implement OpenMP Unified Shared Memory.
2023-05-26 Andrew Stubbs
Tobias Burnus
handling of 'structure elements' with
allocators, https://gcc.gnu.org/PR109998
PPPS: I remarked before:
On 21.12.22 16:51, Tobias Burnus wrote:
On 14.12.22 11:47, Tobias Burnus wrote:
This patch adds parsing/argument-checking support for
'!$omp allocators allocate([align(int),allocator(a)
führer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit a899401404186843f38462c8fc9de733f19ce864
Author: Tobias Burnus
Date: Tue May 30 12:49:09 2023 +0200
OpenMP: Improve C/C++ parsing error message [PR10]
Replace
I intent to commit the attached patch soon.
However, I want to give anyone the chance to comment on any aspect before
committing. Comments after the commit are welcome as well :-)
OpenMP 5.2 now uses properties to clauses and "pure" is among those properties.
Note that pure-2.f90 contains also
he issues I noted
before;
while doing so and when adding a bunch of additional tests, I found a few
additional
issues, which have been fixed as well. Somehow, there cannot be too many
testcases ...
Tobias
See previously in this thread for my review comments and Kwok's patch remarks,
i.e.
On
Andrew: Does the GCN change look okay to you?
This patch permits to use GCN devices with 'omp requires unified_address' which
in principle works already, except that the requirement handling did disable it.
(It also updates libgomp.texi for this change and likewise for an older
likewise nvptx c
This patch fixes a corner case issue (missing list items in a map clause)
and ensures that such an issue is caught.
Committed to mainline as https://gcc.gnu.org/r14-1605-gdd958667821e38
It is a forward port of Thomas' OG12 then OG13 commit which fixed
a run-time issue which the mainline version
1e38b7d6b8efe448044901b4762b3a
Author: Tobias Burnus
Date: Wed Jun 7 13:22:13 2023 +0200
testsuite/libgomp.*/target-present-*.{c,f90}: Improve and fix
One of the testcases lacked variables in a map clause such that
the fail occurred too early. Additionally, it would have failed
tronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit 38944ec2a6fa108d24e5cfbb24c52020f9aa3015
Author: Tobias Burnus
Dat
schaft: München; Registergericht
München, HRB 106955
commit d5c58ad1ebaff924c2546df074174cffb128feb8
Author: Tobias Burnus
Date: Tue Jun 13 11:27:47 2023 +0200
libgomp/testsuite: Add requires-unified-addr-1.{c,f90} [PR109837]
Add a testcase for 'omp requires unified_address'
On 13.06.23 12:42, Thomas Schwinge wrote:
On 2023-06-05T14:18:48+0200, I wrote:
OK to push the attached
"Add 'libgomp.{,oacc-}fortran/fortran-torture_execute_math.f90'"?
Subject: [PATCH] Add
'libgomp.{,oacc-}fortran/fortran-torture_execute_math.f90'
gcc/testsuite/
* gfortran.for
I intent to commit this tomorrow, unless there are comments.
It does as it says (see commit log): It initializes default-device-var
to the value using the algorithm described in OpenMP 5.2, which
depends on whether OMP_TARGET_OFFLOAD=mandatory was set.
NOTE: With -foffload=disable there is no bi
First update for OpenMP changes that made it into GCC 14.
Wording, technical and other comments are welcome as always.
I intent to commit the attached patch tomorrow.
Tobias
PS: There were a bunch of other useful changes, but those "only" improved
and fixed features already supported or added
Now committed - with additional changes: two GCC 13 features on the
implementation-status list were missed in a previous update. Current
version:
→ https://gcc.gnu.org/projects/gomp/
→ https://gcc.gnu.org/gcc-14/changes.html (as first entry)
Tobias
On 13.06.23 20:45, Tobias Burnus wrote
On 14.06.23 10:09, Thomas Schwinge wrote:
This reminds me of the (unresolved)https://gcc.gnu.org/PR81886
"Means to determine at runtime foffload targets specified at compile time".
I think there is the problem that we also support offloading in
libraries. Thus, if you compile the main program w
On 14.06.23 10:42, Thomas Schwinge wrote:
Couldn't/shouldn't we now get rid of this 'GOMP_MAP_FLAG_PRESENT'...
...
#define GOMP_MAP_PRESENT_P(X) \
- (((X) & GOMP_MAP_FLAG_PRESENT) == GOMP_MAP_FLAG_PRESENT)
+ (((X) & GOMP_MAP_FLAG_PRESENT) == GOMP_MAP_FLAG_PRESENT \
+ || (X) == GOMP_MAP_FO
On 13.06.23 12:44, Thomas Schwinge wrote:
On 2023-06-05T14:25:18+0200, I wrote:
OK to push the attached
"driver: Forward '-lgfortran', '-lm' to offloading compilation"?
(We didn't have a PR open for that, or did we?)
(It was approved by Joseph and pushed by Thomas as r14-1807-g4bcb46b3ade179 )
Comments on the wording and/or the content?
I did notice that we missed to document three OMP_* environment
variables, hence, I added them.
(For OMP_ALLOCATOR, I expect an update once the 5.1 extensions have been
implemented.)
(Some cross references could be added if we had/once we have documen
On 14.06.23 12:34, Tobias Burnus wrote:
Comments on the wording and/or the content?
This remains — however, the attached patch now additionally lists the
predefined allocators, fixes one awkward wording of mine – and it
documents the OpenMP 5.1 syntax of the OMP_ALLOCATOR environment variable
Now committed as r14-1869-g73a0d3bf895b5c / https://gcc.gnu.org/r14-1869
Tobias
On 14.06.23 17:44, Tobias Burnus wrote:
On 14.06.23 12:34, Tobias Burnus wrote:
Comments on the wording and/or the content?
This remains — however, the attached patch now additionally lists the
predefined
t mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit 450b05ce54d3f08c583c3b5341233ce0df99725b
Author: Tobias Burnus
Date: Wed Jul 12 13:50:21 2023 +0200
libgomp: Use libnuma for OpenMP's par
4
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit 13c3e29d47e359b2f05ea98d61710fc162ba6d31
Author: Tobias Burnus
Date: Wed Jul 12 16:14:20 2023 +0200
libgomp.texi: add cross r
Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit 407d68daed00e040a7d9545b2a18aa27bf93a106
Author: Tobias
955
commit a85a106c35c6d1d9fd40627e149501e5e854bcc3
Author: Tobias Burnus
Date: Fri Jul 14 13:15:07 2023 +0200
libgomp.texi: Extend memory allocation documentation
libgomp/
* libgomp.texi (OMP_ALLOCATOR): Document the default values for
the traits. Add crossref to 'Memory allocation'.
sellschaft: München; Registergericht
München, HRB 106955
commit 89d0f082b3c95f68d116d4480126e3ab7fb7f36b
Author: Tobias Burnus
Date: Mon Jul 17 15:13:44 2023 +0200
OpenMP/Fortran: Parsing support for 'uses_allocators'
The 'uses_allocators' clause to the '
Comments regarding the validity of the Fortran assumptions are welcome!
This patch now uses a 'simple' loop for OpenMP loops with
a constant loop-step size. Before, it only did so for step = ±1.
(Otherwise, a count variable is used from which the original
loop index variable is calculated from.)
rwise, the following still applies:
On 18.07.23 14:11, Tobias Burnus wrote:
Comments regarding the validity of the Fortran assumptions are welcome!
This patch now uses a 'simple' loop for OpenMP loops with
a constant loop-step size. Before, it only did so for step = ±1.
(Otherwise, a co
z der Gesellschaft: München; Registergericht
München, HRB 106955
commit 49ad5a86615089d236ae8ee9a2b7d17db1f0c1d7
Author: Tobias Burnus
Date: Wed Jul 19 13:33:29 2023 +0200
gfortran.dg/gomp/affinity-clause-1.f90: Fix scan-tree-dump
gcc/testsuite/
* gfortran.dg/gomp/affinity-clause-
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit a9d17fbd1e918019b77a6d9616704db85b5c3e8c
A
Hi Thomas & Chung-Lin,
On 20.07.23 15:33, Thomas Schwinge wrote:
On 2023-07-11T02:33:58+0800, Chung-Lin Tang
wrote:
+++ b/gcc/c/c-parser.cc
@@ -14059,7 +14059,8 @@ c_parser_omp_variable_list (c_parser *parser,
static tree
c_parser_omp_var_list_parens (c_parser *parser, enum omp_clause_co
mation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit 506f068e7d01ad2fb107185b8fb204a0ec23785c
Author: Tobias Burnus
This patch adds diagnostic for additional code alongside a nested teams
in a target region.
The diagnostic is happening soon after parsing such that expressions
in clauses are not yet expanded - those would end up before TEAMS
and can be very complicated (e.g. assume an allocatable-returning func
On 24.07.23 21:49, Jakub Jelinek via Fortran wrote:
Thanks for working on this. The fuzzy thing on the Fortran side is
if e.g. multiple nested BLOCK statements can appear sandwiched in between
target and teams (of course without declarations in them), or if e.g.
The current patch rejects neste
Now committed as r14-2754-g2e31fe431b08b0 with a minor addition:
On 24.07.23 22:05, Tobias Burnus wrote:
The current patch rejects nested blocks, be it 'omp target; block;
block; omp teams;'
which was before in the testcase. But now also
or be it 'omp target; block; block;end b
On 24.07.23 21:49, Jakub Jelinek via Fortran wrote:
On Mon, Jul 24, 2023 at 09:43:10PM +0200, Tobias Burnus wrote:
This patch adds diagnostic for additional code alongside a nested teams
in a target region.
Thanks for working on this. The fuzzy thing on the Fortran side is
if e.g. multiple
The attached patch calls CUDA's cuMemcopy2D and cuMemcpy3D
for omp_target_memcpy_rect[,_async} for dim=2/dim=3. This should
speed up the data transfer for noncontiguous data.
While being there, I ended up adding support for device to other device
copying; while potentially slow, it is still bette
führer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit 819f3d3692cbfe69ed7861da6ef47805914bb0b8
Author: Tobias Burnus
Date: Wed Jul 26 11:52:20 2023 +0200
libgomp.texi: Add status item, @ref and document omp_in_explicit_t
itz der Gesellschaft: München; Registergericht
München, HRB 106955
commit 081e25d3cfd86c4094999ded0bbe99b91762013c
Author: Tobias Burnus
Date: Thu Jul 27 18:14:11 2023 +0200
OpenMP/Fortran: Extend reject code between target + teams [PR71065, PR110725]
The previous version failed to diag
Hi Thomas,
thanks for proof reading and the suggestions! – Do have comments to the
attached patch?
* * *
Crossref: For further optimizations, see also
https://gcc.gnu.org/PR101581 — [OpenMP] omp_target_memcpy – support
inter-device memcpy
https://gcc.gnu.org/PR110813 — [OpenMP] omp_target_memc
Now committed as r14-2865-g8b9e559fe7ca5715c74115322af99dbf9137a399
Tobias
On 28.07.23 13:51, Tobias Burnus wrote:
thanks for proof reading and the suggestions! – Do have comments to the
attached patch?
* * *
Crossref: For further optimizations, see also
https://gcc.gnu.org/PR101581
Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit 7780dc5b2d02785186583fc8eced3c9e3aec4552
Author: Tobias Burnus
Date: F
Attached is the updated patch. Main changes:
- File names shown that violate the requires-clause-must-be-same requirement
Taken from the offload_vars/funcs context (if available), otherwise
(that's no 'omp target'/'omp declare target' but just 'omp target update/data'
in the TU), the *.o fil
Needed a break and some success. Hence, I implemented this useful and simple
OpenMP 5.2
feature.
OK for trunk?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung
On 01.07.22 16:34, Jakub Jelinek wrote:
On Fri, Jul 01, 2022 at 03:06:05PM +0200, Tobias Burnus wrote:
[...]
Will Fortran diagnose:
subroutine foo
!$omp requires unified_shared_memory
!$omp target
!$omp end target
end subroutine foo
subroutine bar
!$omp requires reverse_offload
!$omp target
Updated version attached – I hope I got everything right, but I start to
get tired, I am not 100% sure.
On 01.07.22 18:55, Jakub Jelinek wrote:
Perhaps you're just lucky and the stack contains '\0' there?
Probably.
Maybe it would be better to simply use different error message for the
0 vs. no
This patch adds support for the OpenMP 5.2 syntax for the linear clause,
following the C/C++ patch. The testcases are modified versions from the
C/C++ ones, plus one added one for duplicated modifiers.
At least to me it is not quite clear when
linear ( var : ref)
refers to a variable 'ref' and
Hi Jakub,
thanks for the comment & spec referral. I have now updated the patch –
and included the new C/Fortran testcase.
On 04.07.22 16:53, Jakub Jelinek via Fortran wrote:
See OpenMP 5.2 [59:31-34]:
A modifier that is an expression must neither lexically match the name of a
simple modifier
d
On 04.07.22 19:20, Jakub Jelinek wrote:
Perhaps you could avoid some code duplication by doing it like:
bool close_paren = gfc_match ("val )") == MATCH_YES;
if (close_paren || gfc_match ("val , ") == MATCH_YES)
Done!
Good idea! I was thinking of things
Hi Thomas,
On 06.07.22 13:04, Thomas Schwinge wrote:
On 2022-06-08T05:56:02+0200, Tobias Burnus wrote:
PS: I have not fully tested the intelmic version.
As part of my standard testing, I'm reporting that it got completely
broken. ;'-)
Interesting. Because intelmic-mkoffloa
Hi Thomas,
On 06.07.22 14:38, Thomas Schwinge wrote:
:-) Haha, that's actually *exactly* what I had implemented first! But
then I realized that 'target offloading_enabled' is doing exactly that:
check that offloading compilation is configured -- not that "there is an
offloading device available
Hi Thomas,
On 06.07.22 12:30, Thomas Schwinge wrote:
On 2022-06-08T05:56:02+0200, Tobias Burnus
wrote:
[..]
To make things more failure proof, OK to push the attached
"Define 'OMP_REQUIRES_[...]', 'GOMP_REQUIRES_[...]' in a single place"?
I concur that
Hi Thomas, hello all,
On 06.07.22 12:42, Thomas Schwinge wrote:
On 2022-07-01T15:06:05+0200, Tobias Burnus
wrote:
Attached is the updated patch. Main changes: [...]
This is now a great implementation of cross-component communication
(host/offloading compilers, runtime), thanks! I'm
Hi Thomas, hello all,
On 06.07.22 13:04, Thomas Schwinge wrote:
On 2022-06-08T05:56:02+0200, Tobias Burnus
wrote:
PS: I have not fully tested the intelmic version.
...
Subject: [PATCH] Fix Intel MIC 'mkoffload' for OpenMP 'requires'
...
This also means finally
Hi Thomas, hello all,
On 07.07.22 10:37, Thomas Schwinge wrote:
In preparation for other changes:
On 2022-06-29T16:33:02+0200, Tobias Burnus wrote:
+++ b/libgomp/testsuite/libgomp.c-c++-common/requires-3.c
@@ -0,0 +1,24 @@
+/* { dg-do link { target offloading_enabled } } */
Not expected to
On 07.07.22 10:42, Thomas Schwinge wrote:
In preparation for other changes:
...
On 2022-06-29T16:33:02+0200, Tobias Burnus wrote:
+/* { dg-output "devices present but 'omp requires unified_address,
unified_shared_memory, reverse_offload' cannot be fulfilled" } */
(T
Hi Andrew,
On 07.07.22 12:34, Andrew Stubbs wrote:
Implement the -foffload-memory=pinned option such that libgomp is
instructed to enable fully-pinned memory at start-up. The option is
intended to provide a performance boost to certain offload programs without
modifying the code.
...
gcc/Chan
Hi Thomas,
On 07.07.22 15:26, Thomas Schwinge wrote:
On 2022-07-01T23:08:16+0200, Tobias Burnus
wrote:
Updated version attached – I hope I got everything right, but I start to
get tired, I am not 100% sure.
..., and so the obligatory copy'n'past-o;-) crept in:
...
+
On 08.07.22 00:18, Andrew Stubbs wrote:
Likewise, the 'requires' mechanism could then also be used in '[PATCH
16/17] amdgcn, openmp: Auto-detect USM mode and set HSA_XNACK'.
No, I don't think so; that environment variable needs to be set before
the libraries are loaded or it's too late. There
On 08.07.22 11:55, Andrew Stubbs wrote:
It's not incompatible with GCN offloading, only with the XNACK mode in
which the binary was compiled (i.e. USM on or off).
The message could be less terse, indeed. I went through a variety of
messages for this and couldn't find one that I liked. How about.
ctronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit 220bef460153a0296e947f16492d35e67b1b5b22
Author: Tobias Burnu
Hi,
On 12.07.22 13:50, Lewis Hyatt via Gcc-patches wrote:
On Tue, Jul 12, 2022 at 2:33 AM Thomas Schwinge wrote:
On 2022-07-11T11:27:12+0200, I wrote:
Oh my, PR101551 "[offloading] Differences in diagnostics etc."
strikes again... The latter two 'note' diagnostics are currently
only emitted
This patch does three things:
(a) It removes a 'sorry' for 'device(ancestor:1)' and passes
GOMP_DEVICE_HOST_FALLBACK as device number.
This is sufficient for full "reverse" offload support with ENABLE_OFFLOADING
being false - and -foffload=disable. And for simple hello-world cases.
On the
Ups to quick/wrong patch file. I had found an issue related to 'noclone'
(duplicated entries, dg-scan-dump issues with OpenACC) – but ended up to
attach the wrong file... Changes: omp-low.cc and
gcc/testsuite/*/goacc/. The rest is the same.
Tobias
On 21.07.22 12:55, Tobias Burnus wr
As is, it is only a cleanup/consistency patch.
However, I did run into this issue when working on the reverse-offload
implementation (to handle reverse lookups of vars and functions).
OK for mainline?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 20
This patch addresses a corner case which causes a filename
confusion:
lto1: error: OpenMP 'requires' directive with 'unified_address' specified
only in some compilation units
lto1: note: '1.c' has 'unified_address'
lto1: note: but '1.c' has not
lto1: fatal error: errors during merging of
Hi all,
On 05.05.22 11:12, Jakub Jelinek via Gcc-patches wrote:
→ https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594082.html
On Wed, Mar 09, 2022 at 07:04:24PM +0800, Chung-Lin Tang wrote:
→ https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591449.html
Now in OpenMP 5.x, static members
Testcase wise, the run-time testcase libgomp.fortran/examples-4/simd-2.f90
checks essentially the same, except that it uses an array-descriptor array
(assumed shape) while this testcase uses an assumed-size array.
I decided for an extra compile-time only testcase, but it could be also be
moved to
On 29.07.22 10:03, Jakub Jelinek wrote:
There were 2 issues visible on this new testcase, one that we didn't have
special POINTER_TYPE_P handling in a few spots of expand_omp_simd ...
The other issue was that we put n2 expression directly into a
comparison in a condition and regimplified that, fo
Rather obvious fix and similar to PR106449.
OK for mainline and backporting (how far?). I would like to backport it
at least to GCC 12.
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäft
On 04.08.22 09:32, Tobias Burnus wrote:
Rather obvious fix and similar to PR106449.
OK for mainline and backporting (how far?). I would like to backport
it at least to GCC 12.
Now committed as obvious:
https://gcc.gnu.org/g:r13-1997-g8a16b9f983824b6b9a25275cd23b6bba8c98b800
I intent to
Hi,
your GCC 13 commit
https://gcc.gnu.org/r13-7720-g0fa76e35a5f9e1 x86: Update model values for
Raptorlake.
causes a build fail:
gcc/common/config/i386/cpuinfo.h: In function ‘const char*
get_intel_cpu(__processor_model*, __processor_model2*, unsigned int*)’:
gcc/common/config/i386/cpuinfo.h
, HRB 106955
commit 8f3c4517b1fff965f2bdedcf376dcfd91cda422b
Author: Tobias Burnus
Date: Thu Aug 17 15:20:55 2023 +0200
libgomp: call numa_available first when using libnuma
The documentation requires that numa_available() is called and only
when successful, other libnuma functio
Hello Thiago,
the patch looks good to me. Thanks! Can you commit the patch yourself or
do you need someone to do this for you?
On 15.08.23 18:17, Thiago Jung Bauermann via Gcc-patches wrote:
Thiago Jung Bauermann writes:
Commit 92d1425ca780 "c++: redundant targ coercion for var/alias tmpls"
This patch fixes a bug with an OpenMP non-rectangular loop nest where the
factor is 0.
With the old code before r12-5295-g47de0b56ee455e, the testcase of the
PR (or included in the attached patch) worked fine. omp-expand.c contained
back then:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/omp-e
Hello Thiago,
On 18.08.23 23:24, Thiago Jung Bauermann wrote:
Tobias Burnus writes:
the patch looks good to me. Thanks! Can you commit the patch yourself or
do you need someone to do this for you?
Thank you! I don't have commit access, so I would need someone to do
this for me.
Don
1 - 100 of 3670 matches
Mail list logo
