Add support for the gfx1036 RDNA2 APU integrated graphics devices.  The ROCm
documentation warns that these may not be supported, but it seems to work
at least partially.

gcc/ChangeLog:

	* config.gcc (amdgcn): Add gfx1036 entries.
	* config/gcn/gcn-hsa.h (NO_XNACK): Likewise.
	(gcn_local_sym_hash): Likewise.
	* config/gcn/gcn-opts.h (enum processor_type): Likewise.
	(TARGET_GFX1036): New macro.
	* config/gcn/gcn.cc (gcn_option_override): Handle gfx1036.
	(gcn_omp_device_kind_arch_isa): Likewise.
	(output_file_start): Likewise.
	* config/gcn/gcn.h (TARGET_CPU_CPP_BUILTINS): Add __gfx1036__.
	(TARGET_CPU_CPP_BUILTINS): Rename __gfx1030 to __gfx1030__.
	* config/gcn/gcn.opt: Add gfx1036.
	* config/gcn/mkoffload.cc (EF_AMDGPU_MACH_AMDGCN_GFX1036): New.
	(main): Handle gfx1036.
	* config/gcn/t-omp-device: Add gfx1036 isa.
	* doc/install.texi (amdgcn): Add gfx1036.
	* doc/invoke.texi (-march): Likewise.

libgomp/ChangeLog:

	* plugin/plugin-gcn.c (EF_AMDGPU_MACH): GFX1036.
	(gcn_gfx1103_s): New.
	(isa_hsa_name): Handle gfx1036.
	(isa_code): Likewise.
	(max_isa_vgprs): Likewise.

A splay-tree was previously used to lookup equivalent target addresses
for a given host address on offload targets. However, as splay-trees can
modify their structure on lookup, they are not suitable for concurrent
access from separate teams/threads without some form of locking.  This
patch changes the lookup data structure to a hashtab instead, which does
not have these issues.

The call to build_indirect_map to initialize the data structure is now
called from just the first thread of the first team to avoid redundant
calls to this function.

2024-03-22  Kwok Cheung Yeung  <kcyeung@baylibre.com>

	libgomp/
	* config/accel/target-indirect.c: Include string.h and hashtab.h.
	Remove include of splay-tree.h.  Update comments.
	(splay_tree_prefix, splay_tree_c): Delete.
	(struct indirect_map_t): New.
	(hash_entry_type, htab_alloc, htab_free, htab_hash, htab_eq): New.
	(GOMP_INDIRECT_ADD_MAP): Remove volatile qualifier.
	(USE_SPLAY_TREE_LOOKUP): Rename to...
	(USE_HASHTAB_LOOKUP): ..this.
	(indirect_map, indirect_array): Delete.
	(indirect_htab): New.
	(build_indirect_map): Remove locking.  Build indirect map using
	hashtab.
	(GOMP_target_map_indirect_ptr): Use indirect_htab to lookup target
	address.
	(GOMP_target_map_indirect_ptr): Remove volatile qualifier.
	* config/gcn/team.c (gomp_gcn_enter_kernel): Call build_indirect_map
	from first thread of first team only.
	* config/nvptx/team.c (gomp_nvptx_main): Likewise.
	* testsuite/libgomp.c-c++-common/declare-target-indirect-2.c (main):
	Add missing break statements.
	* testsuite/libgomp.fortran/declare-target-indirect-2.f90: Remove
	xfail.

Add support for the gfx1103 RDNA3 APU integrated graphics devices.  The ROCm
documentation warns that these may not be supported, but it seems to work
at least partially.

gcc/ChangeLog:

	* config.gcc (amdgcn): Add gfx1103 entries.
	* config/gcn/gcn-hsa.h (NO_XNACK): Likewise.
	(gcn_local_sym_hash): Likewise.
	* config/gcn/gcn-opts.h (enum processor_type): Likewise.
	(TARGET_GFX1103): New macro.
	* config/gcn/gcn.cc (gcn_option_override): Handle gfx1103.
	(gcn_omp_device_kind_arch_isa): Likewise.
	(output_file_start): Likewise.
	(gcn_hsa_declare_function_name): Use TARGET_RDNA3, not just gfx1100.
	* config/gcn/gcn.h (TARGET_CPU_CPP_BUILTINS): Add __gfx1103__.
	* config/gcn/gcn.opt: Add gfx1103.
	* config/gcn/mkoffload.cc (EF_AMDGPU_MACH_AMDGCN_GFX1103): New.
	(main): Handle gfx1103.
	* config/gcn/t-omp-device: Add gfx1103 isa.
	* doc/install.texi (amdgcn): Add gfx1103.
	* doc/invoke.texi (-march): Likewise.

