Intel® Fortran Compiler Release Notes

The Intel® Fortran Compiler (ifx) is based on the Intel Fortran frontend and runtime libraries but uses modern LLVM-based backend compiler technology. Because of this, ifx gives you all the Fortran features you know in Intel Fortran, like legacy DEC extensions, superior Fortran Standards support, and powerful compiler directives. Everything you expect in Intel Fortran. But, in addition, ifx adds new capabilities for Intel’s latest CPU and GPU products, including OpenMP TARGET and automatic DO CONCURRENT offload to Intel GPUs for additional accelerated performance.

 ifx fully supports Fortran Standards through Fortran 2018 and now includes select Fortran 2023 features. For more information on ifx, see the Intel® Fortran Compiler Developer Guide and Reference and the Porting Guide for ifort Users to fix.

Change History

This section highlights key changes from the previous product version and changes in minor releases.

 New Features in ifx 2025.0  

• The [no]ieee_mode_restore keyword has been added to the assume option.  This enables saving and restoring the IEEE mode flags at call sights as required by the Fortran standard.  The default is assume noieee_mode_restore, which does not save the mode flags prior to a call and does not restore them after the call.
• The standard-semantics option is now sensitive to a standards conformance level set by the stand option.  If no stand option is specified, standard semantics sets options to conform to Fortran 2018 standard behavior.
• The fopenmp-offload-mandatory and  /Qopenmp-offload-mandatory compiler option tells the compiler to generate only a device version of the compiled code and not a host version.
• Option -inline-forceinline (Linux) and /Qinline-forceinline (Windows), which tells the compiler to treat inline routines as forceinline.
• Option -fvec-allow-scalar-stores (Linux) and /Qvec-allow-scalar-stores (Windows), which ensures vectorization of an explicit simd loop.
• You can specify new pure intrinsic subroutines SPLIT and TOKENIZE.

New OpenMP features in ifx 2025.0

• OpenMP 6.0
  • An IF clause allowed on TEAMS construct
• OpenMP 6.0
  • A DEVICE_TYPE clause may now appear on a TARGET construct.
• OpenMP 5.1
  • The DEVICE_TYPE clause may appear on a DECLARE TARGET directive.
• OpenMP 5.1
  • AFFINITY clause is now permitted on a TASK directive.

See Intel® Compiler Extension Routines to OpenMP* in the Fortran Developer Guide and Reference for more information.

Additional Information

Read this supplemental article for more information about the implementation of Fortran and OpenMP standards in Intel Fortran Compiler (ifx).

Changes

• -check all now behaves as -check all -check nouninit.  Setting -check uninit and linking with libraries not built with this option such as MKL or MPI causes runtime failures, so -check uninit is no longer set by -check all.
• The results of IEEE_MAX_NUM, IEEE_MIN_NUM, IEEE_MAX__NUM_MAG, and IEEE_MIN_NUM_MAG have changed to conform to the Fortran 2023 specification.  If one of the arguments is a NaN, the other argument is returned, while in Fortran 2018 a NaN was returned.  The old behavior is available in the new Fortran 2023 functions IEEE_MAX, IEEE_MIN, IEEE_MAX_MAG, and IEEE_MIN_MAG.  These functions are all defined in the intrinsic module IEEE_ARITHMETIC.
• Previously, a BOZ constant was permitted in an array constructor as an extension, and the BOZ would always be interpreted as an integer value of default kind regardless of the type of the array constructor. To comply with Fortran 2023, in this release, BOZ constants in array constructors with an explicit REAL type-spec are now interpreted as the bits of a REAL value with the same kind as the type-spec. To obtain the old behavior, wrap the BOZ constant in reference to the INT intrinsic function.
• A C string (Intel Fortran extension) containing a NULL character when assigned to an integer variable used to truncate the string at the null character and pad with NULLs.  As of this release, the truncation no longer occurs.  For example: 

integer :: i
character(4) :: c
i = "\0ab"C
c = "\0ab"C
print "(z8.8)", i
print "(z8.8)", c
end

In previous releases this printed:

00000000
00626100

The integer value is all 0s because the first byte of the character string was NULL and the value got truncated. The character value is (little-endian order, so right-to-left!):   0x00 (explicit NUL)  0x61 (a)  0x62 (b)  0x00 (automatic trailing NULL)

The character C following the string literal constant automatically appends a NULL character to the end of the string. 

With this release, the output of the above program is

00626100
00626100

• The Intel® Fortran Developer Guide and Reference received extensive updates to remove older material, refresh existing examples, and add supported Fortran 2018 and 2023 Fortran Language features

Known Issues  

BLOCK DATA

• On Windows systems, a subprogram built into a library that references a common block variable initialized in a BLOCK DATA subprogram that is compiled separately and linked with the library will not get initialized but will have a zero value.  The workaround for this problem is to compile the subprogram and the BLOCK DATA subprogram together, or pass the object file with BLOCK DATA separately on the link line.

COMMON Block

• Beginning with the Intel Fortran Compiler (ifx) version 2023.2.0

  • Programs that declare a COMMON block, instead of individual COMMON block variables, in an OpenMP data sharing clause cause a runtime failure, i.e. segmentation fault or incorrect result. The workaround is to declare the individual COMMON block variables.

