F2018: TS 29113 Compliance

Accelerated Computing HPC Compilers nvc, nvc++ and nvfortran
1

Hi, I am writing to inquire about an issue with the NVIDIA NVHPC toolchain I initially reported in LLNL/zfp#163.

Lawrence Livermore National Laboratory’s (LLNL) ZFP conforms to the Fortran 2018 standard in its C to Fortran interface while using the c_ptrdiff_t type from ISO_C_BINDING as well as others already present in earlier standards. However, there currently is no support for these types. Further problems are encountered when attempting to replace them with equivalents, the callee receiving unrecognizable values. Thus, at the moment, it is not possible to compile and use a functional version of ZFP that utilizes the ZFP to Fortran interface, using NVHPC, thereby not letting users leverage Cuda GPU acceleration. I notice that OLCF’s Summit’s zfp-gpu module does not include Fortran bindings.

These additional interoperability features, which include c_ptrdiff_t, were initially described in TS 29113 (“Further interoperability of Fortran with C”) and were implemented by many compiler vendors as an extension to F2003/2008 (DOI 10.1145/2179280.2179282). To the best of my knowledge, TS 29113 was formally included and extended as part of Fortran 2018. NVFortran implicitly advertises compliance with ISO/IEC 1539-1 : 2018, Information technology – Programming Languages – Fortran, Geneva, 2018 (Fortran 2018) in the Compatibility and Conformance to Standards section of the NVHPC SDK’s online documentation by listing it under “further information”. I, unfortunately, do not have access to these ISO standards and therefore can only assume that the aforementioned standard includes the additional C interrogability features mentioned in The new features of Fortran 2018 by the WG5 sub-committee, as well as compilers’ documentation/release notes/statuses such as GNU’s. The referenced ISO document is the -1 part of the full F2018 standard but the other sections either appear to be withdrawn, related to other concerns, or nonexistent (in our case). I am not certain how vastly the “Base Language” title should be interpreted as.

I apologize in advance for any inaccuracies as I don’t have access to ISO standards and am trying to reconstruct the feature’s history from a diverse set of sources. I was only trying to decipher why we couldn’t access to these features.

In any case, I believe that these additional C interoperability features with Fortran ought to be included in the NVHPC toolchain, as C–Fortran binding is important to many codes, and these new features improve the development experience as well as the reliability of the written software.

In the issue I mentioned at the beginning of this post, I explain in some detail this and other issues faced while building and running a simple Fortran test program using ZFP, relating to the NVHPC toolchain. I would appreciate it if you could consider adding support for these features to a future release of the NVHPC SDK. Using LLNL/zfp#163 to work on this problem would be beneficial because you might discover other issues, especially in the handling of C enumerations (mentioned in issue).

Thank you for your time and consideration.

2

Hi henryleberre,

Apologies for the wrong impression, but the inclusion of the relevant language standards was not intended to imply full compliance with these standards. A bit further on that page, table 1 indicates that we full comply with F2003.

For F2008 and F2018, we’re part of the community effort Flang F18 project, a complete rebuild of our Fortran front-end with the goal to be fully F2018 compliant. While I don’t have a timeline, once F18 is production ready, our current plan would be to switch nvfortran to use this new front-end.

As a stop-gap, we do add some F2008 and F2018 features as requested by users depending on the need and difficulty in implementation. Looks like we do already have a request for c_ptrdiff_t, which appears to be slated for our 22.9 release. I can’t guarantee it will be the final release (sometimes new features are pulled if they are found to have issues), but please give 22.9 a try once it’s out later this month.

-Mat

3

Thank you very much MatColgrove and jeffhammond for the clarification and help on this issue. I wasn’t sure whether this was a bug or an unimplemented feature. Since some major F2018 features had already been implemented (particularly standard parallelism) and the ISO standard was referenced, I naïvely assumed NVFortran was an F2018 compiler. I expect most codes probably don’t rely on all of the new features.

Switching to the Flang front-end is an excellent idea. My experience with Flang and the LLVM toolchain in general has been excellent. The middle-end and the back-end are what make NVHPC such a great toolkit for HPC with NVIDIA GPUs.

@jeffhammond I haven’t looked into this issue in quite some time since I circumvented it by creating my own C wrapper & Fortran interface, but it would be my pleasure to help.