The Next Chapter for the Intel® Fortran Compiler 2023

[Ron_Green]

The Intel Fortran Compiler development team is thrilled to share news of our achievement in reaching a major milestone for the Intel® Fortran Compiler, IFX:  With the 2023.0.0 release, IFX now has Fortran language feature parity with our Intel® Fortran Compiler Classic, IFORT.  And this is no small feat. For the first time, IFX has full Fortran 2018 language support, putting it on par with IFORT.  This includes all the legacy DEC/Compaq/Intel language features, extensions, and all our compiler directives that you have come to expect in Intel Fortran!  But there’s more to the IFX story to celebrate! In a parallel effort, our Fortran compiler added OpenMP GPU offload features to enable your applications to access acceleration on Intel GPUs, such as the Intel® Data Center GPU Max Series. 

I have posted this blog article that details the evolution of IFX, features in IFX 2023, and where we are going with IFX and IFORT in 2023 and years beyond. 

I will open this thread for comments.  We know IFX is not quite ready to replace Ifort, at least for some users, with the 2023.0.0 version.  While the major development work is complete, we still need to stabilize the code.  But it should be quite close and should have reasonably good performance relative to ifort.  Make sure to use -xhost, -x<arch>, or -Ofast -flto, as one or the other of these options are needed to get Intel optimizations over and above baseline LLVM optimizations.   We have our Ifort to IFX Porting Guide to help with the differences between IFX and Ifort.  

We look forward to feedback on your experience with IFX 2023.0

ron

Keep up with all the latest from the Intel Fortran team by following me on Twitter @iCompilersRon
Ron Green #IAmIntel

[Simon_C]

That is good news. I notice that Ron says "We know IFX is not quite ready to replace Ifort, at least for some users, with the 2023.0.0 version." I am a little less concerned about features in ifx than I am about possible bugs - things ifort gets right that ifx doesn't yet. Over the last few years I've had several problems with ifort because of bugs in the operation of derived types and especially parameterised derived types. Current programs I'm developing pretty much require the latest, or near latest, version of ifort to function properly. (The same is true of the compiler developed by NAG, which I also use.)

I'd be grateful if someone from Intel would comment on ifx vs. ifort with respect to problems in the implementation of this language feature, and any others where the two compilers differ in their correctness.

Thanks,

Simon_C

[Ron_Green]

@Simon_C I will comment on ifx vs ifort on language features.  

I mentioned in the article that ifort and ifx share the same code for interpreting your program against the Fortran Standard.  It's a multi-step process.  The shared code breaks down your program into a binary representation.  Think of it as gathering characters into words, words into sentences, and sentences into paragraphs .  Then converting that to a second language.  It is a step-wise translation from your ASCII program to machine instructions. 

Ifort and ifx convert your program into this representation the same way.  Same code (except for OpenMP, where IFX has to interpret OMP 5.x offload statements and clauses).   This representation is called an Abstract Syntax Tree (AST).   Up to this point ifort and ifx are identical.  Now, the AST has to be translated or "lowered" to an intermediate representation (IR) to continue with the process of going from your source to machine code.  For ifort, the AST was lowered (translated) into our own proprietary representation called IL0.  For ifx, the IR is LLVM-IR.  Totally different representations.  Much like 2 different languages.  The lowering of the AST to IL0 IR has been around since Intel acquired the CVF/DVF compiler.  If you remember, the early Intel Fortran compilers during this transition were buggy.  It's not easy to do this lowering.  Takes a while to get all the possible permutations of the AST covered correctly.  

This is where you see errors in ifx that you don't see in ifort.  Totally different translations.  So the LANGUAGE interpretation is the same, but translation to IR is different.  Also, once in LLVM-IR binary form, the LLVM compiler framework invokes optimizations/vectorizations and code generation.  This is also different from ifort.   We run the same test suites, regression tests, etc. on both compilers.  But you cannot possibly cover every permutation of features in testing.  This is true for software engineering on any complex application.  You try to anticipate what users will input to the program (compiler) but you cannot possible cover every possible combination of language features that a user may come up with.  We have 10s of thousands of tests.  And each compiler bug fixed has to have a regression test added to our regression suite (run nightly).  Every bug fix in ifort and ifx for, what, 20 years or more is in the regression suite.  So it's not for lack of effort but rather simple combinatorics of the many F2018 features and how they can combine.  Over time compilers "harden" or fix all the issues that are found.  The longer a compiler is around, the more "hardened" it becomes - NAG for example.  

