Intel® Fortran Compiler and Intel® Fortran Compiler Classic Release Notes, oneAPI 2024 Release

The Intel® HPC Toolkit package provides two Fortran compilers:

• The Intel® Fortran Compiler (ifx) has all of the Fortran language features of ifort, plus the added functionality of OpenMP* directives to offload to Intel GPUs. The OpenMP 5.0, 5.1, 5.2 and 6.0 target features for Intel GPU in ifx are not available in ifort. 
• The Intel® Fortran Compiler Classic (ifort) uses our legacy Intel compiler technology and is provided to support users making the transition to the Intel® Fortran Compiler (ifx). This compiler is provided along with ifx during this transition period. Also, Intel Fortran Compiler Classic provides the ability to create binaries for Windows 32bit libraries and applications (ifx creates 64bit binaries only).

The Intel Fortran Compiler (ifx) is our flagship Fortran compiler. The Intel Fortran Compiler (ifx) is based on the Intel Fortran Compiler Classic (ifort) frontend and runtime libraries but uses modern LLVM-based backend compiler technology. Thus, ifx gives you all the Fortran features you know and love in ifort, 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.

Both compilers, ifort and ifx, fully support Fortran Standards through Fortran 2018 and now include select Fortran 2023 features. 

ifx and ifort are binary (.o/.obj) and module file (.mod) 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 and not compiled with -ipo). Both compilers use the same runtime libraries. Our users tell us that the performance of applications compiled with ifx is comparable to the same application compiled with ifort.

NOTE  Intel® Fortran Compiler Classic (ifort) is now deprecated and will be discontinued in late 2024. Intel recommends that customers transition now to using the LLVM-based Intel® Fortran Compiler (ifx) for continued Windows* and Linux* support, new language support, new language features, and optimizations. For more information on ifx, see the Intel® Fortran Compiler Developer Guide and Reference and the Porting Guide for ifort Users to ifx.

NOTE macOS support is removed for Intel® Fortran Compiler Classic (ifort) in the 2024.0 release. 

Where to Find the Release

Please follow the steps to download the Intel^® HPC Toolkit and follow the installation instructions. For full functionality, it is recommended that you install the Intel® oneAPI Base Toolkit first. The Fortran compilers can be downloaded from the Standalone Components page.

Change History

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

New in Intel^® Fortran Compiler 2024.2.0 Release

• The Intel® Fortran Compiler adds the -fstrict-overflow and Qstrict-overflow[-] options to instruct the Fortran compiler to optimize under the assumption that integer operations won't overflow. For applications that rely on integer overflow behavior, the -fnostrict-overflow option ensures correct functionality.
• Stay at the forefront of parallel programming with our ongoing conformance enhancements for the latest OpenMP standards, including 5.x and the forthcoming 6.0. With this compiler release you can now specify OpenMP 5.1 THREAD_LIMIT on TEAMS and TARGET constructs to better manage thread usage, and OpenMP 5.2 enhancements like COPYPRIVATE and NOWAIT on construct beginnings, as well as an updated LINEAR clause syntax for more precise control. With OpenMP TR12, the LOOP directive is now applicable to DO CONCURRENT loops, paving the way for more powerful loop optimizations.
• The added OpenMP runtime library extensions* provide a robust set of memory management extensions, including functions for precise host pointer registration, targeted memory allocations, and device-specific optimizations. With these powerful extensions, you can push the boundaries of performance and efficiency in your high-performance computing applications.

* added extensions: ompx_target_register_host_pointer, ompx_target_unregister_host_pointer, ompx_target_aligned_alloc, ompx-target_aligned_alloc_device, ompx_target_alloc_host, ompx_target_aligned_alloc_shared, ompx_target_aligned_alloc_shared_with_hint, ompx_target_realloc, ompx_target_realloc_device, ompx_target_realloc_host, ompx_target_realloc_shared, ompx_get_device_from_ptr, and ompx_get_num_subdevices.

Intel^® Fortran Compiler Classic 2021.13.0

• The Intel® Fortran Compiler Classic has been updated to include recent versions of 3rd party components, which include functional and security updates.

System Requirements

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

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 advantages with the Unified layout, refer to Use the setvars and oneapi-vars Scripts with Linux and Use the setvars and oneapi-vars Scripts with Windows.

Details of New and Changed Compiler Features

New Features in ifx 2024.2.0 and ifort 2021.13.0

• -f[no]strict-overflow (Linux) or /Qstrict-overflow[-] (Windows)

  • strict-overflow tells the compiler to assume integer operation can never overflow, allowing better optimization. Programs that depend on integer overflow should use nostrict-overflow, which may impact performance.
