https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109128
Bug ID: 109128
Summary: [Offload][OpenMP][OpenACC] Static linking with unused
offload function will lead to mismatch number of
offload fn/symbols
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: openacc, openmp, wrong-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
gfortran -fopenmp one.f90
ar rcv libone.a one.o
ranlib libone.a
gfortran -fopenmp two.f90 -L. -lone
With GCN, it prints:
libgomp: Cannot map target functions or variables (expected 0, have 2)
The issue seems to be related to the linker removing the the symbol from
__OFFLOAD_TABLE__ (i.e. from the .gnu.offload_funcs sections, which has
first/last the__offload_func_table and __offload_funcs_end symbols, whose
pointer is put into the __OFFLOAD_TABLE__).
But the removed symbol is still visible to the offload compiler, i.e. it ends
up in the GOMP_register_var call as generated by
gcc/config/{gcn,nvptx}/mkoffload.cc
It is not quite clear which permutations work or cause problems.
It seems as if the common block (both files have then '.comm' sections) is
important. Whether 'libone.a' also fails or only '-L. -lone' seems to be
inconsistent (some minor details). Additionally, having a libgomp library call
also in the main program is also required.
==> one.f90 <==
module m
implicit none
integer :: my_var
common /my_common/ my_var
contains
integer function unused_func(n) result(res)
integer :: n
!$omp target map(from:res) firstprivate(n)
res = 5*n
!$omp end target
end
end module m
==> two.f90 <==
use m
implicit none
integer :: A
!$omp target enter data map(A)
end
