Porting Guide for Intel® Fortran Compiler

This porting guide is a work in progress.  Check back frequently during the next months for updates. 

Guiding Principles for the Intel Fortran Compiler

The Intel® oneAPI product packages provide two Fortran compilers. Intel Fortran Compiler Classic (ifort) provides best-in-class Fortran language features and performance for CPU. The Intel Fortran Compiler (ifx) enables developers needing OpenMP* offload to Intel GPUs. The OpenMP* 5.0, 5.1 GPU offload features in ifx are not available in ifort. For now ifort continues to be our best-in-class Fortran compiler for customers not needing GPU offload support. The default compiler for the Microsoft Visual Studio* environment is ifort.

Our latest compiler, the Intel Fortran Compiler (ifx), is production-ready for CPUs and GPUs. ifx is based on the Intel Fortran Compiler Classic (ifort) frontend and runtime libraries, but uses LLVM backend compiler technology.  The release in oneAPI 2023.0 completely implements FORTRAN 77, Fortran 90/95, Fortran 2003, Fortran 2008 and Fortran 2018 language standards and most OpenMP 4.5 and OpenMP 5.0/5.1 directives and offloading features. ifx is 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). Both compilers use the the same runtime libraries.  ifx may or may not match the performance of ifort compiled applications. Performance improvements will be coming in ifx with each update release throughout 2023.

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 this Porting Guide for ifort Users to ifx.

See this table for Intel® Toolkit Version to Compiler Version Mapping

Major Changes in Compiler Option Defaults

• Intel Fortran Compiler Classic users can continue to use the ifort driver.
• Intel Fortran Compiler users use the ifx driver for the features in Intel Fortran Compiler Classic and to use the additional feature of compiling to use Intel GPUs via OpenMP TARGET directives.

Creating IA-32 Binaries

The Intel Fortran Compiler (ifx) can only create 64 bit binaries for Windows or Linux. ifx does not support IA-32. Neither -m32 nor /Qm32 are supported.

Compiler Options for Intel Fortran Compiler First Use

Consider these safe options. Use these to validate correctness with your application before moving to optimized code tests.

Floating Point Behavior

• To get ifort behavior in floating point comparisons, ifx users should specify assume [no]ieee_compares and/or assume nan_compares.
  • Tells the compiler to generate IEEE compareSignaling operations for floating point comparisons, as required by the Fortran 2018 standard. By default ifx assume NaNs are not going to be operands in floating point comparisons and does not generate that check for NaNs.  
    • Linux
      • -assume [no]ieee_compares
    • Windows
      • /assume:[no]ieee_compares
• fp-model | fp and fast
  • The behavior with the fp-model | fp fast=1 or 2 option is different between ifort and ifx with respect to floating point compares.  To get ifort behavior when using the fp-model or fp fast option with ifx, assume nan_compares should also be specified on the ifx command line.
    • Linux
      • -fp-model fast=1 or -fp-model fast=2 -assume nan_compares
    • Windows
      • /fp:fast 1 or /fp:fast 2 /assume:nan_compares

CPU Performance

* may not be final

ifx Compiler Options and OpenMP Directives

• OpenMP 4.5/5.0/5.1 TARGET directives are only recognized by the ifx ompiler that is included in the Intel oneAPI HPC Toolkit.  ifx also recognizes OpenMP PARALLEL and SIMD directives.
• -fiopenmp and -qopenmp are equivalent.
  • ​Compile and recognize OpenMP parallel and SIMD directives and clauses and use the Intel OpenMP runtime libraries.
• -fopenmp is deprecated and will be removed in a future release.
• -fopenmp-targets=spir64
  • This option is needed when OpenMP 4.5/5.0/5.1 TARGET pragmas/directives are used to run on Intel GPUs.
  • spir64 stands for "64-bit Standard, Portable Intermediate Representation"
• Use the compiler options above together to create a fat binary for both the cpu and the Intel GPU.
  • ifx -fiopenmp -fopenmp-targets=spir64 code.F90
  • ifx -qopenmp -fopenmp-targets=spir64 code.F90

Important Compiler Options Mapping

• ifx will accept many ifort compiler options.  
• Not all ifort options are accepted and/or implemented in ifx.
• Undocumented options from ifort are NOT implemented and there are no plans to do so.  Remember, this is a very different compiler – the old internal, undocumented ifort options have no meaning or mapping to the ifx compiler.  If there is functionality in an undocumented option that you think you need, submit a bug report via Online Service Center (OSC), explain the behavior you expect and how ifx is not providing what you need. “Because ifort accepted this option and it’s in my makefile” is not justification.  This is a different compiler with different optimizations and behavior.  Try ifx without the option.
• Diagnostic warnings are emitted for ifort options that are not CURRENTLY planned to be implemented in ifx. For example,

       command line warning #10148: option '-ip' not supported.