• -ffp-accuracy(Linux) and /Qfp-accuracy(Windows), which let you specify the required accuracy (precision) for floating-point operations and library calls.  
• -ftarget-register-alloc-mode(Linux) and /Qtarget-register-alloc-mode(Windows), which let you specify a register allocation mode for specific hardware for use by supported target backends.  
• -fopenmp-concurrent-host-device-compile(Linux) and /Qopenmp-concurrent-host-device-compile(Windows), which let you specify the format of device code stored in a resulting object. This is an experimental feature.  
• -fopenmp-do-concurrent-maptype-modifier(Linux) and /Qopenmp-do-concurrent-maptype-modifier(Windows), which let you specify the data movement for variables referenced inside the DO CONCURRENT region when it is auto-offloaded. 
• [q or Q]mkl-sycl-impl, which lets you link to one or more specific Intel® oneAPI Math Kernel (oneMKL) SYCL libraries.  
• -fmaintain-32-byte-stack-align(Linux) and /Qmaintain-32-byte-stack-align(Windows), which tell the compiler to realign the stack to 32-byte if stack alignment is uncertain for functions with external linkage, and retain 32-byte alignment for other functions.  
•  -fstrict-overflow (Linux) and /Qstrict-overflow (Windows), which determine whether strict overflow is enabled for signed addition, subtraction, and multiplication wrap arounds using twos-complement representation. 
• -fopenmp-target-default-sub-group-size(Linux) and /Qopenmp-target-default-sub-group-size(Windows), which let you specify a default sub-group size globally for single program multiple data (SPMD) kernels that are generated for OpenMP* target constructs when offloading to SPIR64-based devices.  

New OpenMP features in ifx 2024.2.0

• OpenMP 5.1
  • The THREAD_LIMIT clause is now accepted on the TEAMS and TARGET constructs.
• OpenMP 5.2.
  • You can now specify the MAP map-type-modifier PRESENT in the DECLARE MAPPER directive. 
  • COPYPRIVATE and NOWAIT can now be specified on directives that begin a construct, not just on the END directive of the construct.
  • Suppport of the LINEAR clause with linear-step and linear-modifier.

• Ifx now supports the OpenMP runtime library extensions ompx_target_register_host_pointer, omp_target_unregister_host_pointer, ompx_target_aligned_alloc, ompx-target_aligned_alloc_device, ompx_target_alloc_host, ompx_target_aligned_alloc_shared, ompx_target_aligned_alloc_shared_with_hint, ompx_target_realloc, ompx_target_realloc_device, ompx_target_realloc_host, ompx_target_realloc_shared, ompx_get_device_from_ptr, and ompx_get_num_subdevices. 
  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).

Support Deprecated 

Intel® Fortran Compiler Classic (ifort) is now deprecated and will be discontinued in late 2024. Intel recommends that customers transition now to using the LLVM-based Intel® Fortran Compiler (ifx) for continued Windows* and Linux* support, new language support, new language features, and optimizations. For more information on ifx, see the Intel® Fortran Compiler Developer Guide and Reference and the Porting Guide for ifort Users to ifx.

Intel Fortran Compiler (ifx)

• -assume[no]std_intent_in is not implemented and is deprecated. (assume[no]std_intent_in does nothing for ifx and will be deprecated and removed.)

• -fsycl-link-huge-device-code is deprecated and may be removed in a future release.  Use -flink-huge-device-code instead.

• -fopenmp is deprecated and may be removed in a future release.  Use -qopenmp or -fiopenmp instead.
• The compiler option on Linux -mkl is deprecated and may be removed in a future release. Beginning in the 2021.4.0 release the replacement is -qmkl. This compiler option tells the compiler to link to necessary libraries in the Intel® oneAPI Math Kernel Library.

Intel Fortran Compiler Classic (ifort)

• Directive SIMD (!dir$ SIMD) is deprecated and may be removed in a future release. In the source code users should replace the directive with the OpenMP SIMD directive !$omp simd and associated clauses. When using the OpenMP SIMD directive remember to add compiler option -qopenmp-simd or -qopenmp. When compiling with -O2, -qopenmp-simd is implied.
• The compiler option on Linux -mkl is deprecated and may be removed in a future release. Beginning in the 2021.4.0 release the replacement is -qmkl. This compiler option tells the compiler to link to necessary libraries in the Intel® oneAPI Math Kernel Library.

Support Removed

Note that starting with release 2021.7, macOS* support is limited to Mac* computers with Intel® Processors.

macOS* support

macOS support is removed for Intel® Fortran Compiler Classic (ifort) in the 2024.0 release. 

Intel® C++ Compiler Classic (icc/icpc)

Intel® C++ Compiler Classic (icc/icpc) is removed in the 2024.0 release. Intel recommends that customers transition now to using the LLVM-based Intel® oneAPI DPC++/C++ Compiler (icx/icpx) for continued Windows* and Linux* support, new language support, new language features, and optimizations. For more information on icx/icpx, see the Intel® oneAPI DPC++/C++ Compiler Developer Guide and Reference and the Porting Guide for icc Users to dpcpp or icx.

Known Issues

Installation on Windows