libgomp/ChangeLog:

	* plugin/plugin-gcn.c (EF_AMDGPU_MACH): GFX1103.
	(gcn_gfx1103_s): New.
	(isa_hsa_name): Handle gfx1103.
	(isa_code): Likewise.
	(max_isa_vgprs): Likewise.

Our dear friend '-Wuninitialized' reported:

    [...]/libgomp.oacc-fortran/acc-memcpy.f90:18:27:

       18 |     char(j) = int (j, int8)
          |                           ^
    Warning: ‘j’ may be used uninitialized [-Wmaybe-uninitialized]
    [...]/libgomp.oacc-fortran/acc-memcpy.f90:14:20:

       14 |   integer(int8) :: j
          |                    ^
    note: ‘j’ was declared here

..., but actually there were other issues.

	libgomp/
	* testsuite/libgomp.oacc-fortran/acc-memcpy.f90: Fix 'char'
	initialization, copy, check.

Dummy procedures look similar to variables but aren't - neither in Fortran
nor in OpenMP. As the middle end sees PARM_DECLs, mark them as predetermined
firstprivate for mapping (as already done in gfc_omp_predetermined_sharing).

This does not address the isses related to procedure pointers, which are
still discussed on spec level [see PR].

	PR fortran/114283

gcc/fortran/ChangeLog:

	* trans-openmp.cc (gfc_omp_predetermined_mapping): Map dummy
	procedures as firstprivate.

libgomp/ChangeLog:

	* testsuite/libgomp.fortran/declare-target-indirect-4.f90: New test.

While texinfo 7.0.3 does not warn, an older texinfo did complain about:
libgomp.texi:1964: warning: node next `omp_target_memcpy' in menu
`omp_target_memcpy_rect' and in sectioning `omp_target_memcpy_async' differ

libgomp/

	* libgomp.texi (Device Memory Routines): Swap item order to match
	the order of the '@node's of the '@subsection's.

GCN: The original meaning of 'GCN_SUPPRESS_HOST_FALLBACK' isn't applicable (non-shared memory system)

'GCN_SUPPRESS_HOST_FALLBACK' originated as 'HSA_SUPPRESS_HOST_FALLBACK' in the
libgomp HSA plugin, where the idea was -- in my understanding -- that you
wouldn't have device code available for all functions that may be called, and
in that case transparently (shared memory system!) do host-fallback execution.
Or, with 'HSA_SUPPRESS_HOST_FALLBACK' set, you'd get those diagnosed.

This has then been copied into the libgomp GCN plugin as
'GCN_SUPPRESS_HOST_FALLBACK'.  However, the original meaning isn't applicable
for the libgomp GCN plugin anymore: we assume that we're generating device code
for all relevant functions, and we're implementing a non-shared memory system,
where we cannot transparently do host-fallback execution for individual
functions.

However, 'GCN_SUPPRESS_HOST_FALLBACK' has gained an additional meaning, to
enforce a fatal error in case that 'libhsa-runtime64.so.1' can't be dynamically
loaded; keep that meaning.

	libgomp/
	* plugin/plugin-gcn.c (GOMP_OFFLOAD_can_run): Don't consider
	'GCN_SUPPRESS_HOST_FALLBACK' anymore (assume always-'true').
	(init_hsa_context): Adjust 'GCN_SUPPRESS_HOST_FALLBACK' error
	message.

Per commit 683f1184
"OpenMP: Move omp requires checks to libgomp", we're now using 'return -1'
from 'GOMP_OFFLOAD_get_num_devices' for 'omp_requires_mask' purposes.  This
missed that via 'nvptx_get_num_devices', we could also 'return -1' for
'cuDeviceGetCount' failure.  Before, this meant (in 'gomp_target_init') to
silently ignore the plugin/device -- which also has been doubtful behavior.
Let's instead turn 'cuDeviceGetCount' failure into a fatal error, similar to
other errors during device initialization.

	libgomp/
	* plugin/plugin-nvptx.c (nvptx_get_num_devices):
	'cuDeviceGetCount' failure is fatal.

If 'libhsa-runtime64.so.1', 'libcuda.so.1' are not available, the corresponding
libgomp plugin/device gets disabled, as before.  But if they are available,
report any inconsistencies such as missing symbols, similar to how we fail in
presence of other issues during device initialization.

	libgomp/
	* plugin/plugin-gcn.c (init_hsa_runtime_functions): Fatal error
	for missing symbols.
	* plugin/plugin-nvptx.c (init_cuda_lib): Likewise.

This reverts commit b1420971.

For the type of the target callbacks we use elsehwere void (*) (void *) and
IMHO should use that for the reverse offload fallback as well (where the actual
callback is emitted using the same code as for host fallback or device kernel
entry routines), even when it is also ok to use void (*) () before C23 and
we aren't building libgomp with C23 yet.  On some arches perhaps void (*) ()
could result in worse code generation because calls in that case like casts
to unprototyped functions need to sometimes pass argument in two different spots
etc. so that it deals with both passing it through ... and as a named argument.