• ifx option –qnextgen-diag causes the ifx to emit a long list of ifort options that are NOT accepted by ifx.
• If you have an unsupported compiler option that is important to your application AND removing it from your build with ifx leads to an error, please report an issue via OSC.  We would like to know which options you need implemented in ifx.
• ifort options that ARE IMPLEMENTED in ifx or will be implemented soon are accepted quietly.
• GNU* and Microsoft* compatible options are accepted by ifort and ifx.

fp-model, fp Compiler Option

UPDATED May 17, 2024

-fp-model=precise (/fp:precise) is supported with ifx.

-fp-model=fast (/fp:fast) and the fp-model=fast=2 (/fp:fast=2) behave differently with ifx and ifort.

• With ifx -fp-model=fast (/fp:fast) sets option -fimf-precision=medium.
  • Currently with ifx 2024.0.0,
    • fast=1 and fast=2 are the same
    • does not generate the check for NaN operands.
• With ifort, -fp-model=fast=2 (/fp:fast2) sets options -fimf-precision=medium (/Qimf-precision:medium) and -fimf-domain-exclusion=15 (/Qimf-domain-exclusion=15). With ifort, floating-point compares happen as specified by the IEEE floating-point standard, in that the code sequence generated for them assumes a compare can involve a NaN.

-fp-model=consistent (/fp:consistent) is supported beginning with ifx 2022.0.0. The Fortran Developer Guide and Reference hasn't caught up yet as of 2024.0.0. It is equivalent to -fp-model precise -no-fma -fimf-arch-consistency=true (/fp:precise /Qfma- /Qimf-arch-consistency:true)

-fp-model=source (/fp:source) is supported with ifx.  This option provides the same precision control as  -fp-model=precise (/fp:precise) but adds -fprotect-parens (/Qprotect-parens)  which forces the compiler to use Fortran expression evaluation rules for expressions containing parenthesis.

-fp-model=except (/fp:except) is not supported with ifx. There is no warning message about that if used.

fimf Family of Compiler Options

UPDATE: December 5, 2023, the optional :funclist is now supported.

With ifx and the fimf* compiler options, the optional:funclist list of functions that is available with ifort is not supported. Here is the list of fimf compiler options.

fimf-absolute-error=value
fimf-accuracy-bits=bits
fimf-arch-consistency=value
fimf-max-error=ulps
fimf-precision=value
fimf-domain-exclusion=classlist

-parallel

With ifort the -parallel compiler option auto-parallelization is enabled. That is not true for ifx; there is no auto-parallelization feature with ifx.

-fstrict-overflow (Linux) /Qstrict-overflow (Windows)

Integer overflow in arithmetic expressions is not permitted by the Fortran standard. However, some legacy programs rely on integer overflow. When overflow occurs, as much of the value as can fit into the result is assigned, and may also result in a change in the sign bit.

By default, the ifx compiler assumes integer arithmetic does not overflow. ifx defaults to -fstrict-overflow (Linux) or /Qstrict-overflow (Windows). When strict-overflow is enabled the compiler assumes that integer operations can never overflow, which allows for better optimizations. But, if overflow does occur, the resulting behavior is undefined and this behavior may not be compatible with the default ifort behavior.

ifort allowed integer overflow. Therefore, programs that rely on the ifort behavior for integer overflow should use the -fno-strict-overflow (Linux) or /Qstrict-overflow- (Windows) with ifx. The -fno-strict-overflow (linux) or /Qstrict-overflow- (Windows) for ifx allows to compiler to assume intergers may overflow and are allowed to overflow.  Allowing overflow in ifx may result in less optimized code.

Optimization Reports

Optimization reports are a work-in-progress for ifx. With each release more information is included. 

Some things to know include:

• The compiler option itself remains the same, -qopt-report | /Qopt-report.
• There are 3 levels of detail available: 1, 2 and 3.
• On Linux the report goes to stdout. On Windows when compiling in a command window, the output goes to the command window.
  • The optimization report that is printed to stdout or the terminal reports the optimizations performed by Intel's proprietary vectorizer.
• On Linux -qopt-report also creates files with the .yaml suffix. That is an optimization report created by the LLVM community. It can be viewed using opt-viewer.py. At this time we recommend the Intel optimization report for Intel optimizations.

