Stdlib: Workarounds for the PGI compiler

[certik]

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

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

1. 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. #35 will fix this.

2. 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... :cry:

[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.