2024-03-04  Jakub Jelinek  <jakub@redhat.com>

	PR libgomp/114216
	* target.c (gomp_target_rev): Change host_fn type and corresponding
	cast from void (*)() to void (*) (void *).

OpenMP permits '(first)private' for C++ member variables, which GCC handles
by tagging those by DECL_OMP_PRIVATIZED_MEMBER, adding a temporary VAR_DECL
and DECL_VALUE_EXPR pointing to the 'this->member_var' in the C++ front end.

The idea is that in omp-low.cc, the DECL_VALUE_EXPR is used before the
region (for 'firstprivate'; ignored for 'private') while in the region,
the DECL itself is used.

In gimplify, the value expansion is suppressed and deferred if the
  lang_hooks.decls.omp_disregard_value_expr (decl, shared)
returns true - which is never the case if 'shared' is true. In OpenMP 4.5,
only 'map' and 'use_device_ptr' was permitted for the 'target' directive.
And when OpenMP 5.0's 'private'/'firstprivate' clauses was added, the
the update that now 'shared' argument could be false was missed. The
respective check has now been added.

2024-03-01  Jakub Jelinek  <jakub@redhat.com>
	    Tobias Burnus  <tburnus@baylibre.com>

	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 regions.

libgomp/ChangeLog:

	* testsuite/libgomp.c++/target-lambda-3.C: Moved from
	gcc/testsuite/g++.dg/gomp/ and fixed is-mapped handling.
	* testsuite/libgomp.c++/target-lambda-1.C: Modify to also
	also work without offloading.
	* testsuite/libgomp.c++/firstprivate-1.C: New test.
	* testsuite/libgomp.c++/firstprivate-2.C: New test.
	* testsuite/libgomp.c++/private-1.C: New test.
	* testsuite/libgomp.c++/private-2.C: New test.
	* testsuite/libgomp.c++/target-lambda-4.C: New test.
	* testsuite/libgomp.c++/use_device_ptr-1.C: New test.

gcc/testsuite/ChangeLog:

	* g++.dg/gomp/target-lambda-1.C: Moved to become a
	run-time test under testsuite/libgomp.c++.

Co-authored-by: Tobias Burnus <tburnus@baylibre.com>

These routines map simply to the C counterpart and are meanwhile
defined in OpenACC 3.3. (There are additional routine changes,
including the Fortran addition of acc_attach/acc_detach, that
require more work than a simple addition of an interface and
are therefore excluded.)

libgomp/ChangeLog:

	* libgomp.texi (OpenACC Runtime Library Routines): Document new 3.3
	routines that simply map to their C counterpart.
	* openacc.f90 (openacc): Add them.
	* openacc_lib.h: Likewise.
	* testsuite/libgomp.oacc-fortran/acc_host_device_ptr.f90: New test.
	* testsuite/libgomp.oacc-fortran/acc-memcpy.f90: New test.
	* testsuite/libgomp.oacc-fortran/acc-memcpy-2.f90: New test.
	* testsuite/libgomp.oacc-c-c++-common/lib-59.c: Crossref to f90 test.
	* testsuite/libgomp.oacc-c-c++-common/lib-60.c: Likewise.
	* testsuite/libgomp.oacc-c-c++-common/lib-95.c: Likewise.

The main 'arch' context selector for nvptx is, well, 'nvptx';
however, as 'nvptx64' is used as by LLVM, it makes sense
to support it as well.

Note that LLVM has: "The triple architecture can be one of
``nvptx`` (32-bit PTX) or ``nvptx64`` (64-bit PTX)."
GCC effectively only supports the 64bit variant (at least for
offloading). Thus, GCC's 'nvptx' is not quite the same as LLVM's.

The device-compiler part (nvptx_omp_device_kind_arch_isa) uses
TARGET_ABI64 such that nvptx64 is only defined with -m64.

gcc/ChangeLog:

	* config/nvptx/gen-omp-device-properties.sh: Add 'nvptx64' to arch.
	* config/nvptx/nvptx.cc (nvptx_omp_device_kind_arch_isa): Likewise.

libgomp/ChangeLog:

	* libgomp.texi (OpenMP Context Selectors): Add 'nvptx64' as additional
	'arch' value for nvptx.

Support for indirect calls to procedures/functions in offloaded target
regions is now available for C, C++ and Fortran.

2024-02-15  Kwok Cheung Yeung  <kcyeung@baylibre.com>

	libgomp/
	* libgomp.texi (OpenMP 5.1): Mark indirect call support as fully
	implemented.

