does not compile with nvhpc-25.9 (cuda 12.9)

[gwiecz1]

Hello,
As the tittle suggests. Enclosed is the full terminal output of the attempt. For short:

cd GPU
in ci/install.sh:
c_c=70,80
cuda_ver=12.9

./ci/install.sh
(...) <= goes well until:
mpif90 -cpp -traceback -g -fast -Mdalign -r8 -acc -gpu=cc70,cc80,cuda12.9,unroll -Minline=maxsize:340 -cuda -I../wrappers -c attach.f
NVFORTRAN-S-0084-Illegal use of symbol sort - attempt to CALL a non-SUBROUTINE (attach.f: 72)
NVFORTRAN-S-0084-Illegal use of symbol sort - attempt to CALL a non-SUBROUTINE (attach.f: 101)
NVFORTRAN-S-0084-Illegal use of symbol sort - attempt to CALL a non-SUBROUTINE (attach.f: 133)

I would be grateful for any suggestions.
Best regards,
g

tinker-hp_build.txt

[opadjoua]

Hello,

Thank you for your remark. We shall account for it later on

It seems latest SDK compilers include sort as a default Built-in symbol. We have not built Tinker-HP with that setup yet. As mentioned inside the prerequisites.md directives, it is convenient to build the app using older SDK versions like (HPC-SDK 22.7 + cuda11.7 + GNU-11.x.x).
That said, I suggest you rebuild with (SDK24-7 + cuda 12.5) . Even not explicitely mentioned, I tested that setup, and it worked fine.

Regards,

[gwiecz1]

Hi!
Thank you for your reply, opadjoua.
I got it compiled, but it became a little more complicated. Here's what I've noticed.

1. There was a small race condition in GPU/source/Makefile.pgi (with make 4.4.1), which showed up when I was compiling with 1 job (ci/install.sh 1). Namely, make tried to compile MOD_spectra.f prior to MOD_beads.f, while the latter is the dependency of the former. Hence, small change in the makefile was required.
2. As of the sort* subroutines, its more mysterious (as my fortran has rusted a lot, and my cuda fortran never got top notch). attach.f uses utilgpu, while utilgpu uses cudafor from nvhpc. It turns out, that the use of cudafor (at least the one from nvhpc 25.9) changes the compiler behavior in a way, that even after pasting the sort subroutine into attach.f, it was still not visible to the compiler, and I was getting the same error. So, I moved the content of sort.f into module MOD_sort.f, and used it in all sources requiring it.
3. inf of MOD_utilgpu.f had to be made public explicitly.
4. Compiler warned about ptr in function acc_malloc_bc and queue in acc_get_cuda_stream_c in MOD_utilgpu.f, complaining that these should not have intent - i stripped it.
5. domdecstuff.f, using sort2 at line 300, does so with violation of argument types when compiling for mixed precision (and deterministic reduction) - the list in domdecstuff is real(r_p), while the sort2 takes real(t_p). I added sort2a subroutine to the MOD_sort.f and used it in domdecstuff.

Enclosed is the patch documenting all these shenanigans, I thought it might be of some use. So far tinker-hp works great and gives me reasonable results, which might suggest that I did not break too much. I suspect though, that my changes may not be optimal. Therefore, I would be grateful for suggestions/comments, including these regarding the proper testing procedure.
By the way, some developer docs would be a great thing ;)
Thank you and all the best!
g

01.patch.gz