Issue with NVFORTRAN With NVHPC 25.3

[jcabrerard]

I'm running tests on RHEL9, trying to install openmpi-5.0.7 from source with nvhpc-25.3. I downloaded the tarball from the releases page. However, I'm running into the following in the "make" step:
...
...
GENERATE psizeof_f.f90
FC psizeof_f.lo
NVFORTRAN-S-0081-Illegal selector - KIND parameter has unknown value for data type (psizeof_f.f90: 89)
0 inform, 0 warnings, 1 severes, 0 fatal for pmpi_sizeof_complex16_scalar
NVFORTRAN-S-0081-Illegal selector - KIND parameter has unknown value for data type (psizeof_f.f90: 99)
0 inform, 0 warnings, 1 severes, 0 fatal for pmpi_sizeof_complex16_r1
...
...
NVFORTRAN-S-0081-Illegal selector - KIND parameter has unknown value for data type (psizeof_f.f90: 159)
0 inform, 0 warnings, 1 severes, 0 fatal for pmpi_sizeof_complex16_r7
make[3]: *** [Makefile:2591: psizeof_f.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/dist/apps/openmpi/openmpi-5.0.7/ompi/mpi/fortran/mpif-h/profile'
make[2]: *** [Makefile:3440: all-recursive] Error 1
make[2]: Leaving directory '/dist/apps/openmpi/openmpi-5.0.7/ompi/mpi/fortran/mpif-h'
make[1]: *** [Makefile:2710: all-recursive] Error 1
make[1]: Leaving directory '/dist/apps/openmpi/openmpi-5.0.7/ompi'
make: *** [Makefile:1539: all-recursive] Error 1

I found this issue to be very similar to the one described in #8616, but when tried to apply the patches described in the fix, I couldn't find any differences.

Any advice would be appreciated.

Regards,

[antoine-morvan]

Could reproduce on several systems (x86_64 & aarch64 ; RHEL, Ubuntu, AmazonLinux) with exact same versions of OpenMPI and NVHPC. I also tried rolling back with

• NVHPC 25.1 : no issue
• OpenMPI 5.0.6 : exact same issue

[ggouaillardet]

It looks like a different issue.

NVHPC now supports real(REAL16) (I tried 25.3, no support in 24.7) but not complex(REAL16).
Open MPI assumes if the former is supported, so is the latter.

You can re-run configure with ompi_cv_fortran_have_iso_fortran_env_real16=n to forcibly disable ISO_FORTRAN_ENV:REAL16 support, and you should be good.

An other workaround is to build with gcc/g++/nvfortran (REAL16 is disabled for a different reason e.g. non matching type sizes).

I will issue a PR shortly (it will test both real(REAL16) and complex(REAL16).

@bosilca @jeffhammond could you please ping your compiler folks about this limitation?

[jeffhammond]

There are more use cases for half precision real than complex. Adding all the complex number stuff isn't trivial, so it makes sense why it isn't there yet.

I will note this nonetheless.

[antoine-morvan]

You can re-run configure with ompi_cv_fortran_have_iso_fortran_env_real16=n to forcibly disable ISO_FORTRAN_ENV:REAL16 support, and you should be good.

I could build just by adding this at the end of my configure line. Did not check what's actually disabled.

[jcabrerard]

Compilation was successful after setting the flag ompi_cv_fortran_have_iso_fortran_env_real16=n

Thank you very much.

Best,

[ggouaillardet]

@jcabrerard if you tell me your full name, I will credit you for reporting this issue in the commit message.

[jeffhammond]

The feedback from the compiler team is that kind=REAL16 is supported only for use with REAL() and will not be supported by COMPLEX() within the lifetime of the current NVHPC Fortran front-end (the one based on PGI). As you know, NVIDIA is leading the development of LLVM Flang, which should support COMPLEX(kind=REAL16) (it probably already does, but I haven't verified).

[ggouaillardet]

Thanks @jeffhammond !

I can confirm complex(REAL16) is already supported in upstream LLVM 19.

The PR I issued disables ISO_FORTRAN_ENV:REAL16 with NVHPC regardless they only support real(REAL16) or not.
If too much of a limitation for some real use cases, I guess I will be able to do something about it later.

[jcabrerard]

@jcabrerard if you tell me your full name, I will credit you for reporting this issue in the commit message.

You don't have to, but this is Jorge Cabrera, with the University of Florida.

Thank you,

[jsquyres]

@jcabrerard Yes we do! We very much value when users report issues and help test the solution. Thank you!