Long winded answer.  In the lifecycle of ifx, version 2023.x is where we hope to find and fix those errors in IR lowering to LLVM-IR that user codes find that our extensive testing could not anticipate.  All the F2018 features and mixing of features in combinations or very OO and complicated expressions that no one could have foreseen.  It takes time to evolve something as complex as a compiler to a "stable" state.  For example, is Clang or g++ or gfortran bug free? Or NAG bug free? No, rather it's an evolution.  Of course when the bug affects your code it's human to think the compiler is not "as good as compiler XYZ".  This is why it's important for users to report bugs to the developers and understand that with a new compiler like ifx or Flang there will be some time needed to "harden" the implementation.  This is why we are keeping ifort available to users as we make this transition.

[Simon_C]

Ron,

That is a very interesting insight into what is under the hood and a much fuller answer than I expected. For someone who thinks of everything that happens between issuing an ifort myprog.for command and the creation of a functioning myprog.exe as being the work of "the compiler" an understanding of what goes on in the background is very helpful. For example, until the other week I had not encountered the term LLVM and did not know what a colleague was talking about when it came up in a discussion for what compiler to use for Arm-based Apple machines. I expect that is a whole other topic (does Intel intend to support them?)

I'll summarise my understanding of what you have said:

ifort:

Fortran code -> AST -> IL0 -> machine code

ifx:

Fortran code -> AST -> LLVM-IR -> machine code

Leaving aside OpenMP, ifort and ifx produce the same results for the first step, but not yet for the second (AST to intermediate representation). At this second step ifort suffers fewer bugs because the technology has been around a great deal longer. (Yes, my first serious programs for public use were compiled using the DEC Fortran which you mention.)

The same test suites are used for both ifort and ifx but, large as they are, they can't cover all combinations of features so bugs still crop up. Intel hopes to close the gap between ifort and ifx during 2023.

Thanks,

Simon_C

[JohnNichols]

http://www.bitsavers.org/www.computer.museum.uq.edu.au/RT-11/DEC-11-LFLRA-B-D%20PDP-11%20FORTRAN%20Language%20Reference%20Manual.pdf 

interesting find. 

[jimdempseyatthecove]

Hay Steve, did you notice from your prior life?

(all caps)

Jim Dempsey

[Steve_Lionel]

---

@jimdempseyatthecove wrote:

Hay Steve, did you notice from your prior life?

(all caps)

Jim Dempsey

---

I never worked on PDP-11 FORTRAN., having started with "VAX-11/VMS FORTRAN". At the time of that product, all caps was the correct spelling. 

[Michael_S_17]

I can give positive feedback for my (experimental) coarray programming with the ifx compiler (ifx version 2023.0.0 yet). The shift from ifort to ifx was seamless.

This comprises very fancy customizations through coarrays and collective subroutines already, both for kernel programming on CPUs yet, such as customization through coarrays for single-image asynchronous code execution (i.e. multiple asynchronous coroutines simultaneously on each coarray image), as well as using traditional Fortran OOP for implementing distributed objects. My codes run the same with gfortran/OpenCoarrays, ifort, and ifx.

I am using only a fraction of the available Fortran language features but am still positively surprised how well ifx does already work for Coarray Fortran. It is my believe that Fortran’s simplicity is of great advantage here, for both implementers as well as users (Fortran programmers).

In my experience, some major performance issues with the coarray runtime (the same using gfortran/OpenCoarrays, ifort, and ifx) appears to be due to MPI: I am using two different methods of compilation for (same version of) MPICH simultaneously on the same system, which leads to very different runtime performance of the same coarray program (but with same output). It is only my best guess yet, but the one (older) method for MPICH compilation could be better for oversubscribing cores, while the other (newer) method could be better for not oversubscribing cores: https://groups.google.com/g/comp.lang.fortran/c/vITMz5e1nHQ

[PatRuane]

Ron,

We've been using Compaq Visual Fortran Prof 6.6.A to support our custom legacy application, and now we're looking to set up a backup server with the same development environment. My concern, though, is about licensing.

Since Intel acquired Compaq, I'm assuming we can work things out through your organization. Could you give me some recommendations on which software I should purchase to ensure we're in compliance? If you're not the right person to ask, could you please direct me to someone who can assist me with this?

Thanks in advance for your help.

Best regards,

Pat Ruane, TelePro

[Steve_Lionel]

Intel did not acquire Compaq and has no legal rights to Compaq Visual Fortran, which remains the property of HP Enterprise.

[Ron_Green]

Post the question on our licensing forum

[van_der_merwe__ben]

I just recompiled out many Fortran files using IFX using the latest 2024 compiler released. I ran around 200 validation tests and apart from numerical noise in about a dozen cases where noise is not uncommon, there was just one issue I had to track down (a common variable in a data block not getting initialized, could not reproduce it in a smaller case so I did not log it). But that is pretty good!!

So the IFX compiler gets a thumbs up for me!  It works.

Please convey this positive feedback to the team who must hav worked really really hard to make this happen.