Notes on Intel® Advanced Vector Extensions 512 (Intel® AVX-512)

• Compiling with -x or -ax is a SUGGESTION or REQUEST to compiler, not imperative
• ifx sometimes will use AVX2, instead of, AVX-512 instructions.
• Use –mprefer-vector-width=512
  • ifx –mprefer-vector-width=512 …
  • Same as the ifort compiler option: –qopt-zmm-usage=high

Compiler Versioning

• A new versioning macro is defined for ifx
  •  __INTEL_LLVM_COMPILER

• Version String
  The version string for the two compilers, ifort and ifx, is new. With Intel oneAPI semanitic versioning is used. This article explains more about the Intel oneAPI versioning schema. 

  An example:
  ifx –-version 
  ifx (IFORT) 2022.0.0 20211123

  The format is:
       MAJOR.MINOR.PATCH build-string
  where 
  ·    MAJOR is the product version. It may not always match the calendar year.
  ·    MINOR is a single-digit minor version number, starting at “0” for initial release and incremented as needed for minor releases.
  ·    PATCH starts at “0” for the initial release. If a critical PATCH for specific bug and security fixes, the number is incremented.
  The build-string is of the form YYYYMMDD.

Object Files and .mod Files

ifx is binary (.o/.obj) and module (.mod) file compatible with ifort, i.e. 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). Object files created with icc, icl, icpc, icx, icpx, dpcpp are also binary compatible; they will link.

However, if you compile using the -ipo compiler option, there is no compatibility between the object files created by ifort and ifx. 

Proprietary Intel Directives Support

Support for general, non-OpenMP compiler directives (!DIR$) is growing release by release. 

!DIR$ directives are recognized by the front end, but not all are implemented. !DIR$ directives that ifx 2023.0.0 supports are: IVDEP, VECTOR [NO]DYNAMIC_ALIGN,  VECTOR [NO]REMAINDER, DISTRIBUTE_POINT, NOFUSION, [NO]UNROLL, [NO]UNROLL_AND_JAM, among others.

Essential OpenMP Offload Environment Variables 

These environment variables are useful to control and get more information about the computations being offloaded. For more details see this section of the Intel® Fortran Compiler Classic and Intel® Fortran Compiler Developer Guide and Reference.

• Select the target device:  OMP_TARGET_OFFLOAD = mandatory | disabled | default
  • mandatory: The TARGET region runs code on the GPU or other accelerator.
  • disabled: The TARGET region runs on the CPU.
  • default: The TARGET region run on GPU if the device is available, else falls back and runs on the CPU.
• Select the plugin, i.e. device driver: LIBOMPTARGET_PLUGIN = OPENCL | LEVEL0
  • The default is LEVEL0.
  • Companion environment variable: LIBOMPTARGET_DEVICE_TYPE = GPU | CPU
    • The default is GPU.
    • CPU is only implemented for OPENCL.
• Print GPU kernel runtime profile when the program finishes: LIBOMPTARGET_PLUGIN_PROFILE = T
  • The profile includes GPU kernel start and complete time.
  • Data transfer times are also printed.
• Dump offloading runtime debug information
  • LIBOMPTARGET_DEBUG = 0 | 1 | 2
    • The default is 0, disabled.
  • LIBOMPTARGET_INFO = 0 | 1 | 2 | 4 | 8 | 32
    • The default is 0, disabled.
    • See this LLVM documentation for details.

Link Using ifx with dpcpp Object Files

Some developers are choosing to offload compute kernels in a Fortran program using DPC++. 

To link successfully, additional ifx compiler options are required as in this example:

dpcpp -c device.cpp

ifx -qopenmp -fsycl host.f90 device.o -lstdc++ -lsycl

This works for ifx 2022.1.0 and earlier. In a future release, -qopenmp will not be required.

Static and Dynamic Linking of Intel Fortran Libraries with ifx

Linux*

ifort for Linux defaulted to statically linking all but two Intel libraries. This was equivalent to using option -static-intel. The two Intel libraries that did not default to static linking were libiomp5 (the OpenMP runtime library) and libicaf (Coarray Fortran runtime library). To statically link the OpenMP Runtime Library, use compiler option -qopenmp-link=static (default is -qopenmp-link=dynamic). There is no static version of libicaf and it must be linked dynamically.

For ifx for Linux the default is similar to ifort.  Most Intel libraries are linked statically except for: 

1. libicaf (Coarray Fortran library)
2. libiomp5 (OpenMP runtime library)
3. libimf (Intel libm replacement intrinsics)
4. libintlc (libc replacement functions)

For ifx, to get libimf and libintlc to statically link, use the compiler option -static-intel. To statically link the OpenMP Runtime Library, use compiler option -qopenmp-link=static (default is -qopenmp-link=dynamic). There is no static version of libicaf and it must be linked dynamically.

Also, if you are using static linking, make sure no libraries appear in a -l<library name> in the compiler command line.  Adding -l<library name> overrides any -static* option and causes that library to be linked dynamically. For example,

ifx -static-intel -limf foo.f90

will cause libimf to be linked dynamically. 

Windows*

For Windows, both compilers default to dynamic linking in all cases. You cannot use static linking on Windows.

Known Limitations

• With ifx 2023.x, the only I/O allowed with ifx in an OpenMP TARGET region is print * and that is limited to numeric, logical, complex and character strings.
• Support added in ifx 2022.3.0... On Windows* the ATTRIBUTES DLLEXPORT and DLLIMPORT are not yet supported.
• Beginning with ifx 2023.2.0, Windows QuickWin applications are supported.

• COMPLEX data type performance

  • A current ( version 2023.x and older ) shortcoming of the Intel Fortran Compiler is performance when data is COMPLEX.  The datatypes affected are:

    COMPLEX(KIND=4) same as Intel's COMPLEX*8
    COMPLEX(KIND=8) same as Intel's COMPLEX*16 or DOUBLE COMPLEX
    COMPLEX(KIND=16) same as Intel's COMPLEX*32

  • For applications using these datatypes, the Intel Fortran Compiler will show a performance loss in comparison to the Intel Fortran Compiler Classic.  We are working on improving performance for these Fortran intrinsic data types in a future release.

PGO, IPO, and Linking Changes

The ifx compiler has different methods for both Interprocedural Analysis (IPO) and Profile Guided Optimizations (PGO). 

• PGO  
  • PGO (Profile Guided Optimization), as implemented in ifort, is not supported. Profiling is available using the Clang -fprofile compiler options. Refer to Multi-Stage PGO for more information.
• IPO  
  • ​LLVM uses Link Time Optimization (LTO) technology. In ifort it is termed “Interprocedural Optimization” (IPO).

For more information on LLVM LTO, refer to LLVM Link Time Optimization: Design and Implementation.

• -ipo is automatically translated to -flto for the user by the ifx driver.
• The variants of the -ipo compiler option are removed.
• If you compile using the -ipo compiler option, there is no compatibility between the object files created by ifort and ifx. 
• To create a static library using objects compiled with -ipo, use llvm-ar to create the library. The utility is supplied with the Intel compler.

ifx -ipo -c issue.f90
llvm-ar rc ifx_ipo.a issue.o

• Intel linker xi* tools removed
  • Intel tools xilink, xild, and xiar are removed from ifx as they serve no purpose – they are specific to the proprietary object file formats used by the Intel® Compilers.
  • In your Makefiles or Project Settings, if you have used xilink or xild, replace these with the equivalent native linkers. Similarly replace xia with ar or similar archive tool.

ifort Features Not Supported in ifx

• Guided Auto Parallelism
  • Deprecated in ifort
• Profile Guided Optimization (PGO) is implemented using the Clang -fprofile compiler options.
• Identification of code with possible speculative execution side-channel effects

Brutus or Bisectional Optimization Support

If you are unfamiliar with “Brutus” in the Intel Fortran Compiler Classic or Bisectional Optimizations in Clang/LLVM, you may skip this section.

ifx has support for Clang/LLVM –opt-bisect-limit=N for bisectional optimization debug. This is similar to the Brutus option in ifort. A community effort is underway to enhance optimization debugging capabilities in Clang/LLVM through the open source community.

Usage example:

ifx -mllvm -opt-bisect-limit=300 t.f90

For more information, refer to, Using -opt-bisect-limit to debug optimization errors. 

Appendix

References

Useful references include

Intel® Fortran Compiler Classic and Intel® Fortran Compiler Developer Guide and Reference

New Features for ifx in Intel® Fortran Compiler Classic and Intel® Fortran Compiler Developer Guide and Reference

Intel oneAPI Programming Guide  A general guide to help developers get started from setting the environment to compiling and running simple applications.

Fortran Language and OpenMP Features in ifx Updated with each compiler release

Intel® Fortran Compiler for oneAPI Release Notes

Intel® Fortran Compiler Classic - Support for Fortran Language Standards

Intel® Fortran Compiler Information and Frequently Asked Questions

Porting Guide for ICC Users to DPCPP or ICX