Commit graph

1829 commits

Author SHA1 Message Date
GCC Administrator
43997608a0 Daily bump. 2022-07-13 00:16:33 +00:00
Tobias Burnus
220bef4601 libgomp: Add tailing \n to gomp_debug
Contrary to gomp_{error,warning,fatal}, no tailing '\n' is added with
gomp_debug; only affected was a 'requires'-related output.

libgomp/ChangeLog:

	* target.c (gomp_target_init): Added tailing '\n' to gomp_debug.
2022-07-12 11:10:50 +02:00
Thomas Schwinge
3723aedaad XFAIL 'offloading_enabled' diagnostics issue in 'libgomp.oacc-c-c++-common/reduction-5.c' [PR101551]
Fix-up for recent commit 06b2a2abe2
"Enhance '_Pragma' diagnostics verification in OMP C/C++ test cases".
Supposedly it's the same issue as in
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101551#c2>, where I'd
noted that:

| [...] with an offloading-enabled build of GCC we're losing
| "note: in expansion of macro '[...]'" diagnostics.
| (Effectively '-ftrack-macro-expansion=0'?)

	PR middle-end/101551
	libgomp/
	* testsuite/libgomp.oacc-c-c++-common/reduction-5.c: XFAIL
	'offloading_enabled' diagnostics issue.
2022-07-12 08:28:00 +02:00
GCC Administrator
c72d471469 Daily bump. 2022-07-12 00:16:27 +00:00
Thomas Schwinge
06b2a2abe2 Enhance '_Pragma' diagnostics verification in OMP C/C++ test cases
Follow-up to recent commit 0587cef3d7
"c: Fix location for _Pragma tokens [PR97498]".

	gcc/testsuite/
	* c-c++-common/gomp/pragma-3.c: Enhance '_Pragma' diagnostics
	verification.
	* c-c++-common/gomp/pragma-5.c: Likewise.
	libgomp/
	* testsuite/libgomp.oacc-c-c++-common/reduction-5.c: Enhance
	'_Pragma' diagnostics verification.
2022-07-11 11:23:33 +02:00
GCC Administrator
b53ebbc541 Daily bump. 2022-07-11 00:16:25 +00:00
Lewis Hyatt
0587cef3d7 c: Fix location for _Pragma tokens [PR97498]
The handling of #pragma GCC diagnostic uses input_location, which is not always
as precise as needed; in particular the relative location of some tokens and a
_Pragma directive will crucially determine whether a given diagnostic is enabled
or suppressed in the desired way. PR97498 shows how the C frontend ends up with
input_location pointing to the beginning of the line containing a _Pragma()
directive, resulting in the wrong behavior if the diagnostic to be modified
pertains to some tokens found earlier on the same line. This patch fixes that by
addressing two issues:

    a) libcpp was not assigning a valid location to the CPP_PRAGMA token
    generated by the _Pragma directive.
    b) C frontend was not setting input_location to something reasonable.

With this change, the C frontend is able to change input_location to point to
the _Pragma token as needed.

This is just a two-line fix (one for each of a) and b)), the testsuite changes
were needed only because the location on the tested warnings has been somewhat
improved, so the tests need to look for the new locations.

gcc/c/ChangeLog:

	PR preprocessor/97498
	* c-parser.cc (c_parser_pragma): Set input_location to the
	location of the pragma, rather than the start of the line.

libcpp/ChangeLog:

	PR preprocessor/97498
	* directives.cc (destringize_and_run): Override the location of
	the CPP_PRAGMA token from a _Pragma directive to the location of
	the expansion point, as is done for the tokens lexed from it.

gcc/testsuite/ChangeLog:

	PR preprocessor/97498
	* c-c++-common/pr97498.c: New test.
	* c-c++-common/gomp/pragma-3.c: Adapt for improved warning locations.
	* c-c++-common/gomp/pragma-5.c: Likewise.
	* gcc.dg/pragma-message.c: Likewise.

libgomp/ChangeLog:

	* testsuite/libgomp.oacc-c-c++-common/reduction-5.c: Adapt for
	improved warning locations.
	* testsuite/libgomp.oacc-c-c++-common/vred2d-128.c: Likewise.
2022-07-10 16:50:03 -04:00
GCC Administrator
0fe604a2d9 Daily bump. 2022-07-09 00:16:54 +00:00
Thomas Schwinge
faa0c328ee Fix one issue in OpenMP 'requires' directive diagnostics
Fix-up for recent commit 683f118439
"OpenMP: Move omp requires checks to libgomp".

	gcc/
	* lto-cgraph.cc (input_offload_tables) <LTO_symtab_edge>: Correct
	'fn2' computation.
	libgomp/
	* testsuite/libgomp.c-c++-common/requires-1.c: Add 'dg-note's.
	* testsuite/libgomp.c-c++-common/requires-2.c: Likewise.
	* testsuite/libgomp.c-c++-common/requires-3.c: Likewise.
	* testsuite/libgomp.c-c++-common/requires-7.c: Likewise.
	* testsuite/libgomp.fortran/requires-1.f90: Likewise.
2022-07-08 08:53:58 +02:00
GCC Administrator
6345c41454 Daily bump. 2022-07-08 00:16:22 +00:00
Thomas Schwinge
9ef714539c Fix Intel MIC 'mkoffload' for OpenMP 'requires'
Similar to how the other 'mkoffload's got changed in
recent commit 683f118439
"OpenMP: Move omp requires checks to libgomp".

This also means finally switching Intel MIC 'mkoffload' to
'GOMP_offload_register_ver', 'GOMP_offload_unregister_ver',
making 'GOMP_offload_register', 'GOMP_offload_unregister'
legacy entry points.

	gcc/
	* config/i386/intelmic-mkoffload.cc (generate_host_descr_file)
	(prepare_target_image, main): Handle OpenMP 'requires'.
	(generate_host_descr_file): Switch to 'GOMP_offload_register_ver',
	'GOMP_offload_unregister_ver'.
	libgomp/
	* target.c (GOMP_offload_register, GOMP_offload_unregister):
	Denote as legacy entry points.
	* testsuite/lib/libgomp.exp
	(check_effective_target_offload_target_any): New proc.
	* testsuite/libgomp.c-c++-common/requires-1.c: Enable for
	'offload_target_any'.
	* testsuite/libgomp.c-c++-common/requires-3.c: Likewise.
	* testsuite/libgomp.c-c++-common/requires-7.c: Likewise.
	* testsuite/libgomp.fortran/requires-1.f90: Likewise.
2022-07-07 12:38:51 +02:00
Thomas Schwinge
5647e2c385 Enhance 'libgomp.c-c++-common/requires-4.c', 'libgomp.c-c++-common/requires-5.c' testing
These should compile and link and execute in all configurations; host-fallback
execution, which we may actually verify.

