4.10.0 fails to build with NVHPC compiler

[cponder]

I ran into this error in the build:

#66 167.1 [ 4%] Building Fortran object src/funit/core/CMakeFiles/funit-core.dir/TestSuite.F90.o
#66 167.4 NVFORTRAN-S-0155-Empty generic procedure - at$tbpg (/usr/local/src/pFUnit-4.10.0/src/funit/core/TestSuite.F90: 90)
#66 167.4 0 inform, 0 warnings, 1 severes, 0 fatal for counttestcases
#66 167.7 make[2]: *** [src/funit/core/CMakeFiles/funit-core.dir/build.make:634: src/funit/core/CMakeFiles/funit-core.dir/TestSuite.F90.o] Error 2
#66 167.7 make[1]: *** [CMakeFiles/Makefile2:524: src/funit/core/CMakeFiles/funit-core.dir/all] Error 2
#66 167.7 make: *** [Makefile:166: all] Error 2

It doesn't happen with 4.9.0.
Obvious possibilities are that (1) this is a violation of the Fortran standard, or (2) a bug in the compiler, can you confirm?

Also, is this just a failure to build the unit-tests, with the library being built OK?
If so, is there a workaround?

[tclune]

@cponder I believe this is just a new form of an error that we have encountered before. The most recent version of pFUnit has updated the version of containers (gFTL) that are used. We've seen problems with %at() in other parts of the GEOS stack previously - this just leaks the problem into a layer that had previously been immune. I'm fairly confident that the code is standard conforming. I'll look again to see if I can think of a good workaround.

[tclune]

Some success. I've got a workaround in gFTL that appears to let the entire GFE stack compile with nvfortran.

Still playing with the runtime tests in case I can identify other easy fixes for that. But in any event it will take a few days to roll this into a release due to the fact that it touches a few different repos within GFE.

[cponder]

That's fine. For now, I'm rolling back to 4.9.0. I'll move up to 4.10.1 as soon as you have it ready.

[tclune]

@cponder OK - things are somewhat worse than I had hoped yesterday. Some of the self-tests fail to comply and these indicate that the compiler is frequently failing to manage the namespace of type-bound procedures correctly. I will try to isolate a minimal reproducer to send you separately, but will not try to workaround all of these at this time.

[tclune]

Well - even a reproducer is going to be too much trouble unless you can just take an updated GFE and build it yourself.

It appears (as just one example) that some procedure of() in pFUnit is leaking into the module that is testing of() acting on an iterator. In none of my code is of() a PUBLIC entity in any module - they are always TBPs with only the derived type being actually public.

Having said that, I don't quite see why the "iterator" tests compile but the "riterator" (reverse iterator) tests show this issue. The code is very similar between them. Best guess is that since an RIterator contains an Iterator object itself it is just that much more confusion about which "of()" is involved.

If I delete those lines, then I start getting with other procedures that have somewhat common names like "add()".

[mathomp4]

I am seeing this same error with NVHPC 24.7 in my testing today:

[ 69%] Building Fortran object pFUnit/src/funit/core/CMakeFiles/funit-core.dir/TestSuite.F90.o
NVFORTRAN-S-0155-Empty generic procedure - at$tbpg (/ford1/share/gmao_SIteam/Baselibs/ESMA-Baselibs-8.5.0/src/GFE/pFUnit/src/funit/core/TestSuite.F90: 90)
  0 inform,   0 warnings,   1 severes, 0 fatal for counttestcases
gmake[4]: *** [pFUnit/src/funit/core/CMakeFiles/funit-core.dir/build.make:634: pFUnit/src/funit/core/CMakeFiles/funit-core.dir/TestSuite.F90.o] Error 2
gmake[4]: Leaving directory '/ford1/share/gmao_SIteam/Baselibs/ESMA-Baselibs-8.5.0/src/GFE/build'
gmake[3]: *** [CMakeFiles/Makefile2:1384: pFUnit/src/funit/core/CMakeFiles/funit-core.dir/all] Error 2

This is with GFE 1.16.0 → pFUnit v4.10.0, gFTL v1.14.0 so I guess this is still an issue?

[cponder]

Yeah, still an issue with the NVHPC 24.9 compiler as well.
I filed a bug against the compiler.

[mathomp4]

Yeah, still an issue with the NVHPC 24.9 compiler as well. I filed a bug against the compiler.

Oh. Huh. I am currently building Baselibs with 24.9 and I guess I haven't hit this yet. Well, I guess I will in ~30 minutes!

[mathomp4]

Confirmed same error.