Interestingly, the entire Coarray paradigm is implemented for shared memory architecture.
What does it mean that “is the only fully supported Fortran compiler for Apple ARM-based M1 systems”?
I use both GFortran and LFortran on Apple M1 all the time. In fact I develop LFortran on M1 as my primary platform.
I have no idea about the answer. But to extend your question, I have an Intel X86 Mac in office with which I build applications for Mac. Do such applications also run on an M1 Mac natively? or do they need special compatibility software? I know (have heard) for example, Intel compilers cannot be installed on M1.
It may be the case of poor copy editing. In the context of the article, maybe they meant “it is the only Fortran compiler with full F2008 and F2018 coarray support for Apple ARM-based M1 systems”.
The x86 binaries run on M1 by being first translated automatically to ARM by the macOS system. So they run natively in the end. They don’t sometimes use all the instructions available (such as fma), but they run.
I think such language is used to assure the Chief Technology Officer that there is a company to yell at if there is a problem. The gfortran and lfortran compilers are volunteer efforts.
I removed the last 5 posts. Thanks @kargl for bringing this up.
I started in this direction by asking about some details of the post, so you can blame me for starting it. Sorry about that.
Let’s try to take the high road from now on.
To clarify our goals: the goal of this forum and fortran-lang in general is to collaborate on Fortran and collaborate on as many things as we can, and to bring all commercial and open source entities to the same table. Similar to the Fortran Standards Committee, which is trying to bring all the competing interests to the same table to collaborate on a standard. We are trying to extend this to all things Fortran, from tools, compilers, etc.
It’s a fine line how we should define how we should communicate, and also it’s similarly not perfect how to enforce it by the moderators here… If anyone wants to join moderation, let us know, we could always use more help. Speaking for myself, I am trying to do my best, but it’s not perfect, and I am sorry of things are not consistent sometimes.
It’s true that all the competing interests of companies and people who participate here might not always align what what you or I would personally want. And the best thing we can do is to collaborate on as many things as we can and where it makes sense, and compete on the rest. And we should always strive to be respectful to each other.
There are (at least) three meanings commonly ascribed to the word “support”:
supporting a platform: The ability to perform operations on that platform that one can usually perform on other platforms. There can be some degree of adaptation of operations and that usually falls under “Quality of Implementation”. Native code generation is high on the list of items to consider.
supporting a product: The ability to report problems and receive timely fixes or advice. For many but not all users, service-level agreements and dedicated support teams are required to provide sufficient confidence.
supporting a specification: The ability to conform to a published standard, in this case the relevant ISO/IEC Standards for Fortran.
I hope this provides clarity on NAG’s position and approach which has guided our operations since 1970.
Thanks @themos for the clarification. So “support” indeed meant all three meanings. Nice.
(for 7.0, not 7.1, as pointed out later in the thread)
This release contains several major new features:
- parallel execution of coarray programs on shared-memory machines;
- half precision floating-point conforming to the IEEE arithmetic standard, including full support for all exceptions and rounding modes;
- submodules, a Fortran 2008 feature for breaking large modules into separately-compilable files;
- teams, a Fortran 2018 coarray feature for structuring parallel execution;
- events, a Fortran 2018 coarray feature for lightweight single-sided synchronisation;
- atomic operations, a Fortran 2018 coarray feature for updating atomic variables without synchronisation.
This release also contains numerous minor enhancements, including:
- other (minor) features from the Fortran 2008 and Fortran 2018 standards;
- miscellaneous improvements to error detection, and improvements to error messages;
- acceptance of additional non-standard Fortran extensions;
- optional auto-skipping NAMELIST input.
It will be really cool if NAG Fortran can arrive at full support of Fortran 2018 soon, say by this time next year, or at least prior to the publication of Fortran 202X standard revision!
Having all the modern Fortran compilers (say those who have continued compiler development post Fortran 95) on par with a current standard revision at any point in time will help Fortran greatly.
I am afraid you were reading the current (7.0) release’s notes, not the “imminent” 7.1 Release Notes. This was one of the very rare times that we announce something that is not available quite yet.
The Release Notes for 7.1 are now live (as is the rest of Release 7.1).
Awesome. Can’t wait to try it out.
Any vs many, any difference?!
Admittedly I’ve only glanced at the first few lines in the link but …
- first it states, “Full coverage of Fortran 2008.”
- Then a few bullet points down, there is, “Use of data pointer function result as variable in many contexts is supported.” This struck me as different from the 2008 standard because I recalled the latter to state “any variable definition context”:
So when it comes to pointer function reference, are there contexts where NAG 7.1 will not yet support what the standard envisioned?
There are 15 variable definition contexts enumerated in the Standard, the Release Note is explicit about 7 (1,3,5,9,10,11,15). Some others may not make sense and some will be implemented as Release 7.1 evolves.