• There is a known issue integrating Intel software developer tools 2024.0 (Intel® oneAPI Base Toolkit, Intel® HPC Toolkit, or their component products) into Microsoft Visual Studio 2022 (17.7 or higher) on offline systems with the Windows Performance Toolkit (Win11SDK_WindowsPerformanceToolkit) installed. This results in an incomplete integration. To work around the issue, either enable an Internet connection during Intel developer tools installation or uninstall the Windows Performance Toolkit before installing Intel developer tools, after Intel developer tools are installed, reinstall the Windows Performance Toolkit.
• For the oneAPI 2024.2 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* and Xcode*
Please be aware of this when updating Visual Studio.

Non-POSIX Shells

The environment start up scripts have been migrated to POSIX compliant scripts. For non-POSIX shells, such as csh, there is a workaround for command-line usage for the Component Directory Layout:

% bash -c 'source /opt/intel/oneapi/setvars.sh ; exec csh'

For the Unified Directory Layout use

% bash -c 'source <install-dir>/<toolkit-version>/oneapi-vars.sh ; exec csh'

ifx and ifort

These are applicable when using both the ifx and ifort compiler drivers.

Evaluating Compile Time Integer Expressions

• Beginning with the Intel Fortran Compiler (ifx) version 2023.2.0 and the Intel Fortran Complier Classic (ifort) version 2021.10.0
  • When evaluating compile time integer expressions, in some cases where overflow occurred, ifort and ifx did not issue any warning. This has been fixed.
  • When evaluating compile time integer expressions, in some cases where overflow should occur, ifort and ifx would instead silently promote the values to INTEGER(8), yielding a correct numeric result ,but with a larger KIND type  parameter. This automatic promotion to a larger KIND has been partially removed; most expressions will now overflow. This can result in numeric differences, but an overflow warning will be issued. For backwards compatibility, automatic promotion to INTEGER(8) will still occur in the limited case where all values of the expression are integer literals with no explicit KIND parameters. A warning will be issued in that case, too.

COMMON Block

• Beginning with the Intel Fortran Compiler (ifx) version 2023.2.0 and the Intel Fortran Complier Classic (ifort) version 2021.10.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.

Module (.mod) Files

Beginning with the Intel Fortran Compiler (ifx) version 2023.1.0 and the Intel Fortran Complier Classic (ifort) version 2021.9.0 module (.mod) files are compatible only with those module files created with 

• Intel® Fortran Compiler [ Composer | Professional ] Edition for Linux*, version 11.0,
• Intel® Visual Fortran Compiler [ Composer | Professional ] Edition for Windows*, version 11.0, or
• Intel® Fortran Compiler [ Composer | Professional ] Edition for Mac OS* X, version 11.0 and
• newer.

The module files created by Intel Fortran compilers prior to version 11.0 are no longer compatible.

GDB* 10.0 and Earlier 

A change between oneAPI 2023.0 and oneAPI 2023.1 prevents GDB* 10.0 and earlier versions from properly debugging SYCL and OpenMP* CPU offload code produced by the Intel® C, C++, and Fortran compilers. These older versions of GDB are present on RedHat EL8, Ubuntu 20.04, and Rocky 8.

Workarounds

1. Use the Intel® Distribution of GDB*.
2. Download an open source version of GDB after version 10.0
    

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

Using the Coarray Feature with Red Hat 8

Applications that use the coarray feature and are running on Red Hat 8.0 or later should have Intel MPI 2019 Update 7 or later installed.  With earlier versions of MPI, applications may not complete successfully and give little information about the failure.

ifort

These are applicable when using the ifort compiler driver.

Cross Compiling (compiling in 32-bit mode on a 64-bit machine running Microsoft Windows*)

If you are running

• Microsoft Windows* and
• cross compiling (compiling in 32-bit mode on a 64-bit machine) and
• using Microsoft Visual Studio* 2019 and
• handle exceptions, particularly floating point exceptions, in your code and
• you see a SEGV exception when your program gets a floating point exception,

your program did not handle the exception as intended.

The solution is to add legacy_x86_flt_exceptions.lib to your link command.

ifx

These are applicable when using the ifx compiler driver.

-ax

When using the ifx compiler, if you experience any program failure when using option -ax using the 2024.1 version, please remove the option to see if that solves the problem. If that action solved the problem, please report a bug by opening a ticket at https://supporttickets.intel.com/?lang=en-US. Or post your question on the Intel Fortran Community Forum. Add a small reproducer to the report.

-check uninit

With the LInux version of ifx 2024.0.x there is a known bug with the new LLVM Memory Sanitizer feature. This does not affect Windows users; this is a Linux only feature.  This compiler option reports invalid information. A fix is coming in the 2024.1.0 Release. -check uninit is embedded in -check all.

Workaround 1

Compile with -check nouninit.

Workaround 2

If compiling with -check all, replace it with -check all,nouninit.

Workaround 3

Unset the environment variable LIBRARY_PATH or remove this directory in LIBRARY_PATH <oneAPI root dir>/2024.0.0/compiler/2024.0/lib.

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

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.

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 for oneAPI.

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

Technical Support

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

Intel Fortran Compiler Release Notes for Previous Major Releases

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