What compilers and platforms should be supported about stdlib HOT 13 OPEN

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.

from stdlib.

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

from stdlib.

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?

from stdlib.

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.

from stdlib.

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?

from stdlib.

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

from stdlib.

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

from stdlib.

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.

from stdlib.

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?

from stdlib.

For GCC we can test across versions. I would guess offhand that at least back to GCC 6 is OK.

For Intel oneAPI, I ran across a GitHub repo that was demoing using Intel oneAPI no-cost compiler in GitHub Actions. Intel provide oneAPI Docker container but this repo was using the PPA / apt install method that they claimed was faster.
Unfortunately I didn't bookmark that GitHub repo but I could probably find it again if this is of interest.
The oneAPI HPC toolkit provides a rebadged Intel Parallel Studio XE compiler for Fortran, C, C++ but with less strict licensing (currently, no login is required to download oneAPI compilers and libraries).

What I understand from the last Fortran stdlib conference call is that LLVM Flang/f18 might be ready in the next year or so to use for this.

Travis has PowerPC arch available, but I don't know if the XL Fortran compiler is installed there.

PGI has cloud images available, but given the general bugginess at the moment of PGI 19.10 for Fortran 2003 I'm not sure if that would be worth the effort yet.

from stdlib.

Another possibility would be to provide a conda forge package and use their well developed CI (windows, Mac, Linux). Since this could be seen as a misuse of resources, we should ask beforehand.

from stdlib.

Another possibility would be to provide a conda forge package and use their well developed CI (windows, Mac, Linux). Since this could be seen as a misuse of resources, we should ask beforehand.

I think this is the way to go for the long term. But I guess that we should have first a first version/release, right?

from stdlib.

For Intel oneAPI, I ran across a GitHub repo that was demoing using Intel oneAPI no-cost compiler in GitHub Actions. Intel provide oneAPI Docker container but this repo was using the PPA / apt install method that they claimed was faster.
Unfortunately I didn't bookmark that GitHub repo but I could probably find it again if this is of interest.

@scivision Thank you for this input. It could be a possiblity, at least for the short term. It would be nice if you could find back the GitHub repo :)

from stdlib.