[patch][v2a] libgomp: Add interop types and routines to OpenMP's headers and module

2024-08-22 Thread Tobias Burnus
This is nearly identical to v2, except that I presumably used 'git add 
testsuite' when intending to use 'git add -u testsuite' in a last-minute 
change as it contained a bunch of unrelated test files …


The only other change besides removing unrelated files  is that for the 
generic part of omp_get_interop_type_desc, the data types ('int' for 
fr_id, vendor, device_num; const char*' for fr_name, vendor_name) are 
now returned in target.c while the specific types (for device, 
device_context, targetsync platform) will eventually be handled by the 
plugin function.


Tobias

Am 21.08.24 um 20:27 schrieb Tobias Burnus:
Nearly identical to v1, except that I realized that OpenMP permits to 
call those functions also from target regions.


Hence, those also got those functions, including a use of 
omp_irc_other to make clear why it will fail …


In addition, two (nonhost) target-region test files were added.

Comments, remarks, suggestions before I commit it?

Otherwise, the following still applies:
This patch adds 'interop' to C/C++'s omp.h and Fortran's omp_lib.h 
and omp_lib module.


The implementation should match OpenMP 5.1 (which added interop) and 
also TR13; the Fortran routine support is new in TR13. It also adds 
'hsa' as foreign object enum/paramter, which is currently being added 
to the additional-definitions document.


* * *

The routine interface does not exactly match the OpenMP spec as some 
VALUE and BIND(C) and one c_int has been used to reduce pointless 
differences between OpenMP and C/C++.


This shouldn't affect the usage as almost no user will worries about 
the API used for a procedure reference. But if a user defines the 
routine interface him-/herself, this will fail. (But why should 
(s)he? There is 'omp_lib.h' and the 'omp_lib' module, after all – and 
several items in those files are implementation defined.)


On the C/C++ side, there are also some differences (at least with 
TR13) with regards to unsigned vs. signed and to enum (of size 
__UINTPTR_T__) vs. 'typdef (u)intptr_t', but they shouldn't matter 
either (effectively same API) – and, again, there is a omp.h, which 
any sensible user should use.


* * *

While there is a stub implementation for the routines, to make them 
really useful, two things are missing: Support for the 'interop' 
directive in the compiler itself (+ a libgomp function for it) and 
supporting some foreign run time types in the libgomp plugin. Also 
missing is the documentation of the added routines in libgomp.texi. 
All of which will be added in later patches.


Build + tested on x86-64-gnu-linux (with offloading enabled but 
that's not yet relevant). 


Cheers,

Tobiaslibgomp: Add interop types and routines to OpenMP's headers and module

This commit adds OpenMP 5.1+'s interop enumeration, type and routine
declarations to the C/C++ header file and, new in OpenMP TR13, also to
the Fortran module and omp_lib.h header file.

While a stub implementation is provided, only with foreign runtime
support by the libgomp GPU plugins and with the 'interop' directive,
this becomes really useful.

libgomp/ChangeLog:

	* fortran.c (omp_get_interop_str_, omp_get_interop_name_,
	omp_get_interop_type_desc_, omp_get_interop_rc_desc_): Add.
	* libgomp.map (GOMP_5.1.3): New; add interop routines.
	* omp.h.in: Add interop typedefs, enum and prototypes.
 	* omp_lib.f90.in: Add paramters and interfaces for interop.
	* omp_lib.h.in: Likewise; move F90 '&' to column 81 for
	-ffree-length-80.
	* target.c (omp_get_num_interop_properties, omp_get_interop_int,
	omp_get_interop_ptr, omp_get_interop_str, omp_get_interop_name,
	omp_get_interop_type_desc, omp_get_interop_rc_desc): Add.
	* config/gcn/target.c (omp_get_num_interop_properties,
	omp_get_interop_int, omp_get_interop_ptr, omp_get_interop_str,
	omp_get_interop_name, omp_get_interop_type_desc,
	omp_get_interop_rc_desc): Add.
	* config/nvptx/target.c (omp_get_num_interop_properties,
	omp_get_interop_int, omp_get_interop_ptr, omp_get_interop_str,
	omp_get_interop_name, omp_get_interop_type_desc,
	omp_get_interop_rc_desc): Add.
	* testsuite/libgomp.c/interop-routines-1.c: New test.
	* testsuite/libgomp.c/interop-routines-2.c: New test.
	* testsuite/libgomp.fortran/interop-routines-1.F90: New test.
	* testsuite/libgomp.fortran/interop-routines-2.F90: New test.
	* testsuite/libgomp.fortran/interop-routines-3.F: New test.
	* testsuite/libgomp.fortran/interop-routines-4.F: New test.
	* testsuite/libgomp.fortran/interop-routines-5.F: New test.
	* testsuite/libgomp.fortran/interop-routines-6.F: New test.
	* testsuite/libgomp.fortran/interop-routines-7.F90: New test.

 libgomp/config/gcn/target.c|  99 +++
 libgomp/config/nvptx/target.c  |  99 +++
 libgomp/fortran.c  |  41 +++
 libgomp/libgomp.map|  15 +
 libgomp/omp.h.in   |  69 +
 libgomp/omp_lib.f90.in | 

PR 116468: Segmentation fault at intrinsic assignment to allocatable array component of derived type with kind type parameter

2024-08-22 Thread Damian Rouson
A program compiled with gfortran terminates with a segmentation fault
at an intrinsic assignment to an allocatable array component of a
derived type with a kind type parameter.  Please see below.  I tried
several workarounds, including replacing the intrinsic assignment with
a type-bound defined assignment, a non-type-bound defined assignment,
and a source allocation.  I also tried compiling code below with
gfortran 12, 13, and 14.  The only workaround that eliminates the
segmentation fault is switching to source allocation.  The code below
terminates normally with the NAG and LLVM Flang (Flang-new) compilers.

% cat reproducer.f90
  implicit none

  type foo_t(k)
integer, kind :: k
real(k), allocatable :: bar(:)
  end type

  type(foo_t(kind(0.))) foo

  foo%bar = [0.]
end

% gfortran reproducer.f90

% ./a.out

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x102dfad2f
#1  0x102df9d83
#2  0x194afa583
#3  0x1027c7f4b
zsh: segmentation fault  ./a.out

% gfortran --version
GNU Fortran (Homebrew GCC 14.1.0_2) 14.1.0