Workarounds for the PGI compiler

[certik]

I am using PGI 18.10 and the latest master (f300f4a):

1. It does not support error stop and stderr:

--- a/src/f08estop.f90
+++ b/src/f08estop.f90
@@ -19,22 +19,22 @@ module procedure error_stop
 !
 ! call error_stop("Invalid argument")
 
-write(stderr,*) msg
+write(*,*) msg
 
 if(present(code)) then
   select case (code)
   case (1)
-    error stop 1
+    stop 1
   case (2)
-    error stop 2
+    stop 2
   case (77)
-    error stop 77
+    stop 77
   case default
-    write(stderr,*) 'ERROR: code ',code,' was specified.'
-    error stop
+    write(*,*) 'ERROR: code ',code,' was specified.'
+    stop
   end select
 else
-  error stop
+  stop
 endif
 end procedure

2. It does not support qp and it can't even declare real(qp) (it says "kind must be positive", but it is negative because qp is not supported). So one has to remove all qp code. How to implement same procedures for different numeric kinds #35 will fix this.

3. Then there is an internal compiler error that I haven't figured out yet what causes it:

[ 73%] Building Fortran object src/tests/io/CMakeFiles/test_open.dir/test_open.f90.o
PGF90-F-0000-Internal compiler error. interf:new_symbol, symbol not found     629  (/users/certik/repos/stdlib/src/tests/io/test_open.f90: 4)
PGF90/x86-64 Linux 18.10-0: compilation aborted

[scivision]

Until PGI 19.4, PGI struggled with Fortran 2003 and 2008 is really buggy if there at all. 19.10 was the first PGI that was usable with Fortran 2008 syntax in my opinion.

[awvwgk]

I just tested NVHPC 20.9 and it still fails to compile stdlib, with roughly the same errors as already highlighted in this issue.

[Romendakil]

Our code never worked with NVHPC or its predecessor PGI. There were so many errors already at the level of F2003 code. And it really compiles a factor 3-5 slower than ifort.

I just tested NVHPC 20.9 and it still fails to compile stdlib, with roughly the same errors as already highlighted in this issue.

[scivision]

Since Intel oneAPI:

• has "complete" Fortran 2018 support
• is free to use (not just for education as with prior license)
• generally has better performance than PGI/NVHPC for CPU tasks

and since as above PGI/NVHPC still has trouble with Fortran 2003 support, I don't really consider using it in my work. Those who need to use NVHPC for GPU are already stuck with Fortran 95 syntax and stdlib would, in my opinion, become significantly more of a maintenance burden and more heavily reliant on preprocessors.

[awvwgk]

Those who need to use NVHPC for GPU are already stuck with Fortran 95 syntax and stdlib would, in my opinion, become significantly more of a maintenance burden and more heavily reliant on preprocessors.

So true... 😢

[scivision]

Also, there's the triumvirate of NVHPC, Flang classic, and LLVM/F18 Flang. I am not sure what Nvidia's long term plan is, it could be that they're pouring effort into f18 Flang to then rebase NVHPC on. That would be pretty awesome.
In the meantime, there are a significant community of HPC devs who seem to feel that Fortran 95 (or 77) + preprocessing stack is adequate for now, so I can't speak for them. My approach is to simply use the current Fortran standard in my work, and make shims to interface with the older preprocessed Fortran when needed.

I am almost always able to avoid compiler preprocessors by using CMake or Meson configure_file to avoid duplicated code for select type and select rank. Well, I've just pushed the preprocessing up to the build system, but this helps me avoid compiler quirks as I also have to do this when accommodating Fortran file system operations across operating systems--which is where some of the compiler quirks broke my Fortran preprocessing, but easily worked with configure_file in CMake or Meson.

[Carltoffel]

Quick update:
I tried to compile a project which uses stdlib via fpm dependency with nvfortran 22.3.
Disclaimer: tested means it compiles, I cannot test correctness until I fixed every error (if I manage to do)
So far I got the following errors:

• Although error stop is supported by now, there is a compiler bug, which does not allow variable names which start with “module” (e.g., module_name in stdlib_logger) in the same line. Workaround: Search and replace error stop with stop (tested) or module_name with something like mod_name (only tested in dummy program)
• shiftl and shiftr are not supported. Workaround: replace them with lshift and rshift (tested)
• In the files stdlib_stats_mean, stdlib_stats_var and stdlib_stats_moment_all the kind keyword in the count function calls (e.g., n = real(count(mask, kind = int64), sp)) throws NVFORTRAN-S-0079-Keyword form of argument illegal in this context for kind. Workaround: Remove the kind argument (tested, but I expect this to change the behaviour)
• write(formatted) etc. in stdlib_string_type.f90 raises NVFORTRAN-S-0034-Syntax error at or near identifier formatted. Workaround: Delete everything related to this (tested, but this obviously removes features)
• bgt and blt are not supported. Workaround: Implement them (not tested, I just deleted stdlib_bitsets*)

