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 be
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.
(b
On Thu, Dec 15, 2022 at 06:34:30PM +0100, Thomas Schwinge wrote:
> --- a/libgomp/libgomp-plugin.c
> +++ b/libgomp/libgomp-plugin.c
> @@ -82,9 +82,9 @@ GOMP_PLUGIN_fatal (const char *msg, ...)
> void
> GOMP_PLUGIN_target_rev (uint64_t fn_ptr, uint64_t mapnum, uint64_t
> devaddrs_ptr,
>
Hi!
On 2022-12-06T08:45:07+0100, Tobias Burnus wrote:
> This patch finally handles reverse offload.
Yay! \o/
The 'libgomp.fortran/reverse-offload-5.f90' test case for nvptx
offloading runs into an error condition (thus, XFAILed) -- but then
blocks until timeout, insted of terminating promptly
On Sat, Dec 10, 2022 at 09:11:24AM +0100, Tobias Burnus wrote:
> It is used as 'typedef struct reverse_splay_tree_node_s
> *reverse_splay_tree_node;' in
>
> struct target_mem_desc {
>
> reverse_splay_tree_node rev_array;
> }
>
> but also as
>
> struct gomp_device_descr
> {
> ...
> st
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 off
On Tue, Dec 06, 2022 at 08:45:07AM +0100, Tobias Burnus wrote:
> 32bit vs. 64bit: libgomp itself is compiled with both -m32 and -m64; however,
> nvptx and gcn requires -m64 on the device side and assume that the device
> pointers are representable on the host (i.e. all are 64bit). The new code
> tr
