Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
The Intel sign-in experience has changed to support enhanced security controls. If you sign in, click here for more information.
27653 Discussions

The Next Chapter for the Intel® Fortran Compiler 2023

Ron_Green
Moderator
2,700 Views

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

16 Replies
andrew_4619
Honored Contributor II
2,646 Views

As a user who has yet to look at IFX, this post (and links) answers the many on IFX adoption.  Thanks.

Steve_Lionel
Black Belt Retired Employee
2,641 Views

Very happy to see this - I have been selecting ifx for stuff I have been building, and haven't seen problems.

Ron, please pass on the suggestion to the Visual Studio integration team to add a Tools > Options feature to allow making IFX be the default for new projects, rather than having to individually select it.

Ron_Green
Moderator
2,612 Views

@Steve_Lionel We did discuss when the right time was for the VS IDE switchover to IFX.  2023 seemed too soon.  The majority of the team is thinking the right time is for the 2024 release.   However, I am also wondering if Update 1 or Update 2 might be good candidates.  I'll bring this up again with the architecture team.

Steve_Lionel
Black Belt Retired Employee
2,610 Views

Hi Ron. I'm not suggesting that a switchover be made now, but that an option be added to allow the user to select which compiler to use as the default in new projects. This could go under Tools > Options > Intel Compilers and Libraries > General. This would default to IFORT for now, but a user could change it to IFX if they wanted to.

FortranUser22
Novice
2,295 Views

I have an older license of intel Fortran compiler. Is intel Fortran compiler free now?  (as part of the intel OneAPI HPC Toolkit) . According to Wikipedia, it is free now with optional priority support: Intel Fortran Compiler - Wikipedia 

 

 

Steve_Lionel
Black Belt Retired Employee
2,259 Views

That is correct - free with optional support.

AnaWilliam850
Novice
1,761 Views

Thank you

JohnNichols
Valued Contributor II
1,748 Views

I have just spent 2 weeks updating several computers at the Smithsonian Institution that has a cell modem that after 10 GB runs at 75KB/sec.  It took three days to update VS 2022. The modem is faster at night when the traffic slows down and so you have to get up every hour to remove the error code that one had nine try's and it has stopped.    1.65 GB since 2 am this morning.  

Please bring back the MS 3.03 Fortran that fits on a single 5.25 inch floppy drive.  

 

andrew_4619
Honored Contributor II
1,737 Views

Actually did you mean 3.03 Fortran? I think 3.0 was for CP/M machines only, not IBM PC (8086). 3.31 supported 8086/8087 and came on 5 x 5.25 discs + a manual! 

JohnNichols
Valued Contributor II
1,702 Views

You are correct, for some reason I always think of it as 3.03, faulty memory chip.  I remember when I could afford a 20 MB hard drive and I did not need to swap floppy drives.  Those where the days.  I had hair an added bonus.  

I can buy it for 295 USD.  

van_der_merwe__ben
New Contributor I
1,580 Views

Over the last weeks I have been experimenting with getting our solution to compile using IFX rather than IFORT (under Visual Studio 2022 version 17.4.4 and IFX version 2023.0.0). The project has well over six thousand (yes 6000) .FOR and .F90 files in it. I am happy to say that I managed to get it to compile and link successfully. While I have not done any serious validation testing on the final application, I did run one model and it solved successfully.

The support of existing compiler directives and $DEC statement made the transition much easier.

Issues encountered (most reported via tickets) included:

  • One file had code after a return statement which IFORT ignores but IFX does not, causing genuine unresolved externals.
  • One file called an obscure Windows API function which seems to have disappeared, but it is not needed.
  • Two files had functions wrongly declared as imported rather than exported, leading to unresolved externals. IFORT fixes this but IFX does not.
  • About six files generate internal IFX errors when compiled using the array bounds check option. These files do not need that option.
  • Two files ran into internal compiler errors due to arguments being declared as reference which they are by default anyways.
  • Two files that interoperate with C/C++ using mixed string length arguments and bounds checking gave internal compiler errors, but I was able to rewrite the functions using the nicer ISO C binding options so they work with both IFORT and IFX.
  • The stand alone Fortran installer component is missing some LLVM pieces, can be fixed by installing the C++ stand alone component as well, or installing the base and full api kits.

But given the sheer number of files, the list of issues was relatively small. With any compiler upgrade or change, we usually find some issues to clean up.

So well done Intel IFX team!

We shall likely not formally switch for some time, as it requires a lot more testing and validation and we shall likely wait for the next version of the IFX compiler. But this puts us in a better position for the future.

Barbara_P_Intel
Moderator
1,558 Views

Thank you for your comments! I shared them with the Fortran team; they ask that you continue to report issues to help all developers migrate to ifx.

 

abhimodak
New Contributor I
1,178 Views

Can you point to where one can find more examples related to OpenMP offload? 

One specific question (and perhaps answered somewhere else) is: can it do function offloading? For example,

 

Subroutine Work(J, K)

Integer :: J, K

K = 2*J

End 

 

Program Main

Integer :: J(100), K(100)

Integer :: n

do n =1, 100

     Call Work(J(n), K(n))

end do

End

 

And we want the do loop to run over the GPU. Canthis be done using OpenMP offload? (Potentially, there is cascade of 'calls' from Work.)

Abhi

Barbara_P_Intel
Moderator
1,157 Views

Yes, you can call subroutines from a loop within a TARGET region. Some extra OpenMP directives are required to let the compiler know.

The OpenMP website posts documents with examples. Here's a link. 

That same website lists books that are available. I have this one on my desk, Using OpenMP – The Next Step – by Ruud van der Pas, Eric Stotzer and Christian Terboven (2017).

 

abhimodak
New Contributor I
1,139 Views

Thanks Barbara! 

This is embarrassing but I will ask ... I am looking at OpenMP API 5.2.1 Examples – November 2022; chapter 6. 

I am wondering if it means (for the dummy example above), the following --

 

Program Main

Integer :: J(100), K(100)

Integer :: n

!$omp target

!$omp parallel do

do n =1, 100

     Call Work(J(n), K(n))

end do

!$omp

!$omp end target

End

 

I would imagine that there could/would be additional mapping clauses etc as needed along with certain restrictions as documented in chapter 6 of the book.

 

Abhijit

Barbara_P_Intel
Moderator
1,052 Views

I like to use mapping clauses to at least make the code self-documenting, same with shared and private clauses. There are defaults, but it's easier for me to understand the code and not try to remember the defaults.

To offload the subroutine, I believe you need a DECLARE TARGET directive.

More references for you.

Webinar: Three Quick, Practical Examples of OpenMP Offload to GPUs There are links to other webinars there, too, that you may find useful.

For when you're ready to optimize, check this out: oneAPI GPU Optimization Guide

Reply