Integration with Visual Studio

• For the oneAPI 2025.0 release, the Microsoft Visual Studio validated versions are the same as for oneAPI 2024.1:
  • up to Visual Studio 2022   version 17.9.2
  • up to Visual Studio 2019   version 16.11.34 

              See Intel Compilers Compatibility with Microsoft Visual Studio. Please be aware of this when updating Visual Studio.

• On systems where the Intel Fortran Compiler 2025 (IFX) is installed without a previous version of IFORT, users might encounter an error when building a Fortran project in Visual Studio: "The Fortran compiler (ifort.exe) cannot be found."
  • To resolve this, right-click on the project in Solution Explorer, select "Intel Compiler," and then choose "IFX Intel Fortran Compiler."

map-type/map-type-modifier

program main                        
   type mytype                      
      integer, pointer :: p(:)      
      integer :: y                  
   end type                         
                                    
   type(mytype) :: x                
   x%p => null()                    
   x%y = 111                        
#if BUG                             
   !$omp target map(to: x)          
#else               
   !Workaround                
   !$omp target map(to: x, x%p)     
#endif                              
   print *, associated(x%p) ! not ok
   print *, rank(x%p) ! not ok      
   print *, x%y ! ok                
   !$omp end target                 
end        

map-type/map-type-modifier applied to it is not propagated to the pointer component of the derived type. This means that if "x" is mapped with map(to), the pointer component is not mapped with "map(to)" but only with "map(alloc)". The result is that any query regarding the association status, rank, etc, on the pointer x%p done on its device copy, will return random results.
The workaround is to explicitly map the pointer when mapping the pointer x%p on the same construct, as shown above.
 

Fortran Coarray Application Hang After Executing FAIL IMAGE

If you use a FAIL IMAGE statement to make an image fail, you should use a STAT= specifier or a STAT argument in all coarray operations that might encounter that failed image if the statement or operation permits, or you should specify either the assume failed_images or standard-semantics compiler option. If you do not use a STAT= specifier, a STAT argument, or specify one of the compiler options, those operations will not check for failed images. They may then try to coordinate with the failed image, waiting for a response from it. The response would never happen and so the application would hang.

The following example demonstrates using the STAT= specifier to prevent an application hang.

SUBROUTINE FAIL_AND_SYNC ( THIS_ONE )
   INTEGER THIS_ONE
   INTEGER MY_STAT
   IF (THIS_IMAGE() .EQ. THIS_ONE) THEN
       FAIL IMAGE
   END IF
   SYNC ALL (STAT=MY_STAT)      ! Would hang without STAT=
END SUBROUTINE FAIL_AND_SYNC

opt-reports

There is a known issue with using opt-reports with programs containing OpenMP loop constructs with "schedule(dynamic)", which may cause the compiler to emit an error. In this case, it is recommended that the user remove -qopt-report from their compilation.

Potential for Incorrect Results Using Certain OpenMP Offload Directives

There is potential for incorrect results using OpenMP pragmas to offload to Intel GPUs where a parallel loop nested inside a TEAM construct is using a variable in a REDUCTION clause and the TEAM construct does not have the same REDUCTION clause. To avoid incorrect results, compile with -mllvm -vpo-paropt-atomic-free-reduction-slm=true to disable global memory buffers.

Using -ipo and mixing ifx with ifort object files.

ifx is binary (.o/.obj) and module (.mod) file compatible; binaries and libraries generated with ifort can be linked with binaries and libraries built with ifx, and .mod files generated with one compiler can be used by the other (64-bit targets only). If you compile with -ipo though, the compatibility between ifort and ifx is broken. 

GPU Driver Hanging Issue

If you have applications with long-running GPU compute workloads in native environments, you must disable the hangcheck timeout period to avoid terminating workloads. See the Installation Guide for your OS for more information.

CMake Information

• Starting from CMake 3.25, due to limitations in the way CMake tracks linker flags, a CMake project with mixed C/C++ and Fortran code where one of the compilers is LLVM-based (e.g. icx, ifx) and another is the classic version (e.g. icc, ifort) will result in invalid linking flags. As an example, CMake cannot build a project using "icx" as the C/C++ compiler and "ifort" as the Fortran compiler.
  • The workaround is to use only LLVM-based compilers when building mixed-language applications. 
• Starting from CMake 3.27, CMake support for Intel oneAPI DPC++/C++ Compiler and Intel® Fortran Compiler has been updated to use the compiler driver for linking instead of the linker. This change enables use cases for building SYCL applications and libraries and enables Interprocedural Optimization (IPO) on Windows*. 

Configure Script Reports: "linking to Fortran libraries from C fails"

Symptom

