The Intel Fortran team is proud to announce that with our 2023.0.0 release, IFX now has Fortran language feature parity with our Intel® Fortran Compiler Classic, Ifort! All of Fortran 2018. This has been a 4-5 year effort and is a major milestone for the Intel(R) Fortran Compiler, IFX. Read all about our effort bringing up IFX over the past years and our plans for 2023 and beyond.
Although we started the launch last week, today all the Fortran packages are live, including the Windows packages which were a little late to the party.
Keep up with all the latest from the Intel Fortran team by following me on our Intel Fortran Community Forum, and on Twitter @iCompilersRon
I installed the ifx 2023 yesterday and immediately noticed the faster compilations compared to ifort. I am glad to hear that it was not just an illusion.
Over the years, I have found the Intel Fortran forum (as or among) the most professional forum in HPC, filled with experts and lively, deductive, respectful discussions, not just about Intel products but also Fortran and HPC in general. There is always someone from the compiler developer team or forum experts (many of whom are also members of this Fortran discourse) to respond to questions. I hope the Intel team keeps up this lively mature, respectful spirit in their forums.
Potential IFX bugs: I encountered an ICE while compiling a module that ifort 2023 could readily compile. I have yet to isolate the cause. The new ifx release might need a few patches. Nevertheless, fantastic product.
Kudos to you, Ron, and the entire Intel software team, on outstanding products in IFX and also IFORT and an outstanding blog! Tremendous news for Fortran, great to also see you all begin the journey on Fortran 202X starting with the DO CONCURRENT reduction clause.
@shahmoradi thank you for the complements. We do expect IFX to have bugs not seen in Ifort. Although the parsing is shared, lowering the AST to LLVM-IR is unique to IFX. We expect this code that does the lowering to LLVM-IR to have bugs. While we have thousands of tests, nothing tests a compiler as thoroughly as actual production applications. If your code is on github we’d be happy to clone, build, and reproduce the bug.
@FortranFan we have had a lot of requests for that feature. I also need to push for a simple, single compiler option to invoke the offload HOPEFULLY in the Update 1 release. and we’ll need something like the AOT targeting options we have for OpenMP, since not everyone will want JIT. We are working on a couple of performance issues as well. Tuning is going to be ongoing.
I have been encountering several bugs and have been trying to reduce them to a few lines with some production code, but I at least three are encountered building
for starters. I think the issues I am seeing are common enough that if they are resolved it will help porting to ifx(1). Speaking of speed, whenever ( ifort before it, but ifx as well )compiling anything with a very large amount of WRITE statements or large character blocks I have always found it to take a huge amount of time, and huge amounts of memory compared to other compilers. It improves dramatically when all optimization is off, but is still about 4x slower. Not particularly common in Fortran, but look at the compile time for M_intrinsics.f90 for an extreme case. It can take many hours to extract the issues from complex code so it would be great if you can work with that for starters.
@greenrongreen thanks for sharing here and congratulations to all of the Intel team.
It shows what a large task writing a production compiler is. Even though you already had a working frontend for all of Fortran, it still took 4-5 years.
Great news and congratulations to the team. I gave it a try, but unfortunately still hit some errors trying to run the veggies test suite. I was able to work around a couple, but I don’t know what can be done to work around this one:
catastrophic error: **Internal compiler error: Creating this name exceeds internal buffer: veggies_assert_equals_within_absolute_m_mp_assert_equals_within_absolute_with_messages_ss__templ_0
@greenrongreen , if you’re planning to go on a bug hunt soon, you can reproduce a few with
git clone https://gitlab.com/everythingfunctional/veggies
cd veggies
fpm test --compiler ifx
the first one
./src/veggies/result_m.f90(98): error #6764: A unary defined OPERATOR definition is missing or incorrect. [NOT]
allocate(failed, source = .not.self%results%passed())
---------------------------------------^
can be worked around by changing the line to
failed = .not.self%results%passed()
The next one encountered after that is fixed can be worked around with an intermediate variable. I then hit the first error shown.
@urbanjost I was able to isolate these down a little further last night. This is exactly what I was looking for - code that stresses parts of the compiler that are not as common. Advanced use of character expressions, constructor in this case. Most of the codes and test suites that we have run against to date tickle floating point, vectorization, advanced OpenMP and modern Fortran language features. Some areas where we have work are constructors, character expressions, and submodules. Both with IFX and Ifort.
and of these, about 2/3 are the same general area - same stack traces. These have constructs similar to this, which you use in 2/3rds these ICE’ing modules
Which is good, means we can fix most of the ICEs in most of these files with one compiler fix. I’ll get that written up. _history and _help have a different signatures in the crash. These I’ll isolate down further and get bug reports going on all of these.
That looks great. I hope to see fpm compile next myself, and I believe all the errors it is encountering are reflected in the GPF set. Some others of personal interest (prep, lala) as well as a version of fpm are in stand-alone files at
That all use at least one of the GPF modules (fpm uses M_CLI2) which you already have on your list. Fantastic! A huge amount of stuff is compiling in ifx, which was not the case in previous tries; but a lot of things like issues with BLOCK and metamorphic variables that were slowing down my trials previously are all passing; since I use a testframe based on GPF components (M_msg, M_verify, M_journal, … ) it has slowed me running my unit tests on other numeric modules even though they compile so it would be great if that is all just the same problem.
PS: I had opened two issues on the Intel Fortran forum that are probably related if that is what you are seeing, I think they both had tickets opened already.
@greenrongreen congratulations on reaching this important milestone! I’m very interested in exploring automatic offloading of do concurrent to GPUs in two of my open-source projects. I’ll report a few bugs based on my initial efforts to investigate this feature with Inference-Engine: GitHub - BerkeleyLab/inference-engine. One compile-time bug was easy to work around. One run-time bug related to associate will take some time because I use associate ubiquitously. The current setup.sh script uses gfortran and homebrew to build prerequisites. I’ll edit the script to work with ifx before submitting the bug reports.
Yes, IFX supports the same Quickwin functions as IFORT. The libraries with Intel Fortran are the same for IFX and IFORT. IFX uses the same ABI as IFORT so it can work with any libraries built for IFORT. IFX can create DLL libraries, static libraries, console apps, quickwin apps, windows apps just like IFORT. It should be pretty easy to switch over to IFX without losing any Windows functionality.
Yes, after a bumpy start with the character expression errors, the core computational codes we are testing are compiling and passing tests easily. A few performance variations we are looking into, but so far of smaller magnitudes that we would expect to encounter between different compilers. This code base has all been built with ifort previously so probably not too surprising
but with a significant amount of code being tested (> 4M lines so far) things are looking great.
When the problems you already saw get addressed we will be able to complete the basic unit tests and try some larger tests when the resources are available; but this is looking good (we had enough issues with missing features in earlier Beta releases of ifx that we never got this far before – so this is very pleasing – congratulations to everyone that has been working to get it this far. We wanted to start migrating as soon as possible because for various reasons we expected it would be a long process so we are very pleased at how smoothly things are going with this version).
The simple reproducer for the majority of the crashes with GPFR is this
subroutine kludge_bug(expanded,hold)
character(len=:),allocatable :: expanded(:)
character(len=:),allocatable :: hold
expanded=[character(len=80) :: expanded,hold]
end subroutine kludge_bug
Bug ID is CMPLRLLVM-43084 and I’ve escalated it with our dev team. Thank you for alerting us to this one. Working on the others … we’ll get them as well.
@urbanjost I’ve finished analysis of the errors in GPFr. 2 bugs.
First one is the character array constructor I showed above. that affects
args, kracken, CLI, getopt_long, xterm, CLI2, intrinsics and attr.
2nd bug affects _history and _help. This bug is triggered by a reference to a host-associated variable inside a BLOCK construct. The simple reproducer looks like this (cut down and simplified from _history)
module M_history
contains
subroutine redol_(redoline)
character(len=*) :: redoline ! edited command line to be returned
contains
subroutine do_w()
block
redoline(:2) = ''
endblock
end subroutine do_w
end subroutine redol_
end module M_history