Intel® Fortran Compiler Release Notes

ID 846561
Updated 3/21/2025
Version
Public

Devorah Hayman Ron Green

This document applies to the Intel® Fortran Compiler and summarizes new and changed product features. It also includes notes about features and problems not described in the product documentation.

Devorah Hayman Ron Green

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.1 

       New Fortran 2023 features

  • Changes to the SYSTEM_CLOCK intrinsic have been implemented. All integer arguments must have the same kind type, and be of at least default integer kind. Violation of these restrictions is diagnosed as standard messages when option -stand f2023 (Windows: /stand:f23)or option standard-semantics appears on the command line.
  • PUBLIC NAMELIST groups may now contain PRIVATE variables.

New OpenMP features in ifx 2025.1

  • OpenMP 6.0
    • The WORKDISTRIBUTE construct divides the associated block of statements into units of work that are each executed once by a thread of the enclosing TEAMS construct. A procedure reference in the associated block, with the exception of a reference to MATMUL with fixed-size array arguments, will inhibit the work-sharing properties of this construct at this time.
    • INTERCHANGE construct reorders loops in a loop nest.

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).

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. For more information, see the Installation Guide for your OS.

OpenMP offloading to Intel® Xe-LPG Integrated Graphics GPUs

Fortran applications that perform OpenMP offloading to Intel® Xe-LPG Integrated Graphics GPUs may encounter runtime failures or unexpected results. This error has been seen on The latest Intel® Core™ Ultra processors (Series 1 and Series 2), codenames Meteor Lake and Lunar Lake. Affected applications use OpenMP DISTRIBUTE PARALLEL DO constructs with collapse clause added inside an OpenMP target region. The issue has been isolated to the current GPU drivers for Intel® Core™ Ultra processors (Series 1 and Series 2), codenames Meteor Lake and Lunar Lake. A driver update to address this issue will be released at a future date.

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 instead of the linker for linking. 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 be completed 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 triggers 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

for details on how to use the Intel® Fortran Compiler  

Documentation

Product documentation is available online

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:

 

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.

 

Product and Performance Information

1

Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex.