Following the discontinuation of the ACM Fortran Forum (ACM Fortran Forum Editor) and its recurrent publication of Fortran compiler support tables, it is becoming increasingly difficult for me to track progress in the implementation of modern Fortran standards across different compilers.
For those not familiar with them (or with no access to them), since 2007 there were about 30 revisions of a publication with a set of tables (one per published Fortran standard, since the 2003 one) that indicated what “new features” (as described in the corresponding “The New Features of Fortran 20xx” document by John Reid) were supported by reasonably recent versions of a range of compilers. The tables were similar to those in the Fortran Wiki, see, e.g., Fortran 2008 status in Fortran Wiki .
The historical set of tables proved quite useful to me in a number of cases, since they helped answer questions such as “has it been long enough since the 3 main compilers our users have access to started supporting feature X?” (so that it is reasonable that we start using it in our code), and enabled a certain level of user support (“we don’t have access to your compiler, but according to table T1 the bug you reported may be due to your compiler version not supporting feature Y; according to T2 this should work with the newer version V, can you give it a try?”).
While other developers might have other views, given the “paper” format, in my opinion the tables provided a reasonable level of granularity in terms of functionalities, level of support (“yes”, “no”, “partial” - with a footnote), and compiler versions (for some vendors, there was an update every major release).
While I understand that there is some level of interest in creating a new Fortran periodical, I think these recurring tables could survive in a separate format: an online, searchable database. This could bring a range of benefits:
Open access.
Easier browsing (interactively search by functionality keyword, view the description of the functionality, display only a selection of compilers, cells with colours, etc.).
Entries easier to be annotated.
Entries could be curated: e.g., they could be updated if a relevant bug is found.
Increased capacity for version granularity.
Do you know if this already exists for other languages? Would there be interest in / resources for implementing this in Fortran-lang?
Thank you for the links, I was unaware of some of them. They seem to focus on the testing / validating part. It would be great if the entries of the tables could be generated or curated independently, or at least (for compilers with licenses incompatible with that) with reference to an open set of tests.
I don’t know how close they are to having a full consistent testing environment. Work on the way the database works and is presented to users could take place in parallel, and for now it could be filled with vendor-provided information (as it was the case for the ACM Fortran Forum article).
@rouson and I had intentions of getting such a table set up and automated, but got busy with other things before we made it very far. @rouson is currently working on standards conformance tests for flang, so that may be a good place to find test cases. My understanding is that the table Ian Chivers put together was self reported from the compiler teams.
Hi, Jane and I will make the data available to whoever wants to create the on-line database. We typically circulate the vendors once or twice a year, asking for updates. We provide them with a spreadsheet to update. We then collate the information and typeset, and in the past aimed for publication in Fortran Forum. The first version of the current table (covering the 2008 and 2018 standards) is available on our web site https://www.fortranplus.co.uk/app/download/30202489/compiler_support_fortran_2008_and_2018_standards.pdf and appeared in the April 2020 edition of Fortran Forum. We have a revised version available and provided this to the replacement Fortran Forum editor for publication in August 2020. Sadly the replacement editor ended up not taking over. In the light of this thread Jane and I will circulate the vendors asking for updates. It normally takes the vendors 3 or 4 months to provide updates, so we probably won’t have anything to report the summer. Is this ok?
Regarding the database, I think the implementation may be more complex than the existing package index. Is anybody around knowledgeable about what would need to be done?