Follow-up to recent commit 683f118439
"OpenMP: Move omp requires checks to libgomp".

	libgomp/
	* testsuite/libgomp.c-c++-common/requires-4.c: Enhance testing.
	* testsuite/libgomp.c-c++-common/requires-5.c: Likewise.
2022-07-07 12:38:51 +02:00
Thomas Schwinge
99831ceb87 Adjust 'libgomp.c-c++-common/requires-3.c'
As documented, this one does "Check diagnostic by device-compiler's lto1".
Indeed there are none when compiling with '-foffload=disable' with an
offloading-enabled compiler, so we should use 'offload_target_[...]', as
used in other similar test cases.

Follow-up to recent commit 683f118439
"OpenMP: Move omp requires checks to libgomp".

	libgomp/
	* testsuite/libgomp.c-c++-common/requires-3.c: Adjust.
2022-07-07 12:38:50 +02:00
GCC Administrator
4bc92c3bfa Daily bump. 2022-07-07 00:16:46 +00:00
Thomas Schwinge
3f05e03d6c Restore 'GOMP_offload_unregister_ver' functionality
The recent commit 683f118439
"OpenMP: Move omp requires checks to libgomp" changed the
'GOMP_offload_register_ver' interface but didn't change
'GOMP_offload_unregister_ver' accordingly, so we're no longer
actually unregistering.

	gcc/
	* config/gcn/mkoffload.cc (process_obj): Clarify 'target_data' ->
	'[...]_data'.
	* config/nvptx/mkoffload.cc (process): Likewise.
	libgomp/
	* target.c (GOMP_offload_register_ver): Clarify 'target_data' ->
	'data'.
	(GOMP_offload_unregister_ver): Likewise.  Fix up 'target_data'.
2022-07-06 22:53:04 +02:00
GCC Administrator
8467574d8d Daily bump. 2022-07-05 00:16:36 +00:00
Tobias Burnus
c3297044f0 OpenMP/Fortran: Add support for OpenMP 5.2 linear clause syntax
Fortran part to C/C++
commit r13-1002-g03b71406323ddc065b1d7837d8b43b17e4b048b5

gcc/fortran/ChangeLog:

	* gfortran.h (gfc_omp_namelist): Update by creating 'linear' struct,
	move 'linear_op' as 'op' to id and add 'old_modifier' to it.
	* dump-parse-tree.cc (show_omp_namelist): Update accordingly.
	* module.cc (mio_omp_declare_simd): Likewise.
	* trans-openmp.cc (gfc_trans_omp_clauses): Likewise.
	* openmp.cc (resolve_omp_clauses): Likewise; accept new-style
	'val' modifier with do/simd.
	(gfc_match_omp_clauses): Handle OpenMP 5.2 linear clause syntax.

libgomp/ChangeLog:

	* libgomp.texi (OpenMP 5.2): Mark linear-clause change as 'Y'.

gcc/testsuite/ChangeLog:

	* c-c++-common/gomp/linear-4.c: New test.
	* gfortran.dg/gomp/linear-2.f90: New test.
	* gfortran.dg/gomp/linear-3.f90: New test.
	* gfortran.dg/gomp/linear-4.f90: New test.
	* gfortran.dg/gomp/linear-5.f90: New test.
	* gfortran.dg/gomp/linear-6.f90: New test.
	* gfortran.dg/gomp/linear-7.f90: New test.
	* gfortran.dg/gomp/linear-8.f90: New test.

Co-authored-by: Jakub Jelinek <jakub@redhat.com>
2022-07-04 21:50:23 +02:00
Tobias Burnus
683f118439 OpenMP: Move omp requires checks to libgomp
Handle reverse_offload, unified_address, and unified_shared_memory
requirements in libgomp by saving them alongside the offload table.
When the device lto1 runs, it extracts the data for mkoffload. The
latter than passes the value on to GOMP_offload_register_ver.

lto1 (either the host one, with -flto [+ ENABLE_OFFLOADING], or in the
offload-device lto1) also does the the consistency check is done,
erroring out when the 'omp requires' clause use is inconsistent.

For all in-principle supported devices, if a requirement cannot be fulfilled,
the device is excluded from the (supported) devices list. Currently, none of
those requirements are marked as supported for any of the non-host devices.

gcc/c/ChangeLog:

	* c-parser.cc (c_parser_omp_target_data, c_parser_omp_target_update,
	c_parser_omp_target_enter_data, c_parser_omp_target_exit_data): Set
	OMP_REQUIRES_TARGET_USED.
	(c_parser_omp_requires): Remove sorry.

gcc/ChangeLog:

	* config/gcn/mkoffload.cc (process_asm): Write '#include <stdint.h>'.
	(process_obj): Pass omp_requires_mask to GOMP_offload_register_ver.
	(main): Ask lto1 to obtain omp_requires_mask and pass it on.
	* config/nvptx/mkoffload.cc (process, main): Likewise.
	* lto-cgraph.cc (omp_requires_to_name): New.
	(input_offload_tables): Save omp_requires_mask.
	(output_offload_tables): Read it, check for consistency,
	save value for mkoffload.
	* omp-low.cc (lower_omp_target): Force output_offloadtables
	call for OMP_REQUIRES_TARGET_USED.

gcc/cp/ChangeLog:

	* parser.cc (cp_parser_omp_target_data,
	cp_parser_omp_target_enter_data, cp_parser_omp_target_exit_data,
	cp_parser_omp_target_update): Set OMP_REQUIRES_TARGET_USED.
	(cp_parser_omp_requires): Remove sorry.

gcc/fortran/ChangeLog:

	* openmp.cc (gfc_match_omp_requires): Remove sorry.
	* parse.cc (decode_omp_directive): Don't regard 'declare target'
	as target usage for 'omp requires'; add more flags to
	omp_requires_mask.

include/ChangeLog:

	* gomp-constants.h (GOMP_VERSION): Bump to 2.
	(GOMP_REQUIRES_UNIFIED_ADDRESS, GOMP_REQUIRES_UNIFIED_SHARED_MEMORY,
	GOMP_REQUIRES_REVERSE_OFFLOAD, GOMP_REQUIRES_TARGET_USED):
	New defines.

libgomp/ChangeLog:

	* libgomp-plugin.h (GOMP_OFFLOAD_get_num_devices): Add
	omp_requires_mask arg.
	* plugin/plugin-gcn.c (GOMP_OFFLOAD_get_num_devices): Likewise;
	return -1 when device available but omp_requires_mask != 0.
	* plugin/plugin-nvptx.c (GOMP_OFFLOAD_get_num_devices): Likewise.
	* oacc-host.c (host_get_num_devices, host_openacc_get_property):
	Update call.
	* oacc-init.c (resolve_device, acc_init_1, acc_shutdown_1,
	goacc_attach_host_thread_to_device, acc_get_num_devices,
	acc_set_device_num, get_property_any): Likewise.
	* target.c (omp_requires_mask): New global var.
	(gomp_requires_to_name): New.
	(GOMP_offload_register_ver): Handle passed omp_requires_mask.
	(gomp_target_init): Handle omp_requires_mask.
	* libgomp.texi (OpenMP 5.0): Update requires impl. status.
	(OpenMP 5.1): Add a missed item.
	(OpenMP 5.2): Mark linear-clause change as supported in C/C++.
	* testsuite/libgomp.c-c++-common/requires-1-aux.c: New test.
	* testsuite/libgomp.c-c++-common/requires-1.c: New test.
	* testsuite/libgomp.c-c++-common/requires-2-aux.c: New test.
	* testsuite/libgomp.c-c++-common/requires-2.c: New test.
	* testsuite/libgomp.c-c++-common/requires-3-aux.c: New test.
	* testsuite/libgomp.c-c++-common/requires-3.c: New test.
	* testsuite/libgomp.c-c++-common/requires-4-aux.c: New test.
	* testsuite/libgomp.c-c++-common/requires-4.c: New test.
	* testsuite/libgomp.c-c++-common/requires-5-aux.c: New test.
	* testsuite/libgomp.c-c++-common/requires-5.c: New test.
	* testsuite/libgomp.c-c++-common/requires-6.c: New test.
	* testsuite/libgomp.c-c++-common/requires-7-aux.c: New test.
	* testsuite/libgomp.c-c++-common/requires-7.c: New test.
	* testsuite/libgomp.fortran/requires-1-aux.f90: New test.
	* testsuite/libgomp.fortran/requires-1.f90: New test.

liboffloadmic/ChangeLog:

	* plugin/libgomp-plugin-intelmic.cpp (GOMP_OFFLOAD_get_num_devices):
	Return -1 when device available but omp_requires_mask != 0.

gcc/testsuite/ChangeLog:

	* c-c++-common/gomp/requires-4.c: Update dg-*.
	* c-c++-common/gomp/reverse-offload-1.c: Likewise.
	* c-c++-common/gomp/target-device-ancestor-2.c: Likewise.
	* c-c++-common/gomp/target-device-ancestor-3.c: Likewise.
	* c-c++-common/gomp/target-device-ancestor-4.c: Likewise.
	* c-c++-common/gomp/target-device-ancestor-5.c: Likewise.
	* gfortran.dg/gomp/target-device-ancestor-3.f90: Likewise.
	* gfortran.dg/gomp/target-device-ancestor-4.f90: Likewise.
	* gfortran.dg/gomp/target-device-ancestor-5.f90: Likewise.
	* gfortran.dg/gomp/target-device-ancestor-2.f90: Likewise. Move
	post-FE checks to ...
	* gfortran.dg/gomp/target-device-ancestor-2a.f90: ... this new file.
	* gfortran.dg/gomp/requires-8.f90: Update as we don't regard
	'declare target' for the 'requires' usage requirement.

Co-authored-by: Chung-Lin Tang <cltang@codesourcery.com>
Co-authored-by: Thomas Schwinge <thomas@codesourcery.com>
2022-07-04 13:52:02 +02:00
GCC Administrator
ed97448899 Daily bump. 2022-07-02 00:16:26 +00:00
Tobias Burnus
9a668532fb OpenMP: Handle tofrom with target enter/exit data
In 5.2, a map clause can be map-entering or map-exiting,
either containing 'tofrom'. The main reason for this is
permit 'map(x)' with 'omp target enter/exit data',
avoiding to specify 'to:/from:' explicitly. (OpenMP
defaults to 'tofrom'.)

gcc/c/ChangeLog:

	* c-parser.cc (c_parser_omp_target_enter_data,
	c_parser_omp_target_exit_data): Accept tofrom
	map-type modifier but use 'to' / 'from' internally.

gcc/cp/ChangeLog:

	* parser.cc (cp_parser_omp_target_enter_data,
	cp_parser_omp_target_exit_data): Accept tofrom
	map-type modifier but use 'to' / 'from' internally.

gcc/fortran/ChangeLog:

	* dump-parse-tree.cc (show_omp_namelist): For the map-type,
	also handle the always modifer and release/delete.
	* openmp.cc (resolve_omp_clauses): Accept tofrom
	map-type modifier for target enter/exit data,
	but use 'to' / 'from' internally.

libgomp/ChangeLog:

	* libgomp.texi (OpenMP 5.2): Mark target enter/exit data
	with fromto as implemented.

gcc/testsuite/ChangeLog:

	* c-c++-common/gomp/target-data-2.c: New test.
	* c-c++-common/gomp/target-data-3.c: New test.
	* gfortran.dg/gomp/target-data-1.f90: New test.
	* gfortran.dg/gomp/target-data-2.f90: New test.
2022-07-01 17:52:03 +02:00
GCC Administrator
fb29fdea9c Daily bump. 2022-06-29 00:17:00 +00:00
Martin Liska
6835baee71 libgomp: fix typo in mold linker detection
libgomp/ChangeLog:

	* acinclude.m4: Fix typo in mold linker detection.
	* Makefile.in: Regenerate.
	* configure: Regenerate.
2022-06-28 10:35:32 +02:00
GCC Administrator
de89b078e3 Daily bump. 2022-06-22 00:16:25 +00:00
Jakub Jelinek
85d613da34 libgomp: Fix up target-31.c test [PR106045]
The i variable is used inside of the parallel in:
      #pragma omp simd safelen(32) private (v)
      for (i = 0; i < 64; i++)
        {
          v = 3 * i;
          ll[i] = u1 + v * u2[0] + u2[1] + x + y[0] + y[1] + v + h[0] + u3[i];
        }
where i is predetermined linear (so while inside of the body
it is safe, private per SIMD lane var) the final value is written to
the shared variable, and in:
      for (i = 0; i < 64; i++)
        if (ll[i] != u1 + 3 * i * u2[0] + u2[1] + x + y[0] + y[1] + 3 * i + 13 + 14 + i)
          #pragma omp atomic write
            err = 1;
which is a normal loop and so it isn't in any way privatized there.
So we have a data race, fixed by adding private (i) clause to the
parallel.

2022-06-21  Jakub Jelinek  <jakub@redhat.com>
	    Paul Iannetta  <piannetta@kalrayinc.com>

	PR libgomp/106045
	* testsuite/libgomp.c/target-31.c: Add private (i) clause.
2022-06-21 17:51:08 +02:00
GCC Administrator
5a66d7dd2b Daily bump. 2022-06-18 00:16:19 +00:00
Martin Liska
c524d860a7 docs: add missing table header
libgomp/ChangeLog:

	* libgomp.texi: Add table header for new features of
	OpenMP 5.2.
