What compilers and platforms should be supported

[certik]

Let's use this issue to figure out what compilers we have to support (which version and platform).

For my own usage I need at least:

• GFortran (master works as of f300f4a)
• Intel Fortran (master works as of f300f4a)
• NAG (Workarounds for NAG #108)

In addition my colleagues use: PGI (#107), Cray, IBM.

[certik]

In addition I suggest we only use features that work with CMake.

[milancurcic]

I agree that supporting and testing on as many compilers as we can is good for stdlib. I'm concerned that requiring support for several compilers may put a brake on the language features we can use for implementation. (example: do all compilers support finalization? I don't know)

Ensuring that non-free compilers build and run stdlib will require some custom CI+CD hacking with dedicated machines with these compilers.

For start, can we require support for free compilers at first, run it through CI with free tools, and then work on scripts that members with access to Cray, IBM, and similar machines could run there and provide build reports?

[certik]

We need to try and see. For the CI, we would simply use gfortran, and we would just test other compilers by hand. Later we can see if there is a way to automate it.

[zbeekman]

One of the nice things about CMake is its introspection capabilities. Rather than maintaining a list of supported compilers & compiler versions you can test at configure time if a certain language feature is working and enable it or disable it as part of the build.

Additionally, there are ways to BYOL (bring your own license) for the commercial compilers.

[certik]

I tested GFortran, Intel, NAG and PGI, and updated the issue description, either things work, or I created an issue.

I do not have access to other compilers such as Cray or IBM. Does anyone have access to those?

[scivision]

IBM arch is available via Travis-CI--I haven't tried to see if no-cost XL compiler is also there.
On CMake's Gitlab instance, there are a couple people who have contributed code to CMake for Cray Fortran:

• Chuck Craynor
• Willem Deconinck

[scivision]

If stdlib brings in Fortran 2008 improvements, then the current releases of all commonly used Fortran compilers should be doable. Corner cases can be handled by build system detection.

• NAG 7.0 - OK Fortran 2008 as would be used by stdlib
• PGI 19.10 - OK Fortran 2008. PGI 19.4 was a lot buggier/missing syntax
• Gfortran >= 6 OK Fortran 2008
• Intel >= 16 (2016)
• Flang >= 6
• Cray (several years ago)
• IBM (several years ago)

That leaves a few small but impactful communities using Fortran 95 compilers and Fortran 2003-ish compilers. Will those communities have migrated to newer compilers by the time stdlib is "ready".

[MarDiehl]

I think for a standard library, it is important to have clear rules on the following questions:

1. Which Fortran standard is required. While this question sounds simple, most of the compilers implement even older standards only partly and a few corner case statements are missing (see e.g. https://gcc.gnu.org/wiki/Fortran2008Status)
2. What do we do if a compiler theoretically compiles a certain statement, but execution crashes during runtime or gives wrong results (I experienced that for do concurrent)

For applications, it is practicable to specify a compiler version explicitly (Requires GNU > 8.1 or Intel > 18.1, but note that 18.2 has a bug, etc).
On the long term, if the standard library project is successful, missing features are probably more relevant than actual compiler bugs. Let's assume that the Compiler update from version X to Y results in invalid code for do concurrent, but do concurrent is used in the standard library. Hopefully, the compiler vendors will run the test suite of the standard library before releasing version Y and know that they have to fix their product.

The most practical way is probably the use of a test suite that contains all supported compiler versions. Then one can make a case by case decision whether it is worth to drop compatibility with a certain compiler to support a certain statement.

[jvdp1]

The most practical way is probably the use of a test suite that contains all supported compiler versions. Then one can make a case by case decision whether it is worth to drop compatibility with a certain compiler to support a certain statement.

Is it possible to implement such a test suite with GitHub CI? Maybe at least for free compilers?