gFTL does not support PGI

[mathomp4]

This is a simple one. I found out today as I was trying to build gFTL with PGI 18.5 that it doesn't support PGI. I see two issues:

1. There is no cmake_utils/PGI.cmake file
2. If I add one, it doesn't seem to actually pass the tests.

[mathomp4]

As for the PGI.cmake, I added a temporary one in my local test based on translating the GNU.cmake file into PGI speak as close as I could:

# Compiler specific flags for NVIDIA PGI Fortran compiler

set(no_optimize "-O0")
set(check_all "-Mbounds -Mchkfpstk -Mchkptr -Mchkstk ")
set(traceback "-traceback")
set(cpp "-Mpreprocess")


set(CMAKE_Fortran_FLAGS_DEBUG  "${no_optimize}")
set(CMAKE_Fortran_FLAGS_RELEASE "-fast")
set(CMAKE_Fortran_FLAGS "-g ${cpp} ${traceback} ${check_all}")

I could easily make a branch/pull request for this.

[mathomp4]

As for the make tests:

(1098)((HEAD detached at a7d6dc2)) $ make tests
[  1%] Built target shared
[  4%] Built target template_macros
[ 15%] Built target types
[ 21%] Built target altsetSUT
[ 32%] Built target type_test_values
[ 39%] Built target vectorSUT
[ 39%] Building Fortran object tests/Vector/CMakeFiles/testVector.dir/Test_FooPolyPtrVector.F90.o
PGF90-S-0034-Syntax error at or near end of line (Test_FooPolyPtrVector.pf: 952)
PGF90-S-0070-Incorrect sequence of statements  (Test_FooPolyPtrVector.pf: 953)
PGF90-S-0034-Syntax error at or near identifier block (Test_FooPolyPtrVector.pf: 958)
  0 inform,   0 warnings,   3 severes, 0 fatal for test_set
make[3]: *** [tests/Vector/CMakeFiles/testVector.dir/Test_FooPolyPtrVector.F90.o] Error 2
make[2]: *** [tests/Vector/CMakeFiles/testVector.dir/all] Error 2
make[1]: *** [tests/CMakeFiles/tests.dir/rule] Error 2
make: *** [tests] Error 2

This is @tclune level of knowledge to figure out. I'm going to fiddle around with PGI.cmake to see if there is a missing flag I need.

[mathomp4]

Thing I just learned. gFTL + PGI does not like make -j tests. It was...spectacular in its failure.

Also, adding -Mallocatable=03 didn't seem to help either.

[tclune]

I presume the “-j” is not the culprit?

I’m not surprised that PGI struggles. I guess it is time for me to set down and file some bug reports with them …

On Aug 1, 2018, at 9:43 AM, Matthew Thompson <[email protected]mailto:[email protected]> wrote:

Thing I just learned. gFTL + PGI does not like make -j tests. It was...spectacular in its failure.

Also, adding -Mallocatable=03 didn't seem to help either.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Goddard-Fortran-Ecosystem/gFTL/issues/22#issuecomment-409579313, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AF7_4Np54cLbyGqVKtQDwneJzE5Y7MIMks5uMbCYgaJpZM4VqguS.

[martin-schlipf]

Are there any plans to make gFTL support PGI?

With PGI version 19.10 the following program

program test
    implicit none
    type(integer) foo
end program test

does not compile with PGI and therefore the gFTLVector which use this construct do not compile either.

[tclune]

First, gFTL itself does not use the particular construct that you mentioned. gFTL-shared does use the construct, but I have created a permanent branch feature/pgi-workarounds in that repo to support PGI. I'm reluctant to retreat from perfectly legal syntax that is widely supported. Though if I'd realized PGI lacked support for that particular feature, I'd probably have avoided it anyway.

The big problem is that PGI is hopelessly broken for my unit testing framework, which makes it difficult/annoying to test gFTL against the PGI compiler. For containers of scalar intrinsics (except strings), I would expect that PGI should work just fine. Issues are more likely to be encountered for containers with polymorphic elements and/or deferred length strings. But even those may well work.

Having said all this, I would very much like to have gFTL work with all compilers including PGI and will happily except PR's that don't break the other compilers. (And may even implement solutions myself if the compiler workaround is sufficiently simple/obvious.)

[martin-schlipf]

I'm mostly interested in the unit testing framework and gFTL-shared was just the first thing the PGI compiler complained about.

[tclune]

Ah - I did make a bit of effort again a few months back, but the 4.0 branch is a real challenge for PGI. I am willing to take out some F2008 syntax to get things to work under PGI (mostly this is polymorphic assignment), but that alone was not sufficient.

One strategy you might consider: your unit tests are about checking your code not the compiler. Presuming your application can port to GFortran, Intel, and/or NAG, you could run your unit tests in that environment. Yes - it may fail to identify code for which the PGI compiler gets wrong answers, but that should be a relatively rare.

I'll also ping my colleague at PGI (NVIDIA) to see if they have energy to work through the issues. Someone there used an earlier version of pFUnit to purge several compiler bugs and thanked me. Maybe they have resources to do so again. (I think their Flang project has them distracted though.)

[tclune]

My contact at PGI indicated he is interested in helping. I'll try to recover my PGI workarounds and get something to him next week.