2024-02-15  Kwok Cheung Yeung  <kcyeung@baylibre.com>

	gcc/fortran/
	* dump-parse-tree.cc (show_attr): Handle omp_declare_target_indirect
	attribute.
	* f95-lang.cc (gfc_gnu_attributes): Add entry for 'omp declare
	target indirect'.
	* gfortran.h (symbol_attribute): Add omp_declare_target_indirect
	field.
	(struct gfc_omp_clauses): Add indirect field.
	* openmp.cc (omp_mask2): Add OMP_CLAUSE_INDIRECT.
	(gfc_match_omp_clauses): Match indirect clause.
	(OMP_DECLARE_TARGET_CLAUSES): Add OMP_CLAUSE_INDIRECT.
	(gfc_match_omp_declare_target): Check omp_device_type and apply
	omp_declare_target_indirect attribute to symbol if indirect clause
	active.  Show warning if there are only device_type and/or indirect
	clauses on the directive.
	* trans-decl.cc (add_attributes_to_decl): Add 'omp declare target
	indirect' attribute if symbol has indirect attribute set.

	gcc/testsuite/
	* gfortran.dg/gomp/declare-target-4.f90 (f1): Update expected warning.
	* gfortran.dg/gomp/declare-target-indirect-1.f90: New.
	* gfortran.dg/gomp/declare-target-indirect-2.f90: New.

	libgomp/
	* testsuite/libgomp.fortran/declare-target-indirect-1.f90: New.
	* testsuite/libgomp.fortran/declare-target-indirect-2.f90: New.
	* testsuite/libgomp.fortran/declare-target-indirect-3.f90: New.

Two libgomp tests XPASS on Solaris (any non-Linux target actually) since
their introduction:

XPASS: libgomp.c/alloc-pinned-1.c execution test
XPASS: libgomp.c/alloc-pinned-2.c execution test

The problem is that the test just prints

OS unsupported

and exits successfully, while the test is XFAILed:

/* { dg-xfail-run-if "Pinning not implemented on this host" { ! *-*-linux-gnu } } */

Fixed by aborting immediately after the message above in the non-Linux
case.

Tested on i386-pc-solaris2.11 and i686-pc-linux-gnu.

2024-02-02  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	libgomp:
	PR testsuite/113448
	* testsuite/libgomp.c/alloc-pinned-1.c [!__linux__] (CHECK_SIZE):
	Call abort.
	* testsuite/libgomp.c/alloc-pinned-2.c [!__linux__] (CHECK_SIZE):
	Likewise.

2024-02-11  John David Anglin  <danglin@gcc.gnu.org>

libgomp/ChangeLog:

	PR libgomp/113843
	* configure.tgt (hppa*-*-linux*): Define config_path.

We support a maximum of 50 threads on 32-bit hppa.

2024-02-01  John David Anglin  <danglin@gcc.gnu.org>

libgomp/ChangeLog:

	* testsuite/libgomp.c++/loop-3.C: Set num_threads to 50
	on 32-bit hppa.
	* testsuite/libgomp.c/omp-loop03.c: Likewise.

libgomp/ChangeLog:

	* testsuite/libgomp.c/declare-variant-4.h: Use gfx1100/gfx1030
	function not gfx90a for gfx1100/gfx1030 context selector.

Signed-off-by: Tobias Burnus <tburnus@baylibre.com>

The following avoids registering unsupported GCN offload devices
when iterating over available ones.  With a Zen4 desktop CPU
you will have an IGPU (unspported) which will otherwise be made
available.  This causes testcases like
libgomp.c-c++-common/non-rect-loop-1.c which iterate over all
decives to FAIL.

libgomp/
	* plugin/plugin-gcn.c (suitable_hsa_agent_p): Filter out
	agents with unsupported ISA.

The following makes the existing architecture support check work
instead of being optimized away (enum vs. -1).  This avoids
later asserts when we assume such devices are never actually
used.

libgomp/
	* plugin/plugin-gcn.c
	(EF_AMDGPU_MACH::EF_AMDGPU_MACH_UNSUPPORTED): Add.
	(isa_code): Return that instead of -1.
	(GOMP_OFFLOAD_init_device): Adjust.

gcc/ChangeLog:

	* config.gcc (amdgcn-*-*): Add gfx1030 and gfx1100 to
	TM_MULTILIB_CONFIG.
	* doc/install.texi (Configuration amdgcn-*-*): Mention gfx1030/gfx1100.
	* doc/invoke.texi (AMD GCN Options): Add gfx1030 and 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-gfx1030.c: New test.
	* testsuite/libgomp.c/declare-variant-4-gfx1100.c: New test.

Signed-off-by: Tobias Burnus <tburnus@baylibre.com>