https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70945
Bug ID: 70945
Summary: Offloading: compatibility of target and offloading
toolchains
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: openacc, openmp
Severity: enhancement
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
It has been established that for offloading compilation, the target and
offloading toolchains need to be compatible (for example: data types; bit-wise
copying of data).
For OpenACC/OpenMP, offloading is implemented such that the target compiler
already applies certains transformations to the source code before handing over
to the offloading compilers an intermediate representation of the relevant
pieces.
Looking at one specific example: inclusion of <math.h> under the presence of
-ffinite-math-only (as implied by -ffast-math, or -Ofast). The (glibc)
<math.h> will then (__FINITE_MATH_ONLY__) include <bits/math-finite.h> for
"special entry points to use when the compiler got told to only expect finite
results". In the configuration that I'm looking at right now, this works by
diverting the math functions' assembler names from "[function]" to
"__[function]_finite". This is a "bits/[...]" header file, that is applicable
only to this one target's glibc configuration. For nvptx offloading, for
example, we use newlib which doesn't provide these finite math entry points, so
when using the "log" function in offloaded code, you'll see the compilation
fail because of "unresolved symbol __log_finite".
The problem basically is that there is a mis-match between early
transformations done by the target compiler (such as via header files, or done
early in the compiler internally), that are not actually valid for the
offloading compilers. Instead of playing "rat race", trying to make the target
and offloading toolchains/compilers/ABIs match completely (which probably isn't
even possible in the general case), can we maybe find a better solution?
Of course, this problem is applicable only if we agree that it is valid to use
such functions in offlodead regions, which indeed is debatable for a lot of
standard library functions, but for math functions clearly users expect to be
allowed to use them. Also consider Fortran, where such functions are actually
part of the language.