2022-06-17 13:33:35 +02:00
GCC Administrator
499b9c5f09 Daily bump. 2022-06-16 00:16:44 +00:00
Jakub Jelinek
7bfb3f488a openmp: Fix up get-mapped-ptr-1.{c,f90} tests
On Tue, Jun 14, 2022 at 06:41:37PM +0200, Thomas Schwinge wrote:
> In an offloading configuration, I'm seeing:
>
>     PASS: libgomp.fortran/get-mapped-ptr-1.f90   -O  (test for excess errors)
>     [-PASS:-]{+FAIL:+} libgomp.fortran/get-mapped-ptr-1.f90   -O  execution test
>
> Does that one need similar treatment?

I assume not just that but libgomp.c-c++-common/get-mapped-ptr-1.c too?

It both needs the same treatment, and in the get-mapped-ptr-1.c
case there is even UB, while the Fortran version was using c_loc (q)
as the host pointer, in C/C++ it was using q which was value of
uninitialized pointer.

2022-06-15  Jakub Jelinek  <jakub@redhat.com>

	* testsuite/libgomp.c-c++-common/get-mapped-ptr-1.c (main): Initialize
	q to ddress of an automatic variable.  Use -5 instead of -1 in
	omp_get_mapped_ptr call.  Add test with omp_initial_device.
	* testsuite/libgomp.fortran/get-mapped-ptr-1.f90 (main): Use -5 instead
	of -1 in omp_get_mapped_ptr call.  Add test with omp_initial_device.
	Renumber stop arguments afterwards.
2022-06-15 10:45:04 +02:00
GCC Administrator
c3642271e8 Daily bump. 2022-06-14 00:16:39 +00:00
Jakub Jelinek
1158fe4340 openmp: Conforming device numbers and omp_{initial,invalid}_device
OpenMP 5.2 changed once more what device numbers are allowed.
In 5.1, valid device numbers were [0, omp_get_num_devices()].
5.2 makes also -1 valid (calls it omp_initial_device), which is equivalent
in behavior to omp_get_num_devices() number but has the advantage that it
is a constant.  And it also introduces omp_invalid_device which is
also a constant with implementation defined value < -1.  That value should
act like sNaN, any time any device construct (GOMP_target*) or OpenMP runtime
API routine is asked for such a device, the program is terminated.
And if OMP_TARGET_OFFLOAD=mandatory, all non-conforming device numbers (which
is all but [-1, omp_get_num_devices()] other than omp_invalid_device)
must be treated like omp_invalid_device.

For device constructs, we have a compatibility problem, we've historically
used 2 magic negative values to mean something special.
GOMP_DEVICE_ICV (-1) means device clause wasn't present, pick the
		     omp_get_default_device () number
