Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Minimum Fortran standard and compiler bugs #202

Closed
MarDiehl opened this issue May 30, 2020 · 3 comments
Closed

Minimum Fortran standard and compiler bugs #202

MarDiehl opened this issue May 30, 2020 · 3 comments

Comments

@MarDiehl
Copy link
Contributor

Excuse me if I have missed an existing discussion on this question, but I think it is rather important to explicitly state the minimum Fortran standard that is required to use the library.

According to http://fortranwiki.org/fortran/show/Fortran+2008+status a reasonable amount of F2008 is available in Cray, GNU, IBM, Intel, and PGI compilers. Flang is certainly also a candidate for modern Fortran.

I have tried Intel, GNU, and PGI (community edition) and made the following experiences:

  1. GNU: Can handle most of the syntax, but has issues with variable-length strings, user-defined IO, and derived types (finalize)
  2. Intel: Among the three tested compilers the most reliable one
  3. PGI: Feature-wise behind Intel and GNU, severe bugs.

Based on this, I use only code that compiles and runs with Intel and GNU.

I think for a standard library, it is of utmost importance 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 knows 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 minimum compiler version (Requires Intel > 18.1, but note that 18.2 has a bug, or GNU > 8.1). If we would do something like that with a standard library, we are easily involved in politics with the compiler vendors. They might not be happy to hear that the standard library is not compatible with their product because they have not implemented statement XY.
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. However, I don't want to waive the use of error stop just because some of the compiler vendors think that F77 is modern enough

@certik
Copy link
Member

certik commented May 30, 2020

Great points. I believe this is a duplicate of #15. Do you want to merge the two issues, for example by copying your arguments there and closing this one?

@milancurcic
Copy link
Member

We mentioned this briefly in #188 but didn't make further progress. Yes, I think this is needed, especially regarding compilers and supported versions, less so for standard revisions.

I think error stop and newunit are the only F2008 features we use, the rest is F2003 or earlier. I don't think we're using anything F2018 yet.

@MarDiehl
Copy link
Contributor Author

duplicate

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants