Prior to the attached patch, there is a problem with realloc on assignment
with kind=4 characters as the string length was compared with the byte size,
which was always true.
I initially thought, looking at the code, that scalars have the same issues,
but they don't; hence, I ended up with a
On 03.11.22 13:44, Jakub Jelinek wrote:
[...]
Otherwise LGTM, assuming it actually works correctly.
I don't remember support for non-contiguous copying to/from devices
being actually added, [...] And I think it is not ok to copy bytes
that aren't requested to be copied.
I have now removed
This fixes some an issue with 'alloc:' found when working on the patch
'[Patch] OpenMP/Fortran: 'target update' with strides + DT components'
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604687.html
(BTW: This one is still pending review.)
OK for mainline?
* * *
I think the patch is
I recently saw that gfortran does not support derived type components
with 'target update', an OpenMP 5.0 feature.
When adding it, I also found out that strides where not handled. There
is probably some room of improvement about what to copy and what not,
but copying too much should be fine.
Hi Julian,
I had a first quick lock at this patch, I should have a closer look
later. However, I stumbled over the following:
On 20.10.22 18:14, Julian Brown wrote:
typedef struct gfc_symbol
{
...
struct gfc_symbol *old_symbol;
unsigned mark:1, comp_mark:1, data_mark:1, dev_mark:1,
Hi Tobias!
On 24.10.22 21:11, Thomas Schwinge wrote:
On 2022-10-24T21:05:46+0200, I wrote:
On 2022-10-24T16:07:25+0200, Jakub Jelinek via Gcc-patches
wrote:
On Wed, Oct 12, 2022 at 10:55:26AM +0200, Tobias Burnus wrote:
libgomp/nvptx: Prepare for reverse-offload callback handling
Well
cc.gnu.org/pipermail/gcc-patches/2022-September/601959.html (I
think 'target nowait' permits what he thinks is the better way for GPUs.)
Tobias
On 18.10.22 21:27, Tobias Burnus wrote:
Found when playing around with reverse offload once I used 'omp target
parallel'.
The other issue showed up wh
; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit 807b755357c4eb03260d229f4a851009fe058e51
Author: Tobias Burnus
Date: Thu Oct 20 19:20:36 2022 +0200
omp-oacc-kernels-decompose.cc: fix -fcompare-debug with GIMPLE_DEBUG
GIMPLE_DEBUG were put in a paral
955
commit 0c47ae1c9283a812f832e80e451bfa82519c21e8
Author: Tobias Burnus
Date: Thu Oct 20 13:25:25 2022 +0200
libgomp.c-c++-common/requires-4.c: dg-xfail-run-if for USM with -foffload-memory=
The USM implementation uses -foffload-memory=... which allocates variables
in a special memory.
; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit 0d6fc5032c7ba8a95301d0ccbc418875e73955ac
Author: Tobias Burnus
Date: Wed Oct 19 17:31:14 2022 +0200
Fix omp-expand.cc's expand_omp_target for OpenACC
In OG12 commit
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 76b773a4a2d1daf0b83e50cd999bc38f8dd047be
Author: Tobias Burnus
Date:
First, I am woefully aware that there several patches pending. I hope to do a
couple of reviews later today or in the next days.
Otherwise, I did run into another issue in existing code which was exposed by
the delinearization patch on the OG12 branch, but could potentially lead to
wrong code on
Found when playing around with reverse offload once I used 'omp target
parallel'.
The other issue showed up when running the testsuite (which is done with -O2).
In all cases, the ICE is in expand_GOMP_TARGET_REV of this IFN, which should
be unreachable
Note: ENABLE_OFFLOADING inside the
On 12.10.22 16:05, Tobias Burnus wrote:
This came up because the USM implementation with
-foffload-memory={unified,pinned}
as posted at
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/597976.html
does not handle USM with static variables.
This shows up for the OG12 alias devel/omp/gcc-12
On 12.10.22 10:55, Tobias Burnus wrote:
On 11.10.22 13:12, Alexander Monakov wrote:
My understanding is such trickery should not be necessary with
the barrier-based approach, i.e. the sequence of PTX instructions
st % plain store
membar.sys
st.volatile
should be enough
Long introduction - but the patch is rather simple: Don't use kind=1
as type where kind=4 should be used.
Long introduction + background, feel free to skip.
This popped up for libgomp/testsuite/libgomp.fortran/struct-elem-map-1.f90
which uses kind=4 characters
beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit 3760dd553eed21ac5614cf0d0841ca984b4361e2
Author: Tobias Burnus
Date: Fri Oct 14 18:34:49 2022 +0200
gfortran.dg/c-interop/deferred-character-2.f90
Rather obvious patch as it is a straight conversion from C.
OK for mainline?
Tobias
-
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
On 12.10.22 19:09, Andrew Stubbs wrote:
On 12/10/2022 15:29, Tobias Burnus wrote:
Right, sorry, the buffer is circular, but the counter is linear. It
simplified reservation that way, but it does mean that there's a limit
to the number of times the buffer can cycle before the counter
saturates
On 29.09.22 18:24, Andrew Stubbs wrote:
On 27/09/2022 14:16, Tobias Burnus wrote:
Andrew did suggest a while back to piggyback on the console_output
handling,
avoiding another atomic access. - If this is still wanted, I like to
have some
guidance regarding how to actually implement
This came up because the USM implementation with
-foffload-memory={unified,pinned}
as posted at https://gcc.gnu.org/pipermail/gcc-patches/2022-July/597976.html
does not handle USM with static variables.
This shows up for the OG12 alias devel/omp/gcc-12 branch as FAIL for
requires-4.c.
The
__attribute__((unused)))
diff --git a/libgomp/config/nvptx/libgomp-nvptx.h b/libgomp/config/nvptx/libgomp-nvptx.h
new file mode 100644
index 000..5da9aae
--- /dev/null
+++ b/libgomp/config/nvptx/libgomp-nvptx.h
@@ -0,0 +1,51 @@
+/* Copyright (C) 2022 Free Software Foundation, Inc.
+ Contribu
On 11.10.22 16:15, Jakub Jelinek wrote:
I think the most common case is:
integer, allocatable :: var(:)
!$omp allocators allocator(my_alloc) ! must be in same scope as decl of 'var'
...
! optionally: deallocate(var)
end ! of scope: block/subroutine/... - automatic deallocation
So you talk
Hi Jakub,
On 11.10.22 14:24, Jakub Jelinek wrote:
There is another issue besides what I wrote in my last review,
and I'm afraid I don't know what to do about it, hoping Tobias
has some ideas.
The problem is that without the allocate-stmt associated allocate directive,
Fortran allocatables are
up
OK for mainline?
Tobias
On 02.10.22 20:13, Tobias Burnus wrote:
On 27.09.22 11:23, Tobias Burnus wrote:
We do support
#if __PTX_SM__ >= 600 (CUDA >= 8.0, ptx isa >= 5.0)
and we also can configure GCC with
--with-arch=sm_70 (or sm_80 or ...)
Thus, adding atomics with .sys scope is
On 06.10.22 14:17, Jakub Jelinek wrote:
On Thu, Oct 06, 2022 at 12:55:01PM +0200, Tobias Burnus wrote:
I don't know whether it makes sense to handle – in the long run – the
case of se.pre/se.post being nonempty – and, if so, how.
I think it is essential not to throw those away,
if se.pre
Same as for C/C++, albeit a tiny bit longer patch.
I don't know whether it makes sense to handle – in the long run – the
case of se.pre/se.post being nonempty – and, if so, how.
OK for mainline?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201,
On 05.10.22 20:41, Martin Liška wrote:
+++ b/contrib/gcc-changelog/git_update_version.py
@@ -127,6 +127,7 @@ def update_current_branch(ref_name):
repo.git.add(datestamp_path)
if not args.current:
repo.index.commit('Daily bump.')
+
Minor update to just posted patch: the table did not revert all strings where a
substring directive name existed, i.e. 'target' vs. 'target update', 'assume'
vs. 'assumes'. Now fixed. Otherwise unchanged:
Tobias
On 05.10.22 13:19, Tobias Burnus wrote:
Hi Jakub,
On 04.10.22 14:58, Jakub
Hi Jakub,
On 04.10.22 14:58, Jakub Jelinek via Gcc-patches wrote:
On Tue, Oct 04, 2022 at 02:26:13PM +0200, Tobias Burnus wrote:
On Sun, Oct 02, 2022 at 07:47:18PM +0200, Tobias Burnus wrote:
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
OK?
Ok, thanks.
Committed as
https
Hi Jakub,
On 04.10.22 12:19, Jakub Jelinek wrote:
On Sun, Oct 02, 2022 at 07:47:18PM +0200, Tobias Burnus wrote:
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -2749,9 +2749,9 @@ have support for @option{-pthread}. @option{-fopenmp}
implies
@opindex fopenmp-simd
@cindex OpenMP SIMD
On 30.09.22 10:00, Tobias Burnus wrote:
That's for https://gcc.gnu.org/install/specific.html
...
* doc/install.texi (Specific): Add missing items to bullet list.
(amdgcn): Update LLVM requirements, use version not date for newlib.
(nvptx): Use version not git
On 27.09.22 11:23, Tobias Burnus wrote:
We do support
#if __PTX_SM__ >= 600 (CUDA >= 8.0, ptx isa >= 5.0)
and we also can configure GCC with
--with-arch=sm_70 (or sm_80 or ...)
Thus, adding atomics with .sys scope is possible.
See attached patch. This seems to work fine and I h
This patch adds '!$omp assume' and '!$omp assumes' support.
None of the directives is used after resolution.
When we actually start using for 'assumes', it has to be stored in .mod
files. The other question is how to handle 'holds()' expressions with 'assumes'.
-fopenmp-simd: I used a longer
On 30.09.22 15:30, Julian Brown wrote:
On Fri, 23 Sep 2022 14:10:51 +0200 Tobias Burnus
<mailto:tob...@codesourcery.com> wrote:
...
I added n->expr->expr_type == EXPR_VARIABLE to the condition -- I think
that should suffice for now?
Yes.
A similar mean way to write code would
Hi Julian,
On 30.09.22 15:30, Julian Brown wrote:
i = 1; j = 2
map (foo(i)%dt_ptr(1:3), foo(j)%dt_ptr)
Good catch! In that gfc_dep_resolver considers those terms to have a
dependency, and that triggers the mapping node transformation. But I
don't think OpenMP allows you to write this:
Hi Jakub,
On 30.09.22 13:04, Jakub Jelinek via Fortran wrote:
On Fri, Sep 30, 2022 at 12:41:19PM +0200, Tobias Burnus wrote:
And 'device(omp_initial_device)' printed a warning in Fortran.
(BTW: C/C++ silently accepts any negative value.)
I think that is what the standard wants.
E.g. in 5.2
On 30.09.22 12:41, Tobias Burnus wrote:
Fortran: Update use_device_ptr for OpenMP 5.1 [PR105318]
The following two lines slipped in – which I have now removed in my version of
the patch:
--- a/gcc/testsuite/gfortran.dg/gomp/is_device_ptr-1.f90
+++ b/gcc/testsuite/gfortran.dg/gomp
While has_device_addr has been implemented (in GCC 12), updating
use_device_ptr for Fortran was missed.
This patch fixes it: Removing the restrictions and mapping to
has_device_addr where applicable.
For use_device_ptr something similar was done, albeit I think
this has no semantic effect.
And
That's for https://gcc.gnu.org/install/specific.html
[I did notice (just before submitting) that the bullet list
was incomplete - hence, I added it. (Also one ref missed a '-x'.)
However, main reason for this patch is for GCN:]
The listed LLVM version for GCN was outdated.
For newlib, I also
On 29.09.22 14:59, Julian Brown wrote:
On Wed, 28 Sep 2022 17:17:30 +0200 Tobias Burnus
wrote:
I don't see immediately whether some cases can still reach
omp_accumulate_sibling_list – if so, a testcase would be nice, or
whether that error_at can now be removed.
This version of the patch
On 29.09.22 09:06, Jakub Jelinek wrote:
My recent change to enable _Float{16,32,64,128,32x,64x,128x} for C++
apparently broke bootstrap on some Debian/Ubuntu setups.
Those multiarch targets put some headers into
/usr/include/x86_64-linux-gnu/bits/ etc. subdirectory instead of
/usr/include/bits/.
On 28.09.22 15:20, Julian Brown wrote:
This patch fixes an ICE when both a complete struct variable and
components of that struct are mapped on the same directive for OpenACC,
using a modified version of the scheme used for OpenMP in the following
patch [...]
Tested with offloading to NVPTX. OK?
Hi Paul-Antoine, hi all,
On 28.09.22 15:47, Paul-Antoine Arras wrote:
Here is a revised patch resulting from your comments.
The only issue that I could not easily fix is the following code
triggering an ICE: [...]
I filed a PR on Bugzilla:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107067
Is
: Tobias Burnus
Date: Wed Sep 28 10:24:58 2022 +0200
libgomp.texi: Status 'P' for 'assume', remove duplicated line
libgomp/
* libgomp.texi (OpenMP 5.1): Mark 'assume' as implemented
for C/C++. Remove duplicated 'begin declare target' entry.
---
libgomp
The attached patch documents the new nvptx configure flag --with-arch=sm_...
Comments? OK?
Tobias
-
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;
For those without a working crystal ball, I have now also included the patch.
On 27.09.22 15:15, Tobias Burnus wrote:
This patch adds support to handle reverse offload to libgomp's plugin-gcn.c and
to AMD GCN's libgomp target.c.
In theory, that's all whats needed for GCN – in practice
This patch adds support to handle reverse offload to libgomp's plugin-gcn.c and
to AMD GCN's libgomp target.c.
In theory, that's all whats needed for GCN – in practice there a known issue
with
private stack variables which has to be addressed independently. Once this and
the target.c generic
expanded and improved.
For this feature, I did not add any wording in this patch: until the feature
is actually enabled, it would be more confusing than helpful.
On Mon, 26 Sep 2022, Tobias Burnus wrote:
In theory, compiling with "-m32 -foffload-options=-m64" or "-m32
-foffload-opt
100644
index 000..9fd1b27
--- /dev/null
+++ b/libgomp/config/nvptx/libgomp-nvptx.h
@@ -0,0 +1,52 @@
+/* Copyright (C) 2005-2022 Free Software Foundation, Inc.
+ Contributed by Tobias Burnus .
+
+ This file is part of the GNU Offloading and Multi Processing Library
+ (libgomp).
+
+
Hi Richard,
On 26.09.22 10:32, Richard Biener wrote:
On Fri, Sep 23, 2022 at 5:25 PM Tobias Burnus
<mailto:tob...@codesourcery.com> wrote:
This fixes a tree-sharing ICE. It seems as if all unshare_expr
I added were required in this case. [...]
looks like v1/v2/v3 are now unshared
This fixes a tree-sharing ICE. It seems as if all unshare_expr
I added were required in this case. The first long testcase is
based on the real testcase from the OpenACC testsuite, the second
one is what reduction produced - but I thought some nested reduction
might be interesting as well; hence,
Hi Julian and Jakub, hi all,
On 23.09.22 09:29, Julian Brown wrote:
How about this version? (Re-tested.)
[...]
* * *
Some more generic (pre)remarks – not affecting the patch code,
but possibly the commit log message:
This follows OMP 5.0, 2.19.7.1 "map Clause":
which is also in "OMP 5.2,
Hello Paul-Antoine, hi all,
On 21.09.22 23:18, Paul-Antoine Arras wrote:
Here is a patch that fixes an ICE in gfortran triggered by an invalid end
statement at the end of an OMP metadirective:
Remark for other reads of this email: This only applies to OG12 as mainline
does not have the
Hi Martin,
On 20.09.22 14:24, Martin Liška wrote:
On 9/20/22 14:17, Tobias Burnus wrote:
Instead of removing the links, can we rather replace it by an updated link?
[...]
Thanks for the archeological work you did.
Sure, what about the suggested patch?
LGTM. Thanks!
Tobias
Hi Martin,
On 20.09.22 14:02, Martin Liška wrote:
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
@@ -455,9 +455,7 @@ version 2.6, @uref{https://www.openacc.org/}). See
The Fortran 95 standard specifies in Part 2 (ISO/IEC 1539-2:2000)
varying length character strings.
In several cases, one just wants to have the address where an object starts
without requiring the detour via 'c_loc' and the (locally) required 'target'
attribute.
In principle, type(*),dimension(*) of TS29113 permits this, except that
'dimension(*)' only permits arrays and array elements but
On 13.09.22 23:04, Julian Brown wrote:
This patch implements OpenMP 5.0 "declare mapper" support for C++.
And to complete list of patches belonging to this set, Julian had posted
the associated Fortran patch set in June:
[PATCH 0/6] OpenMP 5.0: Fortran "declare mapper" support
hen; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit eec36f27c3ca85d3b6b469e7161b63b69a5823ac
Author: Tobias Burnus
Date: Tue Sep 13 09:08:57 2022 +0200
libgomp.texi: move i
is not
yet enabled, even with this patch.
On 26.08.22 11:07, Tobias Burnus wrote:
PRE-REMARK
As nvptx (and all other plugins) returns <= 0 for
GOMP_OFFLOAD_get_num_devices if GOMP_REQUIRES_REVERSE_OFFLOAD is
set. This patch is currently still a no op.
The patch is almost stand alone, exc
On 09.09.22 17:36, Jakub Jelinek wrote:
Wonder if we instead shouldn't arrange for silent request for no PTX
offloading (or one with warning?) if sm_30 and reverse offload is needed.
Error might be too harsh, the program can still offload to GCN or host
just fine...
Attached patch now
This patch is about the OpenMP 5.{1,2} implementation status.
For omp/ompx/omx, I think it was a bit misleading. omp/ompx (and omx)
are reserved namespaces; for 'omp' nothing needs to be done (either
already implemented or not), while for 'ompx'/'omx' (vendor extension),
the note + footnote
On 09.09.22 12:16, Richard Biener wrote:
On Fri, 9 Sep 2022, Tobias Burnus wrote:
-funsafe-math-optimizations implies -fno-signed-zeros, -fno-trapping-math,
-fassociative-math,
and -freciprocal-math. All of them reduce precision and my violate IEEE or
ISO/language standards.
However, I think
On 09.09.22 10:10, Andrew Stubbs wrote:
On 08.09.22 22:38, Kwok Cheung Yeung wrote:
The instructions for the transcendental functions are documented to have
limited numerical precision, so they are only used if unsafe_math_optimizations
are enabled for now.
-funsafe-math-optimizations implies
/2022-August/600490.html
Backlog:
On 16.08.22 19:28, Tobias Burnus wrote:
* [Patch] OpenMP, libgomp, gimple: omp_get_max_teams, omp_set_num_teams, and
omp_{gs}et_teams_thread_limit on offload devices
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599278.html
[Depends on just-reviewed
; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit d6582c662ca0da05c74fa3183e1bc2cadcb21424
Author: Tobias Burnus
Date: Tue Sep 6 10:02:13 2022 +0200
Fix Fortran/openmp: Partial OpenMP 5.2 doacross
This removed
On 03.09.22 10:07, Jakub Jelinek wrote:
The following patch implements part of the OpenMP 5.2 changes related
to ordered loops ...
Fortran bits to it attached.
OK for mainline?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München;
Update the OpenMP status for features that were added in the last months.
Comments/suggestions? Okay to commit?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Slightly revised version, fixing some issues in mkoffload.cc. Otherwise, the
same applies:
On 25.08.22 19:30, Tobias Burnus wrote:
On 25.08.22 16:54, Tobias Burnus wrote:
The attached patch prepare for reverse-offload device->host
function-address lookup by requesting (if needed) the on-dev
I had this patch lying around since about half a year. I did tweak and
agumented it
a bit today, but finally want to get rid of it (locally - by getting it
committed) ...
This patch changes -misa to -march for nvptx (the latter is now an alias
for the former), it adds a new section about
(Patch + RFC.)
OpenMP 5.2 has 'ompx' and (for fixed source form Fortran) 'omx'
as sentinel to provide a defined namespace for vendor extensions.
The behavior when encountering an unknown directive with ompx/omp sentinel
(or an unknown clause with ompx_ prefix) is implementation defined. For
I did run into some issues related to this; those turned out to be
unrelated, but I end ended up implementing this feature.
Side remark: 'omp parallel workshare' seems to actually permit 'nowait'
now, but I guess that's an unintended change due to the
syntax-representation change. Hence, it is
For reverse-offload data handling, we need to support:
(a) device fn addr -> host fn address
(b) finding already mapped host -> device vars via their device address
For (a), the functions addrs, we need some extra code (cf. previous patches)
as this information does not exist already. For (b),
@Tom and Alexander: Better suggestions are welcome for the busy loop in
libgomp/plugin/plugin-nvptx.c regarding the variable placement and checking
its value.
PRE-REMARK
As nvptx (and all other plugins) returns <= 0 for
GOMP_OFFLOAD_get_num_devices if GOMP_REQUIRES_REVERSE_OFFLOAD is
set. This
On 25.08.22 16:54, Tobias Burnus wrote:
The attached patch prepare for reverse-offload device->host
function-address lookup by requesting (if needed) the on-device address.
This patch adds the actual implementation for NVPTX.
Having array[] = {fn1,fn2}; works with nvptx only since sm
On 25.08.22 16:54, Tobias Burnus wrote:
The attached patch prepare for reverse-offload device->host
function-address lookup by requesting (if needed) the on-device address.
This patch adds the actual implementation for GCN. A variant would be
to only generate .offload_func_table ins
Technically, this patch is stand alone, but conceptually it based on the
submitted but not reviewed patch:
"[Patch] OpenMP: Support reverse offload (middle end part)"
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598662.html
With that patch, for reverse offloads ('omp target
Dear Harald,
On 23.08.22 22:29, Harald Anlauf via Fortran wrote:
the simplification of the size of an array with a bad decl
should not be successful. Improve the error recovery for
such a situation.
[...]
Regtested on x86_64-pc-linux-gnu.
The PR is marked as a 12/13 regression. Will
This patch is about error diagnostic + an ICE for invalid code.
Before the patch, gfortran/f951 showed:
...
Error: 'ancestor' device modifier not preceded by 'requires' directive with
'reverse_offload' clause
18 | end block
| 1
Error: Expecting END PROGRAM statement at (1)
gfortran:
And the same for depend-6.f90, which was obviously copied from depend-4.f90.
Committed as
https://gcc.gnu.org/r13-2152-gf05e3b2c63f3307ba405900f1a80c25b2e87b0a3
On 23.08.22 12:34, Tobias Burnus wrote:
Not really crucial as it is a compile-time test, but there was an off-by-one
typo:
!$omp
; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit 6b2a584ed5bed1b851ee7b4668ac705f20cbb2c4
Author: Tobias Burnus
Date: Tue Aug 23 12:31:43 2022 +0200
gfortran.dg/gomp/depend-4.f90: Minor fix
gcc/testsuite/
* gfortran.dg/gomp/depend-4.f90
I saw that files such as /tmp/ccxFKYeS.target.o kept accumulating. Not a high
number,
but still several.
I turned out that when compiling an offloading program successfully, they were
removed.
But when it failed, those remained. (Example: See PR.)
This patch fixes this by storing the file
Rather obvious, once found. I forgot to add some cleanup, cluttering
/tmp with ".mkoffload.omp_requires".
The same issue exists for GCN also for ".mkoffload.dbg"
OK for mainline? – For the dbg issue, OK also for GCC 11 and 12 backport?
Follow-up to the 'OpenMP: Move omp requires checks to
On 17.08.22 15:09, Jakub Jelinek wrote:
On Tue, Aug 16, 2022 at 04:45:07PM +0200, Tobias Burnus wrote:
Fortran: OpenMP fix declare simd inside modules and absent linear step
[PR106566]
...
LGTM.
+! { dg-final { scan-tree-dump-times "__attribute__\\(\\(omp declare simd
\\(linear\\(
On 16.08.22 16:31, Jakub Jelinek via Gcc-patches wrote:
The following patch is a revival of the
https://gcc.gnu.org/legacy-ml/gcc-patches/2014-10/msg00771.html
patch. While trunk configured against recent glibc and with linker
--as-needed support doesn't really need to link against -lquadmath
I would like to ping the following OpenMP patches.
First two non-pings but just RFC:
- "Restore 'GOMP_offload_unregister_ver' functionality"
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/597918.html
* QUESTION: See 'assert' question in email exchange
(linked email message + emails
The testcase is just a copy of linear-1 with 'omp ... for' replaced by 'omp ...
for simd',
matching what the PR report referred to.
The problem occurs for 'omp ... for simd linear( i : step)' when 'step' is a
variable
when a omp_fn... is generated - as in this case, the original variable is
Fixed subject line: "absent linear" should be "absent linear step" in the
subject line;
i.e. with "step" added: "Fortran: OpenMP fix declare simd inside modules and absent
linear step [PR106566]"
I have also decided to move the 'step = 1' to openmp.cc, which also set it
before with
the old
This patch fixes two issues – the first was reported to me by email but it
also shows up in the official OpenMP examples (see PR).
Namely: Inside a module, 'gfc_match(" ( %s )")' fails as the symbol is already
host associated. (The symbol is the current procedure name.)
Solution: Match with
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
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;
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,
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
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
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
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
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 wrote
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
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
; 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 Burnus
Date: Tue Jul 12 11:10:50
501 - 600 of 3364 matches
Mail list logo