GOMP_DEVICE_FALLBACK (-2) means the host device (this is used e.g. for
			  #pragma omp target if (cond)
			  where if cond is false, we pass -2
But 5.2 requires that omp_initial_device is -1 (there were discussions
about it, advantage of -1 is that one can say iterate over the
[-1, omp_get_num_devices()-1] range to get all devices starting with
the host/initial one.
And also, if user passes -2, unless it is omp_invalid_device, we need to
treat it like non-conforming with OMP_TARGET_OFFLOAD=mandatory.

So, the patch does on the compiler side some number remapping,
user_device_num >= -2U ? user_device_num - 1 : user_device_num.
This remapping is done at compile time if device clause has constant
argument, otherwise at runtime, and means that for user -1 (omp_initial_device)
we pass -2 to GOMP_* in the runtime library where it treats it like host
fallback, while -2 is remapped to -3 (one of the non-conforming device numbers,
for those it doesn't matter which one is which).
omp_invalid_device is then -4.
For the OpenMP device runtime APIs, no remapping is done.

This patch doesn't deal with the initial default-device-var for
OMP_TARGET_OFFLOAD=mandatory , the spec says that the inital ICV value
for that should in that case depend on whether there are any offloading
devices or not (if not, should be omp_invalid_device), but that means
we can't determine the number of devices lazily (and let libraries have the
possibility to register their offloading data etc.).

2022-06-13  Jakub Jelinek  <jakub@redhat.com>

gcc/
	* omp-expand.cc (expand_omp_target): Remap user provided
	device clause arguments, -1 to -2 and -2 to -3, either
	at compile time if constant, or at runtime.
include/
	* gomp-constants.h (GOMP_DEVICE_INVALID): Define.
libgomp/
	* omp.h.in (omp_initial_device, omp_invalid_device): New enumerators.
	* omp_lib.f90.in (omp_initial_device, omp_invalid_device): New
	parameters.
	* omp_lib.h.in (omp_initial_device, omp_invalid_device): Likewise.
	* target.c (resolve_device): Add remapped argument, handle
	GOMP_DEVICE_ICV only if remapped is true (and clear remapped),
	for negative values, treat GOMP_DEVICE_FALLBACK as fallback only
	if remapped, otherwise treat omp_initial_device that way.  For
	omp_invalid_device, always emit gomp_fatal, even when
	OMP_TARGET_OFFLOAD isn't mandatory.
	(GOMP_target, GOMP_target_ext, GOMP_target_data, GOMP_target_data_ext,
	GOMP_target_update, GOMP_target_update_ext,
	GOMP_target_enter_exit_data): Pass true as remapped argument to
	resolve_device.
	(omp_target_alloc, omp_target_free, omp_target_is_present,
	omp_target_memcpy_check, omp_target_associate_ptr,
	omp_target_disassociate_ptr, omp_get_mapped_ptr,
	omp_target_is_accessible): Pass false as remapped argument to
	resolve_device.  Treat omp_initial_device the same as
	gomp_get_num_devices ().  Don't bypass resolve_device calls if
	device_num is negative.
	(omp_pause_resource): Treat omp_initial_device the same as
	gomp_get_num_devices ().  Call resolve_device.
	* icv-device.c (omp_set_default_device): Always set to device_num
	even when it is negative.
	* libgomp.texi: Document that Conforming device numbers,
	omp_initial_device and omp_invalid_device is implemented.
	* testsuite/libgomp.c/target-41.c (main): Add test with
	omp_initial_device.
	* testsuite/libgomp.c/target-45.c: New test.
	* testsuite/libgomp.c/target-46.c: New test.
	* testsuite/libgomp.c/target-47.c: New test.
	* testsuite/libgomp.c-c++-common/target-is-accessible-1.c (main): Add
	test with omp_initial_device.  Use -5 instead of -1 for negative value
	test.
	* testsuite/libgomp.fortran/target-is-accessible-1.f90 (main):
	Likewise.  Reorder stop numbers.
2022-06-13 14:02:37 +02:00
GCC Administrator
ef1e4d80dd Daily bump. 2022-06-11 00:16:21 +00:00
Jakub Jelinek
1eff4872d2 openmp: Call dlopen with "libmemkind.so.0" rather than "libmemkind.so"
On Thu, Jun 09, 2022 at 12:11:28PM +0200, Thomas Schwinge wrote:
> > This patch adds support for dlopening libmemkind.so
>
> Instead of 'dlopen'ing literally 'libmemkind.so':
> ..., shouldn't this instead 'dlopen' 'libmemkind.so.0'?  At least for
> Debian/Ubuntu, the latter ('libmemkind.so.0') is shipped in the "library"
> package:

I agree and I've actually noticed it too right before committing, but I thought
I'll investigate and tweak incrementally because "libmemkind.so"
is what I've actually tested (it is what llvm libomp uses).

Here is the now tested incremental fix.

2022-06-10  Jakub Jelinek  <jakub@redhat.com>

	* allocator.c (gomp_init_memkind): Call dlopen with "libmemkind.so.0"
	rather than "libmemkind.so".
2022-06-10 21:19:51 +02:00
Thomas Schwinge
1459b55d24 libgomp nvptx plugin: Remove '--with-cuda-driver=[...]' etc. configuration option
That means, exposing to the user only the '--without-cuda-driver' behavior:
including the GCC-shipped 'include/cuda/cuda.h' (not system <cuda.h>), and
'dlopen'ing the CUDA Driver library (not linking it).

For development purposes, the libgomp nvptx plugin developer may still manually
override that, to get the previous '--with-cuda-driver' behavior.

	libgomp/
	* plugin/Makefrag.am: Evaluate 'if PLUGIN_NVPTX_DYNAMIC' to true.
	* plugin/configfrag.ac (--with-cuda-driver)
	(--with-cuda-driver-include, --with-cuda-driver-lib)
	(CUDA_DRIVER_INCLUDE, CUDA_DRIVER_LIB, PLUGIN_NVPTX_CPPFLAGS)
	(PLUGIN_NVPTX_LDFLAGS, PLUGIN_NVPTX_LIBS, PLUGIN_NVPTX_DYNAMIC):
	Remove.
	* testsuite/libgomp-test-support.exp.in (cuda_driver_include)
	(cuda_driver_lib): Remove.
	* testsuite/lib/libgomp.exp (libgomp_init): Don't consider these.
	* Makefile.in: Regenerate.
	* configure: Likewise.
	* testsuite/Makefile.in: Likewise.
2022-06-10 17:08:57 +02:00
GCC Administrator
e3bba42fb5 Daily bump. 2022-06-10 00:16:43 +00:00
Jakub Jelinek
699e9a0f67 openmp: Fix up include of the generic allocator.c
As reported by Richard Sandiford, #include "../../../allocator.c"
has one too many ../s, dunno why it worked for me when using
../configure (VPATH = ../../../libgomp)

2022-06-09  Jakub Jelinek  <jakub@redhat.com>

	* config/linux/allocator.c: Fix up #include directive.
2022-06-09 19:44:50 +02:00
Jakub Jelinek
17f52a1c72 openmp: Add support for HBW or large capacity or interleaved memory through the libmemkind.so library
This patch adds support for dlopening libmemkind.so on Linux and uses it
for some kinds of allocations (but not yet e.g. pinned memory).

2022-06-09  Jakub Jelinek  <jakub@redhat.com>

	* allocator.c: Include dlfcn.h if LIBGOMP_USE_MEMKIND is defined.
	(enum gomp_memkind_kind): New type.
	(struct omp_allocator_data): Add memkind field if LIBGOMP_USE_MEMKIND
	is defined.
	(struct gomp_memkind_data): New type.
	(memkind_data, memkind_data_once): New variables.
	(gomp_init_memkind, gomp_get_memkind): New functions.
	(omp_init_allocator): Initialize data.memkind, don't fail for
	omp_high_bw_mem_space if libmemkind supports it.
	(omp_aligned_alloc, omp_free, omp_aligned_calloc, omp_realloc): Add
	memkind support of LIBGOMP_USE_MEMKIND is defined.
	* config/linux/allocator.c: New file.
2022-06-09 10:14:42 +02:00
GCC Administrator
58b67140de Daily bump. 2022-06-04 00:16:27 +00:00
Tobias Burnus
ff35a75473 OpenMP/Fortran: Add support for firstprivate and allocate clauses on scope construct
Fortran commit to C/C++/backend commit
r13-862-gf38b20d68fade5a922b9f68c4c3841e653d1b83c

gcc/fortran/ChangeLog:

	* openmp.cc (OMP_SCOPE_CLAUSES): Add firstprivate and allocate.

libgomp/ChangeLog:

	* libgomp.texi (OpenMP 5.2): Mark scope w/ firstprivate/allocate as Y.
	* testsuite/libgomp.fortran/scope-2.f90: New test.

gcc/testsuite/ChangeLog:

	* gfortran.dg/gomp/scope-5.f90: New test.
	* gfortran.dg/gomp/scope-6.f90: New test.
2022-06-03 15:54:02 +02:00
GCC Administrator
b168441c8a Daily bump. 2022-06-03 00:16:40 +00:00
David Malcolm
6cf276ddf2 diagnostics: add SARIF output format
This patch adds support to gcc's diagnostic subsystem for emitting
diagnostics in SARIF, aka the Static Analysis Results Interchange Format:
  https://sarifweb.azurewebsites.net/
by extending -fdiagnostics-format= to add two new options:
  -fdiagnostics-format=sarif-stderr
and:
  -fdiagnostics-format=sarif-file

The patch targets SARIF v2.1.0

This is a JSON-based format suited for capturing the results of static
analysis tools (like GCC's -fanalyzer), but it can also be used for plain
GCC warnings and errors.

SARIF supports per-event metadata in diagnostic paths such as
["acquire", "resource"] and ["release", "lock"] (specifically, the
threadFlowLocation "kinds" property: SARIF v2.1.0 section 3.38.8), so
the patch extends GCC"s diagnostic_event subclass with a "struct meaning"
with similar purpose.  The patch implements this for -fanalyzer so that
the various state-machine-based warnings set these in the SARIF output.

The heart of the implementation is in the new file
diagnostic-format-sarif.cc.  Much of the rest of the patch is interface
classes, isolating the diagnostic subsystem (which has no knowledge of
e.g. tree or langhook) from the "client" code in the compiler proper
cc1 etc).

The patch adds a langhook for specifying the SARIF v2.1.0
"artifact.sourceLanguage" property, based on the list in
SARIF v2.1.0 Appendix J.

The patch adds automated DejaGnu tests to our testsuite via new
scan-sarif-file and scan-sarif-file-not directives (although these
merely use regexps, rather than attempting to use a proper JSON parser).

I've tested the patch by hand using the validator at:
  https://sarifweb.azurewebsites.net/Validation
and the react-based viewer at:
  https://microsoft.github.io/sarif-web-component/
which successfully shows most of the information (although not paths,
and not CWE IDs), and I've fixed all validation errors I've seen (though
bugs no doubt remain).

I've also tested the generated SARIF using the VS Code extension linked
to from the SARIF website; I'm a novice with VS Code, but it seems to be
able to handle my generated SARIF files (e.g. showing the data in the
SARIF tab, and showing squiggly underlines under issues, and when I
click on them, it visualizes the events in the path inline within the
source window).

Has anyone written an Emacs mode for SARIF files? (pretty please)

gcc/ChangeLog:
	* Makefile.in (OBJS): Add tree-diagnostic-client-data-hooks.o and
	tree-logical-location.o.
	(OBJS-libcommon): Add diagnostic-format-sarif.o; reorder.
	(CFLAGS-tree-diagnostic-client-data-hooks.o): Add TARGET_NAME.
	* common.opt (fdiagnostics-format=): Add sarif-stderr and sarif-file.
	(sarif-stderr, sarif-file): New enum values.
	* diagnostic-client-data-hooks.h: New file.
	* diagnostic-format-sarif.cc: New file.
	* diagnostic-path.h (enum diagnostic_event::verb): New enum.
	(enum diagnostic_event::noun): New enum.
	(enum diagnostic_event::property): New enum.
	(struct diagnostic_event::meaning): New struct.
	(diagnostic_event::get_logical_location): New vfunc.
	(diagnostic_event::get_meaning): New vfunc.
	(simple_diagnostic_event::get_logical_location): New vfunc impl.
	(simple_diagnostic_event::get_meaning): New vfunc impl.
	* diagnostic.cc: Include "diagnostic-client-data-hooks.h".
	(diagnostic_initialize): Initialize m_client_data_hooks.
	(diagnostic_finish): Clean up m_client_data_hooks.
	(diagnostic_event::meaning::dump_to_pp): New.
	(diagnostic_event::meaning::maybe_get_verb_str): New.
	(diagnostic_event::meaning::maybe_get_noun_str): New.
	(diagnostic_event::meaning::maybe_get_property_str): New.
	(get_cwe_url): Make non-static.
	(diagnostic_output_format_init): Handle
	DIAGNOSTICS_OUTPUT_FORMAT_SARIF_STDERR and
	DIAGNOSTICS_OUTPUT_FORMAT_SARIF_FILE.
	* diagnostic.h (enum diagnostics_output_format): Add
	DIAGNOSTICS_OUTPUT_FORMAT_SARIF_STDERR and
	DIAGNOSTICS_OUTPUT_FORMAT_SARIF_FILE.
	(class diagnostic_client_data_hooks): New forward decl.
	(class logical_location): New forward decl.
	(diagnostic_context::m_client_data_hooks): New field.
	(diagnostic_output_format_init_sarif_stderr): New decl.
	(diagnostic_output_format_init_sarif_file): New decl.
	(get_cwe_url): New decl.
	* doc/invoke.texi (-fdiagnostics-format=): Add sarif-stderr and
	sarif-file.
	* doc/sourcebuild.texi (Scan a particular file): Add
	scan-sarif-file and scan-sarif-file-not.
	* langhooks-def.h (lhd_get_sarif_source_language): New decl.
	(LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE): New macro.
	(LANG_HOOKS_INITIALIZER): Add
	LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE.
	* langhooks.cc (lhd_get_sarif_source_language): New.
	* langhooks.h (lang_hooks::get_sarif_source_language): New field.
	* logical-location.h: New file.
	* plugin.cc (struct for_each_plugin_closure): New.
	(for_each_plugin_cb): New.
	(for_each_plugin): New.
	* plugin.h (for_each_plugin): New decl.
	* tree-diagnostic-client-data-hooks.cc: New file.
	* tree-diagnostic.cc: Include "diagnostic-client-data-hooks.h".
	(tree_diagnostics_defaults): Populate m_client_data_hooks.
	* tree-logical-location.cc: New file.
	* tree-logical-location.h: New file.

gcc/ada/ChangeLog:
	* gcc-interface/misc.cc (gnat_get_sarif_source_language): New.
	(LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE): Redefine.

gcc/analyzer/ChangeLog:
	* checker-path.cc (checker_event::get_meaning): New.
	(function_entry_event::get_meaning): New.
	(state_change_event::get_desc): Add dump of meaning of the event
	to the -fanalyzer-verbose-state-changes output.
	(state_change_event::get_meaning): New.
	(cfg_edge_event::get_meaning): New.
	(call_event::get_meaning): New.
	(return_event::get_meaning): New.
	(start_consolidated_cfg_edges_event::get_meaning): New.
	(warning_event::get_meaning): New.
	* checker-path.h: Include "tree-logical-location.h".
	(checker_event::checker_event): Construct m_logical_loc.
	(checker_event::get_logical_location): New.
	(checker_event::get_meaning): New decl.
	(checker_event::m_logical_loc): New.
	(function_entry_event::get_meaning): New decl.
	(state_change_event::get_meaning): New decl.
	(cfg_edge_event::get_meaning): New decl.
	(call_event::get_meaning): New decl.
	(return_event::get_meaning): New decl.
	(start_consolidated_cfg_edges_event::get_meaning): New.
	(warning_event::get_meaning): New decl.
	* pending-diagnostic.h: Include "diagnostic-path.h".
	(pending_diagnostic::get_meaning_for_state_change): New vfunc.
	* sm-file.cc (file_diagnostic::get_meaning_for_state_change): New
	vfunc impl.
	* sm-malloc.cc (malloc_diagnostic::get_meaning_for_state_change):
	Likewise.
	* sm-sensitive.cc
	(exposure_through_output_file::get_meaning_for_state_change):
	Likewise.
	* sm-taint.cc (taint_diagnostic::get_meaning_for_state_change):
	Likewise.
	* varargs.cc
	(va_list_sm_diagnostic::get_meaning_for_state_change): Likewise.

gcc/c/ChangeLog:
	* c-lang.cc (LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE): Redefine.
	(c_get_sarif_source_language): New.
	* c-tree.h (c_get_sarif_source_language): New decl.

gcc/cp/ChangeLog:
	* cp-lang.cc (LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE): Redefine.
	(cp_get_sarif_source_language): New.

gcc/d/ChangeLog:
	* d-lang.cc (d_get_sarif_source_language): New.
	(LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE): Redefine.

gcc/fortran/ChangeLog:
	* f95-lang.cc (gfc_get_sarif_source_language): New.
	(LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE): Redefine.

gcc/go/ChangeLog:
	* go-lang.cc (go_get_sarif_source_language): New.
	(LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE): Redefine.

gcc/objc/ChangeLog:
	* objc-act.h (objc_get_sarif_source_language): New decl.
	* objc-lang.cc (LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE): Redefine.
	(objc_get_sarif_source_language): New.

gcc/testsuite/ChangeLog:
	* c-c++-common/diagnostic-format-sarif-file-1.c: New test.
	* c-c++-common/diagnostic-format-sarif-file-2.c: New test.
	* c-c++-common/diagnostic-format-sarif-file-3.c: New test.
	* c-c++-common/diagnostic-format-sarif-file-4.c: New test.
	* gcc.dg/analyzer/file-meaning-1.c: New test.
	* gcc.dg/analyzer/malloc-meaning-1.c: New test.
	* gcc.dg/analyzer/malloc-sarif-1.c: New test.
	* gcc.dg/plugin/analyzer_gil_plugin.c
	(gil_diagnostic::get_meaning_for_state_change): New vfunc impl.
	* gcc.dg/plugin/diagnostic-test-paths-5.c: New test.
	* gcc.dg/plugin/plugin.exp (plugin_test_list): Add
	diagnostic-test-paths-5.c to tests for
	diagnostic_plugin_test_paths.c.
	* lib/gcc-dg.exp: Load scansarif.exp.
	* lib/scansarif.exp: New test.

libatomic/ChangeLog:
	* testsuite/lib/libatomic.exp: Add load_gcc_lib of scansarif.exp.

libgomp/ChangeLog:
	* testsuite/lib/libgomp.exp: Add load_gcc_lib of scansarif.exp.

libitm/ChangeLog:
	* testsuite/lib/libitm.exp: Add load_gcc_lib of scansarif.exp.

libphobos/ChangeLog:
	* testsuite/lib/libphobos-dg.exp: Add load_gcc_lib of scansarif.exp.

Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-06-02 15:40:22 -04:00
GCC Administrator
820ead4519 Daily bump. 2022-06-01 00:16:34 +00:00
Jakub Jelinek
f38b20d68f openmp: Add support for firstprivate and allocate clauses on scope construct
OpenMP 5.2 adds support for firstprivate and allocate clauses on the scope
construct and this patch adds that support to GCC.
5.2 unfortunately (IMNSHO mistakenly) marked scope construct as worksharing,
which implies that it isn't possible to nest inside of it other scope,
worksharing loop, sections, explicit barriers, single etc. which would
make scope far less useful.  I'm not implementing that part, keeping the
5.1 behavior here, and will file an issue to revert that for OpenMP 6.0.
But, for firstprivate it keeps the restriction that is now implied from
worksharing construct that listed var can't be private in outer context,
where for reduction 5.1 had similar restriction explicit even for scope
and 5.2 has it implicitly through worksharing construct.

2022-05-31  Jakub Jelinek  <jakub@redhat.com>

gcc/
	* omp-low.cc (build_outer_var_ref): For code == OMP_CLAUSE_ALLOCATE
	allow var to be private in the outer context.
	(lower_private_allocate): Pass OMP_CLAUSE_ALLOCATE as last argument
	to build_outer_var_ref.
gcc/c/
	* c-parser.cc (OMP_SCOPE_CLAUSE_MASK): Add firstprivate and allocate
	clauses.
gcc/cp/
	* parser.cc (OMP_SCOPE_CLAUSE_MASK): Add firstprivate and allocate
	clauses.
gcc/testsuite/
	* c-c++-common/gomp/scope-5.c: New test.
	* c-c++-common/gomp/scope-6.c: New test.
	* g++.dg/gomp/attrs-1.C (bar): Add firstprivate and allocate clauses
	to scope construct.
	* g++.dg/gomp/attrs-2.C (bar): Likewise.
libgomp/
	* testsuite/libgomp.c-c++-common/allocate-1.c (foo): Add testcase for
	scope construct with allocate clause.
	* testsuite/libgomp.c-c++-common/allocate-3.c (foo): Likewise.
	* testsuite/libgomp.c-c++-common/scope-2.c: New test.
2022-05-31 11:41:52 +02:00
GCC Administrator
37b3b5dabd Daily bump. 2022-05-29 00:16:31 +00:00
Tobias Burnus
e3803f9cbb OpenMP/Fortran: Add support for enter clause on declare target
Fortran version to C/C++ commit r13-797-g0ccba4ed8571c18c7015413441e971

gcc/fortran/ChangeLog:

	* dump-parse-tree.cc (show_omp_clauses): Handle OMP_LIST_ENTER.
	* gfortran.h: Add OMP_LIST_ENTER.
	* openmp.cc (enum omp_mask2, OMP_DECLARE_TARGET_CLAUSES): Add
	OMP_CLAUSE_ENTER.
	(gfc_match_omp_clauses, gfc_match_omp_declare_target,
	resolve_omp_clauses): Handle 'enter' clause.

libgomp/ChangeLog:

	* libgomp.texi (OpenMP 5.2): Mark 'enter' clause as supported.
	* testsuite/libgomp.fortran/declare-target-1.f90: Extend to test
	explicit 'to' and 'enter' clause.
	* testsuite/libgomp.fortran/declare-target-2.f90: Update accordingly.

gcc/testsuite/ChangeLog:

	* gfortran.dg/gomp/declare-target-2.f90: Add 'enter' clause test.
	* gfortran.dg/gomp/declare-target-4.f90: Likewise.
2022-05-28 20:42:38 +02:00
Jakub Jelinek
42fd2cd932 libgomp: Don't define GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC for _aligned_malloc [PR105745]
since apparently _aligned_malloc requires freeing with _aligned_free and:
 /* Defined if gomp_aligned_alloc doesn't use fallback version
    and free can be used instead of gomp_aligned_free.  */
 #define GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC 1
so the second condition isn't satisfied.  For uses inside of the OpenMP
allocators we can still use _aligned_malloc but we need to call _aligned_free
in gomp_aligned_free.

2022-05-28  Jakub Jelinek  <jakub@redhat.com>

	PR libgomp/105745
	* libgomp.h (GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC): Don't define for
	defined(HAVE__ALIGNED_MALLOC) case.
	* alloc.c (gomp_aligned_alloc): Move defined(HAVE__ALIGNED_MALLOC)
	handling as last option before fallback instead of first.
	(gomp_aligned_free): For defined(HAVE__ALIGNED_MALLOC) call
	_aligned_free.
2022-05-28 08:30:47 +02:00
GCC Administrator
d9176e643f Daily bump. 2022-05-28 00:16:40 +00:00
Jakub Jelinek
0ccba4ed85 openmp: Add support for enter clause on declare target
OpenMP 5.1 and earlier had 2 different uses of to clause, one for target
update construct with one semantics, and one for declare target directive
with a different semantics.
Under the hood we were using OMP_CLAUSE_TO_DECLARE to represent the latter.
OpenMP 5.2 renamed the declare target clause to to enter, the old one is
kept as a deprecated alias.

As we are far from having full OpenMP 5.2 support, this patch adds support
for the enter clause (and renames OMP_CLAUSE_TO_DECLARE to OMP_CLAUSE_ENTER
with a flag to tell the spelling of the clause for better diagnostics),
but doesn't deprecate the to clause on declare target just yet (that
should be done as one of the last steps in 5.2 support).

2022-05-27  Jakub Jelinek  <jakub@redhat.com>

gcc/
	* tree-core.h (enum omp_clause_code): Rename OMP_CLAUSE_TO_DECLARE
	to OMP_CLAUSE_ENTER.
	* tree.h (OMP_CLAUSE_ENTER_TO): Define.
	* tree.cc (omp_clause_num_ops, omp_clause_code_name): Rename
	OMP_CLAUSE_TO_DECLARE to OMP_CLAUSE_ENTER.
	* tree-pretty-print.cc (dump_omp_clause): Handle OMP_CLAUSE_ENTER
	instead of OMP_CLAUSE_TO_DECLARE, if OMP_CLAUSE_ENTER_TO, print
	"to" instead of "enter".
	* tree-nested.cc (convert_nonlocal_omp_clauses,
	convert_local_omp_clauses): Handle OMP_CLAUSE_ENTER instead of
	OMP_CLAUSE_TO_DECLARE.
gcc/c-family/
	* c-pragma.h (enum pragma_omp_clause): Add PRAGMA_OMP_CLAUSE_ENTER.
gcc/c/
	* c-parser.cc (c_parser_omp_clause_name): Parse enter clause.
	(c_parser_omp_all_clauses): For to clause on declare target, use
	OMP_CLAUSE_ENTER clause with OMP_CLAUSE_ENTER_TO instead of
	OMP_CLAUSE_TO_DECLARE clause.  Handle PRAGMA_OMP_CLAUSE_ENTER.
	(OMP_DECLARE_TARGET_CLAUSE_MASK): Add enter clause.
	(c_parser_omp_declare_target): Use OMP_CLAUSE_ENTER instead of
	OMP_CLAUSE_TO_DECLARE.
	* c-typeck.cc (c_finish_omp_clauses): Handle OMP_CLAUSE_ENTER instead
	of OMP_CLAUSE_TO_DECLARE, to OMP_CLAUSE_ENTER_TO use "to" as clause
	name in diagnostics instead of
	omp_clause_code_name[OMP_CLAUSE_CODE (c)].
gcc/cp/
	* parser.cc (cp_parser_omp_clause_name): Parse enter clause.
	(cp_parser_omp_all_clauses): For to clause on declare target, use
	OMP_CLAUSE_ENTER clause with OMP_CLAUSE_ENTER_TO instead of
	OMP_CLAUSE_TO_DECLARE clause.  Handle PRAGMA_OMP_CLAUSE_ENTER.
	(OMP_DECLARE_TARGET_CLAUSE_MASK): Add enter clause.
	(cp_parser_omp_declare_target): Use OMP_CLAUSE_ENTER instead of
	OMP_CLAUSE_TO_DECLARE.
	* semantics.cc (finish_omp_clauses): Handle OMP_CLAUSE_ENTER instead
	of OMP_CLAUSE_TO_DECLARE, to OMP_CLAUSE_ENTER_TO use "to" as clause
	name in diagnostics instead of
	omp_clause_code_name[OMP_CLAUSE_CODE (c)].
gcc/testsuite/
	* c-c++-common/gomp/clauses-3.c: Add tests with enter clause instead
	of to or modify some existing to clauses to enter.
	* c-c++-common/gomp/declare-target-1.c: Likewise.
	* c-c++-common/gomp/declare-target-2.c: Likewise.
	* c-c++-common/gomp/declare-target-3.c: Likewise.
	* g++.dg/gomp/attrs-9.C: Likewise.
	* g++.dg/gomp/declare-target-1.C: Likewise.
libgomp/
	* testsuite/libgomp.c-c++-common/target-40.c: Modify some existing to
	clauses to enter.
	* testsuite/libgomp.c/target-41.c: Likewise.
2022-05-27 12:48:48 +02:00
Tobias Burnus
8255b49ed8 libgomp.texi: Add more to-be-implemented OpenMP 5.2 features
libgomp/
	* libgomp.texi (Other new OpenMP 5.1 features): Add
	'begin declare target'.
	(Other new OpenMP 5.2 features): New.
2022-05-27 10:19:45 +02:00
GCC Administrator
3dff965cae Daily bump. 2022-05-26 00:16:30 +00:00
Jakub Jelinek
c125f504c4 libgomp: Fix occassional hangs with taskwait nowait depend
Richi reported occassional hangs with taskwait-depend-nowait-1.*
tests and I've finally manged to reproduce.  The problem is if
taskwait depend without nowait is encountered soon after
taskwait depend nowait and the former depends on the latter and there
is no other work to do, the taskwait depend without nowait is put
to sleep, but the empty_task optimization in
gomp_task_run_post_handle_dependers wouldn't wake it up in that
case.  gomp_task_run_post_handle_dependers normally does some wakeups
because it schedules more work (another task), which is not the
case of empty_task, but we need to do the wakeups that would be done
upon task completion so that we awake sleeping threads when the
last child is done.
So, the taskwait-depend-nowait-1.* testcase is fixed with the
else if (__builtin_expect (task->parent_depends_on, 0) part of
the patch.
The new testcase can hang on another problem, if the empty task
is the last task of a taskgroup, we need to use atomic store
like elsewhere to decrease the counter to 0, and wake up taskgroup
end if needed.
Yet another spot which can sleep is normal taskwait (without depend),
but I believe nothing needs to be done for that - in that case we
await solely until the children's queue has no tasks, tasks still
waiting for dependencies aren't accounted in that, but the reason
is that if taskwait should wait for something, there needs to be at least
one active child doing something (in the children queue), which then
possibly awakes some of its siblings when the dependencies are met,
or in the empty task case awakes further dependencies, but in any
case the child that finished is still handled as active child and
will awake taskwait at the end if there is nothing further to
do.
Last sleeping case are barriers, but that is handled by ++ret and
awaking the barrier.

2022-05-25  Jakub Jelinek  <jakub@redhat.com>

	* task.c (gomp_task_run_post_handle_dependers): If empty_task
	is the last task taskwait depend depends on, wake it up.
	Similarly if it is the last child of a taskgroup, use atomic
	store instead of decrement and awak taskgroup wait if any.
	* testsuite/libgomp.c-c++-common/taskwait-depend-nowait-2.c: New test.
2022-05-25 11:10:41 +02:00