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 <[email protected]> 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



Reply via email to