[Romendakil]

* Although `error stop` is supported by now, there is a compiler bug, which does not allow variable names which start with “module” (e.g., `module_name` in `stdlib_logger`) in the same line. Workaround: Search and replace `error stop` with `stop` (tested) or `module_name` with something like `mod_name` (only tested in dummy program)

* `shiftl` is not supported. Workaround: replace it with `lshift` (tested)

* E.g. `n = real(count(mask, kind = int64), sp)` in `stdlib_stats_moment_all.f90` throws `NVFORTRAN-S-0079-Keyword form of argument illegal in this context for kind`. Workaround: _didn't try to fix it yet_

Did you actually report all those compiler bugs and problems to the nVidia team? Our lab didn't continue the license, so I only regularly post on their forum, and their support picks it up from there. We never managed to successfully compile and run our code with nVidia (or PGI before).

[Carltoffel]

I will try to collect some more errors, update my comment and then report them.

[Carltoffel]

I've posted my problems in the nvidia forum:
https://forums.developer.nvidia.com/t/building-fortran-standard-library-stdlib-fails/213461
It's currently hidden, because I used two links in one post, which has triggered the spam filter. 🙄

[mcolg]

FYI, I'm looking into these issue now and have mails out to engineering about items #1 and #3. I'll post an update on our forums once I can give complete answers.

For #1, the initial issue does look more to be a parse error with the variable name beginning with "module_" but I don't think it's still quite right even if the variable name is changed. It only works when using literal strings or if the variable name's has the same or more number of characters as the string that's being printed. Again, waiting on feedback from engineering.

For #2, I reported the issue (TPR #31784)

For #3, Still looking into it.

For #4, these are known. I'll push on engineering to see if we can get them added.

To respond to scivision's earlier comment, yes, much of our effort is focused on F18 development and our current plan is to move nvfortran to use the F18 code base. No idea on when that will be, but hopefully sometime in the next few years if all goes well.

For the missing F2008/F2018 features in nvfortran/"classic" flang, we'll still add them depending on the feature, difficulty to implement, and if there's enough demand. We're just not proactively adding them. Reporting on our forums which features you're looking for helps with gauging demand. Big items, like co-arrays, will need to wait for F18.

[milancurcic]

For #3, Still looking into it.

Thanks @mcolg! I recently hit 3. with nvfortran trying to build neural-fortran and found this thread:

https://forums.developer.nvidia.com/t/nvfortran-f-0000-internal-compiler-error-interf-new-symbol-symbol-not-found/185901

It looks like you filed it as TPR #30461 (thank you!)

[mcolg]

It looks like TPR #30461 should be fixed in our upcoming 22.5 release. I just tested it, and it no longer fails.

% nvfortran test.F90  -c -V22.3
NVFORTRAN-F-0000-Internal compiler error. interf:new_symbol, symbol not found     625  (test.F90: 87)
NVFORTRAN/x86-64 Linux 22.3-0: compilation aborted
% nvfortran test.F90 -c -V22.5
%

My usual caveat is that I'm testing with a pre-released version still under going testing. While unlikely, there have been cases when a fix causes other issues so is pulled at the last minute. Hence, I can't guarantee the fix will be in final 22.5, it's just likely to be.

Hopefully, this fixes your item as well.

[fedebenelli]

I've tried to compile my library (that uses stdlib) with nvfortran and got the following error:

<ERROR> Compilation failed for object " build_dependencies_stdlib_src_stdlib_string_type.f90.o "
<ERROR> stopping due to failed compilation
STOP 1
NVFORTRAN-S-0034-Syntax error at or near identifier formatted (build/dependencies/stdlib/src/stdlib_string_type.f90: 29)
NVFORTRAN-S-0034-Syntax error at or near identifier formatted (build/dependencies/stdlib/src/stdlib_string_type.f90: 30)
  0 inform,   0 warnings,   2 severes, 0 fatal for stdlib_string_type

It seems that nvfortran can't compile custom derived type I/O?

[Romendakil]

I would not waste too much time on nvfortran. As far as I know the future of this compiler is uncertain. It never fully supported even Fortran2003, let alone Fortran2008. nVidia now supports a lot their new LLVM-based implementation, flang(-new), and I would guess that the same will happen as to the "classical" ifort: it will be deprecated sometime in the future.