OpenACC offloading strange result

[Patrick Begou]

Hi Salvatore,

I met this problem many times on a really large application. In my 
understanding, the problem relies on the use of libraries containing 
subroutines with kernels. I had several discussions with some GNU 
developers about using a more recent GNU ld linker but I was never able 
to solve the problem.

The only way working for me is to explicitly link with all the "*.o" 
objects and not wit "-lmylib".

Workaround for GNU quite easy do to with some macros in a Makefile. I 
never meet the problem with other compilers.

Patrick



Le 15/10/2025 à 13:59, Salvatore Filippone a écrit :
> An update which I do not fully understand: the failure happens in code 
> inside a module linked into the test program.
> Now, if I copy the module by hand into the test program source code 
> and recompile, the failure goes away.
> Any suggestions on where to look for the error greatly appreciated
> Salvatore
>
> On Wed, Oct 15, 2025 at 10:50 AM Salvatore Filippone 
> <filippone.salvatore@gmail.com> wrote:
>
>     Hi there,
>     I am stuck by a strange problem when compiling with
>               -fopenacc -foffload=nvptx-none=-march=sm_75
>     a code that used to work until relatively recently, is now
>     sistematically throwing the following (or similar) error:
>     libgomp: Cannot map target functions or variables (expected 25,
>     have 20)
>
>     The error comes from allocation of a vector in a derived typein a
>     test program of a complex library; the vector is then subject to
>     something like this
>
>       subroutine oad_sync_space(x)
>         implicit none
>         class(oad_vect), intent(inout) :: x
>         if (allocated(x%v)) then
>           call d_oad_create_dev(x%v)
>         end if
>       contains
>         subroutine d_oad_create_dev(v)
>           implicit none
>           real :: v(:)
>           !$acc enter data copyin(v)
>         end subroutine d_oad_create_dev
>       end subroutine oad_sync_space
>
>     and the failure I showed happens on the enter data directive.
>     Now, I have partially cheated: the above code is extracted from 
>     an attempt to produce a reduced test case: if I only keep  the
>     reduced code (with the reduced type/class definitions) it works,
>     but when I link with the full library code it fails.
>
>     Do you have any suggestions on how to go about debugging this?
>     Should I ask on a different mailing list?
>
>     Full code available if anybody wants to take a look at it.
>     Thanks a lot
>     Salvatore
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/fortran/attachments/20251015/610383d1/attachment.htm>