When compiling with ifx, a ./configure script generated by GNU Autconf reports an error message similar to:

    checking for Fortran 77 libraries of ifx...  -loopopt=0 -L/lib/../lib64 -L/lib/../lib64/ -L/usr/lib/../lib64 -L/usr/lib/../lib64/ -L/lib64 -L/lib/ -L/usr/lib64 -L/usr/lib -lifport -lifcoremt -limf -lsvml -lm -lipgo -lirc -lpthread -lirc_s -ldl
    configure: WARNING: FLIBS does not work
    checking for ifx flag to add single underscore to external names... none
    checking for dummy main to link with Fortran 77 libraries... unknown
    configure: error: in '/path/to/build/dir':
    configure: error: linking to Fortran libraries from C fails
    See `config.log' for more details
    make: *** [build/config.status] Error 1

Examining the config.log file shows that the error causing ./configure to exit was:

    ld: cannot find -loopopt=0

Problem 

In trying to determine libraries needed to link Fortran code with C or C++ code, GNU Autoconf 2.69 and earlier mistakenly interprets -loopopt=0 in -mllvm -loopopt=0 in verbose compiler output as a linker flag.  GNU Autoconf then adds -loopopt=0 to the FLIBS variable, which is passed to the linker.  The linker then looks for a non-existent library causing the test to fail.

Solution for Users Downloading Source Code

Please inform the maintainers of packages impacted by this error about the problem and refer them to this release note. Projects vary in how they handle configure scripts; however, some general rules apply. Users who need a solution before the package maintainer can respond can update the configure script themselves. The difficulty of updating depends on how the package is distributed.

To update, first, install GNU Autoconf-2.70 or newer, as described in Solution for Package Maintainers, below.

After installing the updated autoconf in the user's path, packages that distribute the configure.ac  file along with the configure  script can be updated simply by running:

    autoreconf -if

The resulting configure script should complete without the above error in FLIBS.

It is not uncommon for project maintainers to remove the configure.ac file from a source distribution in a tar or zip archive.  In that case, the user usually needs to download the project from its code repository, and build according to the project's instructions.  Sometimes a version of the configure script is committed to version control and not automatically regenerated.  In that case, either running autoreconf -if as described above, or deleting the configure script often trigger it to be regenerated.  Ideally, documentation for the project will describe how to rebuild the configure script.

Solution for Package Maintainers

To prevent users from seeing errors, update to GNU Autoconf to version 2.70 or later and re-generate the project configure  script.  GNU Autoconf-2.70 was released December 8, 2020.  The source code is available via git clone: http://git.sv.gnu.org/r/autoconf.git.  GNU Autoconf documentation is available through GNU Autoconf Project Page.

Support Deprecated 

•  None

Support Removed

•  Intel® Fortran Compiler Classic (ifort) is now discontinued in oneAPI 2025 release.

How To

Download the Intel Fortran Compiler

Please follow the steps to download the Intel^® HPC Toolkit (includes ifx) and follow the installation instructions.  The Intel Fortran compiler can be downloaded from the Standalone Components page.

How To Install the Intel^® Fortran Compiler

The installation guides for the Intel^® oneAPI Toolkits are available online. Please check the Intel® oneAPI Toolkits Installation Guide for more information.

System Requirements

For complete system requirements please see Intel^® Fortran Compiler System Requirements.

How To Use the Intel^® Fortran Compiler

Refer to

• Get Started with the Intel^® oneAPI Toolkits for Linux*
• Get Started with the Intel^® oneAPI Toolkits for Windows*

• Get Started with OpenMP* Offload to GPU for the Intel® oneAPI DPC/C++ Compiler and Intel® Fortran Compiler

for details on how to use the Intel^® Fortran Compiler  

Documentation

Product documentation is available online

• Intel® Fortran Compiler Classic and Intel® Fortran Compiler Developer Guide and Reference
• Read this supplemental article for more information about ifx and its implementation of the Fortran and OpenMP standards.
• Porting Guide for ifort Users to ifx
• OneAPI Versioning Schema based on Semantic Versioning

Directory Layout Change Implemented in 2024.0

The directory layout is improved across all products to streamline installation and setup. The Unified Directory Layout is implemented in 2024.0. If you have multiple toolkit versions installed, the Unified layout ensures that your development environment contains the correct component versions for each installed version of the toolkit. The directory layout used before 2024.0, the Component Directory Layout, is still supported on new and existing installations. For detailed information about the Unified layout, including how to initialize the environment and its advantages, refer to Use the setvars and oneapi-vars Scripts with Linux and Use the setvars and oneapi-vars Scripts with Windows.

Technical Support

If you have Priority Support, create a support ticket. Otherwise, access the Intel^® Fortran Compiler forum when you need assistance. 

Previous Releases

Intel Fortran Compiler Release Notes for Previous Major Releases:

• oneAPI 2024
• oneAPI 2023
• oneAPI 2022
• oneAPI 2021

Notices and Disclaimers

Intel technologies may require enabled hardware, software, or service activation.

Intel optimizations for Intel compilers or other products may not optimize to the same degree for non-Intel products.

No product or component can be absolutely secure.

Your costs and results may vary.

© Intel Corporation. Intel, the Intel logo, and other Intel marks are trademarks of Intel Corporation or its subsidiaries. Other names and brands may be claimed as the property of others.

No license (express or implied, by estoppel or otherwise) to any intellectual property rights is granted by this document.

The products described may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request.

Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.