https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68463
Bug ID: 68463
Summary: Offloading fails when some objects are compiled with
LTO and some without
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: openacc, openmp
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: iverbin at gcc dot gnu.org
Target Milestone: ---
The reproducer:
$ cat foo.c
void foo ()
{
#pragma omp target
;
}
$ cat bar.c
void bar ()
{
#pragma omp target
;
}
$ cat main.c
extern void foo ();
extern void bar ();
int main ()
{
foo ();
bar ();
return 0;
}
$ gcc -c -fopenmp -flto foo.c
$ gcc -c -fopenmp bar.c main.c
$ gcc -fopenmp foo.o bar.o main.o
main.o: In function `main':
main.c:(.text+0x14): undefined reference to `bar'
collect2: error: ld returned 1 exit status
This happens because the linker plugin in claim_file_handler claims bar.o, and
linker just drops it, because linker considers bar.o as LTO object.
Without offload it claims only LTO objects, but now it claims objects with any
IR. (Yes, offloading misuses lto-plugin and lto-wrapper a bit.)
And even worse, it fails with -foffload=disable, because we decided to stream-
out offload IR unconditionally:
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00628.html
So -foffload=disable only disables compilation of target images in lto-wrapper,
but objects are handled by linker plugin before that.
The first solution that comes to mind - do not claim objects, which contain
offload IR without LTO IR. But this will cause run-time error:
"libgomp: Cannot map target functions or variables (expected 1, have 2)",
because lto-wrapper will surround only *.ltrans.o (derived from foo.o) with
crtoffload{begin,end}.o; and bar.o will be added at the end of the list of
objects from lto-wrapper. But we need this order to get correct host table:
"crtoffloadbegin.o, *.ltrans.o, bar.o, crtoffloadend.o".
Here is a bit more about tables:
https://gcc.gnu.org/wiki/Offloading#Address_mapping_tables
Or maybe we should implement new linker offload-plugin with its
offload-wrapper,
but I don't know how difficult it would be to support 2 plugins in the linkers,
and it really doesn't solve the issue with crtoffload{begin,end}.o placement.
Or maybe just print an error during linking that offloading doesn't support
mixing LTO and non-LTO objects (even if some of them doesn't have offload)?
