Rather obvious fix. Hence, I intent to commit it later as obvious,
unless there are any comments.
Tobias
PS: Thanks goes to Thomas for finding + reporting the issue.
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit
Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit d1e0575fdc9216f96c4f88f9f41a25b854300c0b
Author: Tobias Burnus
Date: Fri Jan 27 09:13:16 2023 +0100
gomp/declare-variant-1*.f90: Update for Windows
Hi Jakub, hi all,
updated patch included, i.e. avoiding 'count' for 'j' when a 'j.0' would
do (i.e. only local var without the different step calculation). I also
now reject if there is a non-unit step on the loop using an outer var.
Eventually still to be done: replace the 'sorry' by working
I stumbled over a new FAIL (regression) in sollve_vv today, which was due to an
odd corner case (see commit log for a description).
The mentioned in-scan error is tested for in gomp/loop-2.f90 ("'inscan'
REDUCTION
clause on construct other than DO, SIMD, DO SIMD, PARALLEL DO, PARALLEL DO
On 22.01.23 02:45, Gerald Pfeifer wrote:
Maybe, but the question is what to use? The project's webpage has on the
first page: "patch submissions to Newlib" and "automate the testing of
newlib".
I also dug into the newlib web page and other sources and - while my
personal preference slightly
n, HRB 106955
commit a18af43b161b6ff4ea6e3aaf08dd72cbacb53a89
Author: Tobias Burnus
Date: Mon Jan 23 09:55:18 2023 +0100
OpenMP: Update gcc-13/changes + projects/gomp
* htdocs/gcc-13/changes.html: Improve wording; mention nvptx reverse
offload; add 'some' to Fortran non-rect-loop support.
: 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 20552407ae11b61fccb46b3e96a8814e790254e7
Author: Tobias Burnus
Date: Mon Jan 23 09:40:41 2023 +0100
Hi Gerald,
On 21.01.23 12:58, Gerald Pfeifer wrote:
Is it maybe a little tough to bump the minimal requirement to something
only released yesterday? Or is this not an issue looking at the use cases?
(Genuine question. Maybe nothing to worry at all.)
On the technical side, the newer newlib
On 21.01.23 13:48, Gerald Pfeifer wrote:
Just one question: Does "all clauses are now accepted" refer to
- all (as in 100% of possible clauses), or
- all (as in a special kind of clause)?
The former – besides the listed 'unified_shared_memory',
'unified_address' and 'reverse_offload'
A new newlib version has been realized yesterday: newlib-4.3.0 (yearly snapshot)
https://sourceware.org/pipermail/newlib/2023/020141.html
https://sourceware.org/ftp/newlib/index.html → 2023-01-20:
newlib-4.3.0.20230120.tar.gz (8.8 MB)
For both nvptx and GCN, the new version is recommended -
This is all about non-rectangular loop nests in OpenMP.
The attached patch depends on the obvious fix for https://gcc.gnu.org/PR108459,
which is together with a nice testcase in Jakub's WIP patch attached to the PR;
without, gfortran.dg/gomp/canonical-loop-1.f90 fails with an ICE (segfault).
My
Reported by nightstrike, who also tested this patch.
On Windows, we call system() which works as described at
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/system-wsystem?view=msvc-170
Namely, it only fails with "-1" if the command interpreter
could not be started.
Hi Gerald,
On 16.01.23 23:16, Gerald Pfeifer wrote:
On Mon, 16 Jan 2023, Tobias Burnus wrote:
requires_offload, unified_address
- and unified_shared_memory clauses cause that the
- only available device is the initial device (the host). Fortran now
Hi Gerald,
On 14.01.23 22:47, Gerald Pfeifer wrote:
I made a couple of incremental edits. See below for what I just pushed
(and please speak up if you see any issues).
commit 2f870cba58c81449beb618a9030824360a25
...
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@
First, I messed up the PR number – it should be PR107706.
On 12.01.23 11:39, Jakub Jelinek wrote:
On Thu, Jan 12, 2023 at 11:22:40AM +0100, Tobias Burnus wrote:
Rather obvious fix for that ICE.
Comments? If there are none, I will commit it later as obvious.
I think the spec should
Rather obvious fix for that ICE.
Comments? If there are none, I will commit it later as obvious.
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank
Hi,
On 11.01.23 10:18, Jakub Jelinek via Gcc-patches wrote:
As reported in the PR, the FUNCTION_TYPE for __builtin_realloc in the
Fortran FE is wrong since r0-100026-gb64fca63690ad [...]
I went through all other changes from that commit and found that
__builtin_sincos{,f,l} got broken as well,
Hi all, hello Jakub,
Below is the updated list to last ping,
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607178.html
NOTE to the list below: I have stopped checking older patches. I know
some more are pending review, others need to be revised. I will re-check,
once the below listed
This patches is the ME part to support OpenMP 5.0's deep-mapping
feature, i.e. mapping allocatable components of Fortran's derived types
automatically. [Not the lang hooks but allocatate-array part will probably
also be useful when later adding 'iterator'-modifier support to the
'map'/'to'/'from'
On 25.11.22 03:13, Sandra Loosemore wrote:
This patch is a followup to my not-yet-reviewed patch
[PATCH v4] OpenMP: Generate SIMD clones for functions with "declare
target"
That patch got reviewed and went into mainline on Nov 15, 2022 as
/pipermail/gcc-patches/2022-December/608404.html
On 14.12.22 11:47, Tobias Burnus wrote:
This patch adds parsing/argument-checking support for
'!$omp allocators allocate([align(int),allocator(a) :] list)'
This follow-up patch additionally adds parsing support for both
declarative and allocate-stmt
On 19.12.22 11:51, Tobias Burnus wrote:
On 19.12.22 10:26, Tobias Burnus wrote:
And here is a more light-wight variant, suggested by Nightstrike:
Using '.' instead of creating a new directory - and checking for
__WIN32__ instead for __MINGW32__.
[...]
I have now updated the heavy version
On 19.12.22 10:26, Tobias Burnus wrote:
And here is a more light-wight variant, suggested by Nightstrike:
Using '.' instead of creating a new directory - and checking for
__WIN32__ instead for __MINGW32__.
The only downside of this variant is that it does not check whether
"close(10,s
As discussed in #gfortran IRC, on Windows opening a directory fails with
EACCESS.
(It works under Cygwin - nightstrike was so kind to test this.)
Additionally, '[ -d dir ] || mkdir dir' is also not very portable.
Hence, I use an auxiliary C file calling the POSIX functions and
expect a fail
ith EISDIR/errno == 21.
On 19.12.22 10:09, Tobias Burnus wrote:
As discussed in #gfortran IRC, on Windows opening a directory fails
with EACCESS.
(It works under Cygwin - nightstrike was so kind to test this.)
Additionally, '[ -d dir ] || mkdir dir' is also not very portable.
Hence, I use an auxili
Seems to be a CUDA JIT issue - which is fixed by adding a dummy procedure.
Lightly tested with 4 systems at hand, where 2 failed before. One had 10.2 and
the other had some ancient CUDA where 'nvptx-smi' did not print a CUDA version
and requires -mptx=3.1.
(I did check that offloading indeed
hes.txt
@@ -3636,3 +3636,99 @@ index 000..d75da75
--
2.38.1
+=== 0001-Auto-Add-File.patch
+From e205ec03f0794aeac3e8a89e947c12624d5a274e Mon Sep 17 00:00:00 2001
+From: Tobias Burnus
+Date: Thu, 15 Dec 2022 12:25:07 +0100
+Subject: [PATCH] libgfortran's ISO_Fortran_binding.c: Use GCC11 ve
Another backward compatibility issue - failed here on Ubuntu 20.04 which
is old but not ancient.
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
Hi,
On 15.12.22 20:42, Tobias Burnus wrote:
If the libgomp plugin doesn't request special
'host_to_dev_cpy'/'dev_to_host_cpy' for 'gomp_target_rev', then standard
'gomp_copy_host2dev'/'gomp_copy_dev2host' are used, which use
'gomp_device_copy', which expects the device to be locked. (As can
Hi,
I have not fully tried to understand it, yet.
(A) Regarding the issue of stalling, see als Andrew's patch and the
discussion about it in
"[PATCH] libgomp: fix hang on fatal error",
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603616.html
and in particular Jakub's two replies.
This patch adds parsing/argument-checking support for
'!$omp allocators allocate([align(int),allocator(a) :] list)'
This is kind of logical follow-up and prep patch for the
'!$omp allocate(list) [align(v) allocator(a)]'
support that was submitted as part of a larger patchset by Abid; cf.
Ubuntu 20.04.5 LTS (focal) unfortunately has an too old unidiff.PatchSet
for the feature added on Monday.
Solution: use is_binary_file only when it is available.
OK for mainline?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München;
Hi Harald,
On 13.12.22 23:27, Harald Anlauf wrote:
Am 13.12.22 um 22:41 schrieb Tobias Burnus:
Back to differences: 'diff -U0 -p -w' against the last GCC 11 branch
shows:
...
@@ -35,0 +37,2 @@ export_proto(cfi_desc_to_gfc_desc);
+/* NOTE: Since GCC 12, the FE generates code to do
Hi Harald,
On 13.12.22 21:53, Harald Anlauf via Gcc-patches wrote:
I now did so - except for three fixes (cf. changelog). See also
PR: https://gcc.gnu.org/PR108056
There is no testcase as it needs to be compiled by GCC <= 11 and then
run with linking (dynamically) to a GCC 12 or 13
We have a working parsing support for the 'allocate' directive
(failing immediately with a sorry after parsing).
To be in line with the rest of the allocat(e,or) etc. handling,
it makes sense to take care of 'align' as well, which is this
patch does - it still fails with a 'sorry' after parsing.
I missed that 'align' needs to be a power of 2 - contrary to 'aligned',
which does not have this restriction for some odd reason.
OK for mainline?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter
This is a 12/13 regression as come changes to fix the GFC/CFI descriptor
that went into GCC 12 fail with the (bogus) descriptor passed via by a
GCC-11-compiled program.
As later GCC 12 changes moved the descriptor to the front end, those
functions are only in libgomp.so to cater for old program.
On 09.12.22 22:12, Tobias Burnus wrote:
Found when working on the just submitted/committed patch.
Committed as r13-4590 – but it required a follow-up that I somehow
missed :-/ but that is now committed as well (as r13-4597).
Tobias
-
Siemens Electronic Design Automation GmbH
Hi Julian,
On 10.12.22 13:10, Julian Brown wrote:
On Thu, 8 Dec 2022 13:04:20 +0100
Tobias Burnus wrote:
All in all, I am fine with the patch - but I spotted some issues.
...
I believe this patch covers all the above cases (hopefully
appropriately generalised), at least for Fortran. I
Now that the reverse-offload patch is (nearly) in:
On 07.12.22 09:08, Tobias Burnus wrote:
On 06.12.22 08:45, Tobias Burnus wrote:
* As follow-up, libgomp.texi must be updated
Slight update to that uncommitted patch: I extended the nvptx entry to
state that only one reverse-offload region
On 09.12.22 15:44, Jakub Jelinek wrote:
On Tue, Dec 06, 2022 at 08:45:07AM +0100, Tobias Burnus wrote:
[...]
I think we just shouldn't support libgomp plugins for 32-bit libgomp, only
host fallback. If you want offloading, use 64-bit host...
(I concur.)
libgomp: Handle OpenMP's reverse
Found when working on the just submitted/committed patch.
I intent to commit it to mainline as obvious tomorrow (or Sun or Mon),
unless there are comments.
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit
Implementing the 5.1 syntax inside the 'allocate' clause. That's a
fallout of working on something else...
OK for mainline?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer:
On 08.12.22 15:35, Andrew Stubbs wrote:
On 08/12/2022 14:02, Tobias Burnus wrote:
With available, I assume that nvptx is an 'available device' (per OpenMP
definition, finally added in TR11), i.e. there is an image for nvptx and
- after omp_requires filtering - there remains at least one nvptx
On 08.12.22 13:51, Andrew Stubbs wrote:
On 08/12/2022 12:11, Jakub Jelinek wrote:
On Thu, Jul 07, 2022 at 11:34:33AM +0100, Andrew Stubbs wrote:
Implement the OpenMP pinned memory trait on Linux hosts using the mlock
syscall. Pinned allocations are performed using mmap, not malloc,
to ensure
Hi Julian:
On 07.12.22 20:13, Julian Brown wrote:
I know that this was the case before, but can you move the mark:1 etc.
after 'tlink'? In that case all bitfields are grouped together.
Thanks for doing so.
I wonder whether that also rejects the following – which seems to be
valid. The 'map'
On 07.12.22 20:09, Julian Brown wrote:
On Wed, 26 Oct 2022 12:39:39 +0200
Tobias Burnus wrote:
The ICE seems to be because gcc/fortran/trans-openmp.cc's
gfc_split_omp_clauses mishandles this as the dump shows the following:
#pragma omp target firstprivate(a) map(tofrom:a
Hi Julian,
I think this patch is OK; however, at least for gimplify.cc Jakub needs to have
a second look.
As remarked for the 2/4 patch, I believe mapping 'map(tofrom: var%f(2:3))'
should work
without explicitly mapping 'map(tofrom: var%f)'
(→ [TR11 157:21-26] (approx. [5.2 154:22-27], [5.1
Hi Julian,
On 07.12.22 16:16, Julian Brown wrote:
On Wed, 7 Dec 2022 15:54:42 +0100 Tobias Burnus wrote:
If I understand Deepak's comment (on OpenMP.org's omp-lang list, sorry
it is a nonpublic list) correctly, the following wording implies that
a 'from: s.w[z:4]' for a pointer 's.w' also
Hi Julian,
If I understand Deepak's comment (on OpenMP.org's omp-lang list, sorry
it is a nonpublic list) correctly, the following wording implies that a
'from: s.w[z:4]' for a pointer 's.w' also implies a mapping of 's.w' -
if 's' is used inside the target region and, thus, gets implicitly
On 06.12.22 08:45, Tobias Burnus wrote:
* As follow-up, libgomp.texi must be updated
That is what the attached patch does – obviously, it is depending on the
main patch.
OK (once the main patch is in)?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift
On 06.12.22 10:15, Jakub Jelinek wrote:
On Tue, Dec 06, 2022 at 09:59:17AM +0100, Tobias Burnus wrote:
This patch updates the OpenMP implementation status, based on libgomp.texi.
For the release notes, it also moves 'non-rectangular loop nests' up as that's
a 5.0 not a 5.1 feature.
And in line
nic 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 9f80367e539839fff1df2c85fc2640638199fc9e
Author: Tobias Burnus
D
; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit 9f80367e539839fff1df2c85fc2640638199fc9e
Author: Tobias Burnus
Date: Tue Dec 6 09:49:30 2022 +0100
libgomp.texi: Fix a OpenMP 5.2 and a TR11 impl-status item
libgomp/
* libgomp.texi (OpenMP 5.2
This patch finally handles reverse offload. Due to the prep work,
it essentially only adds content to libgomp/target.c's gomp_target_rev(),
except that it additionally saves the reverse-offload-function table
in gomp_load_image_to_device.
In the comment to "[Patch] libgomp: Add reverse-offload
On 30.11.22 10:43, Andrew Stubbs wrote:
On 29/11/2022 18:26, Tobias Burnus wrote:
On 29.11.22 16:56, Paul-Antoine Arras wrote:
This patch adds support for 'gfx803' as an alias for 'fiji' in OpenMP
context selectors, [...]
PA committed that patch as
https://gcc.gnu.org/r13-4403
Hi PA, hi Andrew, hi Jakub, hi all,
On 29.11.22 16:56, Paul-Antoine Arras wrote:
This patch adds support for 'gfx803' as an alias for 'fiji' in OpenMP
context selectors, [...]
I think this should be documented somewhere. We have
It turned out that cprop cleverly propagated the unspec_volatile
to the preceding (pseudo)register, permitting to remove the
'set (s0) (pseudoregister)' at -O2. Unfortunately, it does
matter whether the assignment is done to 's2' (previously: pseudoregister)
or to s1. – Just having a hard
elinek via Fortran wrote:
On Fri, Aug 26, 2022 at 08:21:26PM +0200, Tobias Burnus wrote:
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 gu
On 25.11.22 11:38, Jakub Jelinek wrote:
On Fri, Nov 25, 2022 at 11:34:35AM +0100, Tobias Burnus wrote:
It also adds TR11. I don't think we will work any time soon
on TR11 – possibly except for clarifications.
OK for mainline?
Ok (but I hope that once 6.0 is out, we just keep OpenMP 6.0
Update libgomp.texi's OpenMP implementation status.
The 5.1 changes are taken from Jakub's comment at
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602639.html
(sorry for taking that long to incorporate those).
It also adds TR11. I don't think we will work any time soon
on TR11 –
The nvptx reverse-offload code mishandled the case that there was a reverse
offload function that isn't called inside a target region. In that case,
the linker did not include GOMP_target_ext and the global variable it uses.
But the plugin-nvptx.c code expected that the latter is present.
Found
Updated list as follow up to last ping at
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601162.html
Recent patches:
Sandra's (Tue Nov 15 04:46:15 GMT 2022)
[PATCH v4] OpenMP: Generate SIMD clones for functions with "declare target"
On 11.11.22 16:13, Tobias Burnus wrote:
This patch adds TR11 to the history of OpenMP releases – and it does
an update of the implementation status.
OK?
Tobias
PS: The implementation-status changes were lying around in that file
for a while. I think both the GCC 13 release notes and this file
On 19.11.22 11:46, Tobias Burnus wrote:
+ stacklimit = stackbase + seg_size*64;
(this should be '*seg_size' not 'seg_size' and the name should be
s/seg_size/seg_size_ptr/.)
I have updated the comment and ...
(Reading it, I think it should be '..._MEM(SImode,' and
'..._MULT(SImode
Working on the builtins, I realized that I mixed up (again) bits and byes.
While 'uint64_t var[2]' has a size of 128 bits, 'char var[128]' has a size of
128 bytes.
Thus, there is sufficient space for 16 pointer-size/uin64_t values but I only
need 6.
This patch now makes use of the available
On 18.11.22 18:49, Andrew Stubbs wrote:
On 18/11/2022 17:20, Tobias Burnus wrote:
This looks wrong:
+/* stackbase = (stack_segment_decr & 0x)
++ stack_wave_offset);
+ seg_size = dispatch_ptr->private_segment_size;
+ stacklimit = stackbase + s
tches/2022-October/603383.html + the
next two by thread messages.
On 12.10.22 16:29, Tobias Burnus wrote:
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 ato
This patch adds two builtins (getting end-of-stack pointer and
a Boolean answer whether it was the first call to the builtin on this thread).
The idea is to replace some hard-coded values in newlib, permitting to move
later to a manually allocated stack on the compiler side without the need to
This is a part of a patch by Andrew (hi!) - namely that part that only adds the
__builtin_gcn_kernarg_ptr. More is planned, see below.
The short term benefit of this patch is to permit replacing hardcoded numbers
by a builtin – like in libgomp (see patch) or in newlib (not submitted):
---
Found when working on real reverse offload - as
the reverse-offload stub function was added to the reverse-offload table.
Reason - as mentioned in the commit log: lhd_set_decl_assembler_name.
I intent to commit it tomorrow as obvious, unless there are further
comments.
Tobias
-
This patch adds TR11 to the history of OpenMP releases – and it does an
update of the implementation status.
OK?
Tobias
PS: The implementation-status changes were lying around in that file for
a while. I think both the GCC 13 release notes and this file needs some
update for more recent
Hi Richard,
On 11.11.22 11:18, Richard Bienr wrote:
Note I think we can "remove" the install/ and onlinedocs/ _landing_ pages
(index.html) but we should keep the actual content pages so old links keep
working. We can also replace the landing pages with a pointer to the new
documentation (or
On 11.11.22 09:50, Martin Liška wrote:
I do support the Richi's idea about using a new URL for the new Sphinx
documentation
while keeping the older Texinfo documentation under /onlinedocs and /install
If we do so and those become then static files: Can we put some
disclaimer at the top of all
Hi Gerald,
On 10.11.22 20:24, Gerald Pfeifer wrote:
On Thu, 10 Nov 2022, Martin Liška wrote:
We noticed we'll need the old /install to be available for redirect.
Gerald, can you please put it somewhere under /install-prev, or
something similar?
I'm afraid I am confused now. Based on your
Hi,
On 10.11.22 11:03, Gerald Pfeifer wrote:
On Thu, 10 Nov 2022, Martin Liška wrote:
https://gcc.gnu.org/install/ is back with a new face.
But it's not working properly due to some Content Security Policy:
Hmm, it worked in my testing before and I just tried again:
Firefox 106.0.1 (64-bit)
Hello,
On 06.11.22 21:32, Mikael Morin wrote:
Le 05/11/2022 à 23:28, Tobias Burnus a écrit :
OK for mainline?
The trans-array.c part looks good.
A couple of nits for the trans-expr.cc part:
- /* Use the rhs string length and the lhs element size. */
- size = string_length
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
401 - 500 of 3341 matches
Mail list logo
