Hi! For example, Fortran source code that uses the ABORT intrinsic, such as:
program main
implicit none
print *, "CheCKpOInT"
!$omp target
call abort
!$omp end target
end program main
... currently indeed does terminate program execution, for example with
Intel MIC (emulated) offloading:
CheCKpOInT
/tmp/offload_5YrtEq/offload_target_main: symbol lookup error:
/tmp/offload_5YrtEq/lib0000000000.so: undefined symbol: _gfortran_abort
offload error: process on the device 0 unexpectedly exited with code 0
..., but that is clearly not how that is meant to happen (missing
_gfortran_abort symbol). This can be "fixed" with an explicit
-foffload=-lgfortran to tell the offloading compiler(s) that the
libgfortran support library needs to be brought in.
As ABORT and similar intrinsics are part of the Fortran language, my
assumption is that users expect that they can use such intrinsics inside
offloaded code, even more so for mathematical functions and the like,
<https://gcc.gnu.org/onlinedocs/gfortran/Intrinsic-Procedures.html>.
The same conceptual problem exists with nvptx OpenACC offloading. Bernd
has once implemented a -Xoffload option which then can be used such as
proposed in <http://gcc.gnu.org/ml/gcc-patches/2015-05/msg01269.html>;
see the changes to lang_specific_driver in gcc/fortran/gfortranspec.c, to
have it add -Xoffload options to link -lgfortran and -lm. Given all the
logic in gcc/fortran/gfortranspec.c dealing with libgfortran (and also
the math library for that matter), I'm not convinced that such a simple
approach (always add these "-Xoffload -lgfortran -Xoffload -lm" options)
is sufficient in all offloading configuration cases. (And, why can't we
use the existing -foffload instead of adding a new -Xoffload option?)
(And then of course, there is the issue that the libgomp Fortran
testsuite doesn't even use the gfortran driver, but instead manually adds
-lgfortran to the xgcc command line. I have a patch series to address
this, <http://gcc.gnu.org/ml/gcc-patches/2014-11/msg00157.html>, but
that's an orthogonal problem.)
A similar problem does not exist when inside offloaded regions you're
using functions that are provided by libgomp itself. If my understanding
is correct, due to the -fopenacc/-fopenmp flags appearing on the
offloading compilers' command line, this will again cause the libgomp
link spec (libgomp/libgomp.spec.in) to be added, which will link in the
offload targets' libgomp. Also, the offloading compilers' default link
spec does include libc and libgcc, so C/C++ source code, for example,
using the C library's abort function in offloaded code does work as
expected.
How should we handle libgfortran and libm dependencies in offloaded code?
As the linking requirements especially regarding libgfortran may be
different for each offloading target (shared and/or static libraries
supported, static linking enforced, libquadmath needed, and so on), I
think the specific configuration must happen inside the offloading
execution path (mkoffload). Thus, trying to do this inside the gfortran
front end, gcc/fortran/gfortranspec.c:lang_specific_driver etc., does not
appear to be doing it the right way; for offloaded code, we'll always be
using the lto1 front end instead of the gfortran one. Is a libgfortran
link spec like libgomp's, together with some flag (similar to
-fopenmp/-fopenacc being used with the libgomp link spec) the right thing
to do?
Grüße,
Thomas
signature.asc
Description: PGP signature
