search

fortran-lang / stdlib

Fortran Standard Library
https://stdlib.fortran-lang.org
MIT License
1.03k stars 162 forks source link

Workarounds for the PGI compiler #107

Open certik opened 4 years ago

certik commented 4 years ago

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)

  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 commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Since Intel oneAPI:

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 commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

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:

Romendakil commented 2 years ago 
* 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 commented 2 years ago

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

Carltoffel commented 2 years ago

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. :roll_eyes:

mcolg commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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.