Intel® Fortran Compiler 9.1 for Linux*
Release Notes



This product provides tools for Windows* software developers to create Fortran applications that deliver outstanding performance. Intel® Fortran Compiler is a full-language Fortran 95 compiler with many features from the Fortran 2003 standard, plus a wide range of popular language extensions. Intel Compilers support multi-threaded code development through autoparallelism and OpenMP* support.

Product Contents

Intel® Fortran Compiler for IA-32 Based Applications

The Intel® Fortran compiler for IA-32 based applications contains the following components:

Intel® Fortran Compiler for Intel EM64T-Based Applications

Intel® Fortran Compiler for Itanium-Based Applications

The Intel® Fortran compiler for Itanium-based applications contains the following components:


You must recompile all Fortran sources that were compiled with compilers earlier than version 8.0, including those that create .mod files. Third-party libraries built with versions earlier than 8.0 will also need to be rebuilt. Fortran sources built with Intel Fortran 8.0 or later do not need to be recompiled for use with version 9.1.

Please also see the section below on "Change in Linking Mixed Fortran-C/C++ Applications".

What's New in Version 9.1

The following section discusses new features and changes in the Intel Fortran Compiler version 9.1 and updates to 9.1. Please see the separate release notes for the Intel Debugger.

Change History

This section briefly notes new features and changes added since the initial release of version 9.1. More detailed explanations are given below. Not all updates have feature changes. Please view the README.TXT from Intel® Registration Center Product Downloads for information on corrections to reported errors. Note: update numbers are shown for comparison: the actual update number may be higher.





New and Changed Command Line Options

The following is a listing of command line options that are new or have changed since the initial version 9.0 release. Please refer to the compiler documentation for more information on these options.

-allow [no]fpp-comments
Determines how the fpp preprocessor treats Fortran end-of-line comments in preprocessor directive lines. (Default: -allow fpp-comments)
-assume [no]writeable-strings
Determines whether character constants go into read-only memory. (Default: -assume nowriteable-strings)
Directs the compiler to generate processor-specific code optimized for the Intel® Core™ 2 processor family and the Dual-Core Intel® Xeon® 5100-series processors as well as generic IA-32 code (IA-32 and Intel EM64T only, default: off)
-check [no]pointer
Enables or disables run-time checking for accesses through null pointers or of unallocated ALLOCATABLE variables. (Default: -check nopointer)
-check [no]uninit
Determines whether checking occurs for uninitialized variables. (Default: off)
Enables certain interprocedural optimizations, including inlining, for single file compilation. (Default: on)
Lets you specify the maximum size of a function to be inlined. (Default: off)
-fp-model keyword
Controls the semantics of floating-point calculations. (default: -fp-model fast)
Enables or disables the flushing to zero of floating point calculations that would underflow into the denormal range. The behavior of this option has changed for version 9.1 - please see the note below for more details.
-[no-]heap-arrays[ size]
Specifies that automatic arrays and arrays created for temporary computation should be allocated on the heap rather than the stack
Specifies the percentage multiplier that should be applied to all inlining options that define upper limits. (Default: off)
Specifies that an inline routine should be inlined whenever the compiler can do so. (Default: off)
Specifies the maximum number of times inlining may be applied to an entire compilation unit. (Default: off)
Specifies the maximum number of times the inliner may inline into a particular routine. (Default: off)
Specifies the lower limit for the size of what the inliner considers to be a large routine. (Default: off)
Specifies how much larger a routine can normally grow when inline expansion is performed. (Default: off)
Specifies the upper limit for the size of what the inliner considers to be a small routine. (Default: off)
-isystem <dir>
Specifies a directory to add to the start of the system include path. (Default: off)
Tells the compiler to use a specific memory model to generate code and store data. (Intel EM64T only, default: -mcmodel=small)
-mtune itanium2-p9000
Optimizes for Dual-Core Intel® Itanium® 2 Processor 9000 Sequence processors. (Itanium-only, default: off)
Enables or disables performance tuning and heuristics that control memory bandwidth use among processors. (Itanium-only, default 0 for serial compilations, 1 for parallel compilations)
Tells the compiler to issue warnings for source syntax that does not conform to the Fortran 2003 standard. (Default: off)
-watch [no]cmd
Tells the compiler to display and execute driver tool commands. (Default: -watch nocmd)
-watch [no]source
Tells the compiler to display the name of the file being compiled. (Default: -watch nosource)
Directs the compiler to generate specialized and optimized processor-specific code for the Intel® Core™2 processor family and the Dual-Core Intel® Xeon® 5100-series processors. (IA-32 and Intel EM64T-only, default: off)

Alternate Command Line Options

Many command line options have an older spelling where underscores (“_”) instead of hyphens (“-“) connect the words in the option name. The older spelling is still a valid alternate option name.

Deprecated and Removed Command Line Options

For information on command line options that are either deprecated (still functional but to be removed in a future version) or removed (no longer supported), please refer to the chapter Deprecated and Removed Compiler Options in the Intel® Fortran Compiler Options Manual.

Change in Behavior for -ftz and new -no-ftz

When a floating point calculation results in a value too small to be represented as a full-precision normalized value, the default behavior is for a reduced-precision denormalized value to be stored. However, subsequent calculations using denormalized values can suffer significantly reduced performance. The -ftz compiler option, available in previous versions of the compiler, specifies that such values should be converted (flushed) to zero, improving performance. However, the option was not consistently implemented:

On Intel Itanium-based systems only, -ftz is implicitly in effect if -O3 is specified.

As of version 9.1, -ftz is supported on all processor types and for both SSE and X87 instructions leading to consistent computations. However, there is a significant performance degradation when -ftz is explicitly specified and X87 instructions are used for computations on IA-32 and Intel EM64T-based systems. This option should be used only when consistency for computations that underflow is more important than performance.

If you do not want denormals flushed to zero on Intel Itanium systems when -O3 is also specified, or on IA-32 and Intel EM64T-based systems when SSE instructions are used, specify the new -no-ftz option. This will significantly degrade performance but will preserve denormals while enabling other optimizations.

Use of -fp-model to Control Reassociation

The -fp-model option controls the semantics of floating point operations. The default is -fp-model fast which allows the compiler to perform aggressive optimizations including reassociations across parentheses. To obtain the best performance while still strictly obeying the language standard's rules for arithmetic reassociation, use -fp-model precise.

-[no-]heap-arrays to Control Temporary Array Allocation

By default, automatic arrays and temporary arrays created during computation or for argument passing are created on the stack. This gives the best performance, but if the arrays are very large, they can exceed the limited stack space available. If -heap-arrays is specified, the compiler will cause these arrays to be dynamically (heap) allocated instead, eliminating dependence on stack size limits, but with a small performance penalty that may or may not be noticeable depending on the application. If the optional size value is specified (-heap-arrays:size), the compiler will still stack allocate those arrays known at compile time to be smaller than the specified size in bytes.

MULT_HIGH_SIGNED Intrinsic (IA-64 only)

The MULT_HIGH_SIGNED intrinsic, available for the IA-64 platform only, is similar to the existing MULT_HIGH intrinsic except that the arguments are signed INTEGER(8) values and the result is the high 64 bits of the signed 128-bit result.

Rename of User-Defined Operators in USE (Fortran 2003 feature)

A rename clause on a USE statement may now also specify a defined operator. For example:

USE mymod, OPERATOR(.localop.) => OPERATOR(.moduleop.)

BIND(C) Attribute and Statement (Fortran 2003 feature)

The BIND(C) attribute specifies that the named variable, common block or procedure is interoperable with C and has external linkage. Optionally, a character value can be specified which is used to construct the external name. For variables and common blocks, BIND also implies the SAVE attribute, which may be explicitly confirmed with SAVE. some examples:




The compiler applies the same rules it would for a name with the C attribute extension - names are downcased (unless NAME= is specified) and the appropriate platform decoration, such as a leading underscore, is applied.

PROTECTED Attribute and Statement (Fortran 2003 feature)

The PROTECTED attribute restricts the use of module entities. Other than within the module within which the entity has been given the PROTECTED attribute. the following restrictions apply:

If an object has the PROTECTED attribute, all of its subobjects have the PROTECTED attribute.

VALUE Attribute and Statement (Fortran 2003 feature)

The VALUE attribute specifies that a by-value passing mechanism shall be used for an argument. If provided in an explicit interface, the specified argument is passed by value. If used in a procedure, the argument is received by value. It has the same meaning as the ATTRIBUTES VALUE directive applied to a dummy argument. (The VALUE attribute, unlike the ATTRIBUTES VALUE directive, cannot be specified for a procedure.)

INTENT Attribute for Pointer Objects (Fortran 2003 feature)

Pointer dummy arguments may now have the INTENT attribute specified. The INTENT attribute restricts how the association status of the pointer may change - it does not restrict changes to the target of the pointer.

FLUSH statement (Fortran 2003 feature)

Execution of a FLUSH statement causes data written to an external file to be available to other processors. Syntax:

FLUSH file-unit-number

FLUSH ([UNIT=]file-unit-number [, IOSTAT=scalar-int-variable] [, ERR=label])

Note that the IOMSG specifier of Fortran 2003 is not yet supported.

IS_IOSTAT_END Intrinsic Function (Fortran 2003 feature)

Determines whether a value specifies an end-of-file condition


Argument: I shall be of type integer

Result: Default logical

IS_IOSTAT_EOR Intrinsic Function (Fortran 2003 feature)

Determines whether a value specifies an end-of-record condition


Argument: I shall be of type integer

Result: Default logical

MOVE_ALLOC Intrinsic Subroutine (Fortran 2003 feature)

The MOVE_ALLOC intrinsic subroutine moves an allocation from one allocatable object to another.



May be of any type and rank and must be allocatable.
Must be type compatible with FROM, have the same rank, and be allocatable.

If TO is currently allocated, it is deallocated. Then, if FROM is allocated, TO becomes allocated with the same bounds and value identical to that of FROM. Lastly, FROM is deallocated. If TO has the TARGET attribute, any pointer associated with FROM at the time of the call to MOVE_ALLOC is now associated with TO.

The implementation of MOVE_ALLOC is such that the internal descriptor contents are copied from FROM to TO, so that the storage pointed to is the same. The typical use of MOVE_ALLOC is to provide for an efficient implementation of reallocating a variable to a larger size without copying the data twice.

NEW_LINE Intrinsic Function (Fortran 2003 feature)

Returns a newline character.

Syntax: NEW_LINE(A)

Argument: A shall be of type character. It may be a scalar or an array

Result: Character scalar of length one with the same kind type parameter as A. The value is the ASCII newline character CHAR(10).

SELECTED_CHAR_KIND Intrinsic Function (Fortran 2003 feature)

Returns the value of the kind type parameter of the character set named by the argument.


Argument: NAME shall be scalar and of type default character. Supported values are 'DEFAULT' and 'ASCII'.

Result: Default integer scalar. The value is 1 for NAME of 'DEFAULT' or 'ASCII' and -1 otherwise.

IMPORT Statement (Fortran 2003 feature)

The IMPORT statement is allowed within an interface body only and specifies that entities from the host scoping unit are accessible within the interface body.

Syntax: IMPORT [[ :: ] import-name-list ]

Consider the following module:

module mymod
type mytype
 integer comp
 end type mytype

subroutine sub (arg)
 type(mytype) :: arg
 end subroutine sub
end interface
end module mymod

Inside the interface, type mytype is not defined because symbols from the host scope (module mymod) are not visible within an interface block. In Fortran 95, the solution to this problem would be to either create a new module containing type mytype and add a USE of that module to both mymod and the interface body, or to repeat the definition of type mytype within the interface body.

If the interface body was rewritten as:

subroutine sub (arg)
 type(mytype) :: arg
 end subroutine sub

then type mytype (and any other symbols visible in the module scope) can be used within the interface body and there is no need for a separate module nor repeated declarations. If there is no import-name-list, then all accessible symbols from the host scope are accessible within the interface body. If import-name-list appears, only those named symbols are imported. Any symbols made visible this way must have been declared prior to the interface body.


The ASSUME_ALIGNED directive tells the compiler to assume that a variable's memory allocation is aligned on a particular address boundary. This can aid in certain optimizations.

Syntax: cDEC$ ASSUME_ALIGNED address1:n1 [ , address2:n2] ...

address is a memory reference (variable name, array reference, etc.)

n1 is a positive integer initialization expression with one of the following values: 1, 2, 4, 8. 16, 32, 64, 128, 256


When running OpenMP* multiprocessor applications on a system with Non-Uniform Memory Access (NUMA), performance can suffer if computations access memory that is associated with a different processor. The new MEMORYTOUCH directive allows the programmer to inform the processor that it will be reading or writing a memory range in the future. The compiler will attempt to ensure that the memory is allocated locally to the processor making the request.


!DEC$ MEMORYTOUCH (array-name [ , schedule-type [ ( chunk-size ) ]] [ , init-type])


is a directive introducer
is an array of type INTEGER(4), INTEGER(8), REAL(4) or REAL(8)
is an integer expression
is one of LOAD or STORE

If init-type is LOAD, the compiler generates an OpenMP loop which fetches elements of array-name into a temporary variable. If init-type is STORE, the compiler generates an OpenMP loop which sets elements of array-name to zero.


!DIR$ memorytouch (A)
!DIR$ memorytouch (A , LOAD)
!DIR$ memorytouch (A , STATIC (load+jf(3)) )
!DIR$ memorytouch (A , GUIDED (20), STORE)

While the MEMORYTOUCH directive is accepted on all platforms, at present it is meaningful only on certain Itanium-based systems with NUMA designs and when OpenMP is enabled.

OPTIMIZE Directive

General Compiler Directive: Enables or disables optimizations.



c Is one of the following: C (or c), !, or *. (See Syntax Rules for Compiler Directives in the Intel Fortran Language Reference.)

n Is the number denoting the optimization level. The number can be 0, 1, 2, or 3, which corresponds to compiler options O0, O1, O2, and O3. If n is omitted, the default is 2, which corresponds to option O2.

Description The OPTIMIZE and NOOPTIMIZE directives can appear once only at the top of a procedure program unit. A procedure program unit is a main program, an external subroutine or function, or a module. OPTIMIZE and NOOPTIMIZE cannot appear between program units nor in a block data program unit. They do not affect any modules invoked with the USE statement in the program unit that contains them. They do affect CONTAINed procedures that do not contain an explicit OPTIMIZE or NOOPTIMIZE directive.

NOOPTIMIZE is the same as OPTIMIZE:0. They are both equivalent to -O0 (Linux* and Mac OS*) and /Od (Windows*).

The procedure is compiled with an optimization level equal to the smaller of n and the optimization level specified by the O compiler option on the command line. For example, if the procedure contains the directive NOOPTIMIZE and the program is compiled with the -O3 (Linux and Mac OS) or /O3 (Windows) command line option, this procedure is compiled at O0 while the rest of the program is compiled at O3.

ABORT Library Routine Now Exits with Non-Zero Status

A program whose execution is terminated by a call to the ABORT library routine, defined in module IFPORT, now exits with a status of 134. In previous releases, the exit status was set to zero.

Buffering Now Supported for Direct-Access I/O

You may now enable buffering for units opened for direct-access I/O. Buffering causes the run-time library to read or write multiple records in a single disk operation. This can greatly improve run-time performance for applications that use direct-access I/O to access records in order, but may harm performance for applications that access records out-of-order. Buffering can be enabled or disabled in the same manner as for sequential I/O, including the BUFFERED keyword for OPEN, the -assume buffered_io compile command option, and the FORT_BUFFERED environment variable.

New Environment Variables to Specify Default Record Lengths

Two new environment variables are available to change the run-time behavior of applications: FORT_FMT_RECL and FORT_UNFMT_RECL.

FORT_FMT_RECL is used to specify a default RECL (Record Length) value for all Fortran units opened for formatted I/O. If defined with an unsigned decimal integer value, the environment variable value is used as if that value had been specified for RECL= for OPEN when the RECORDTYPE is not 'FIXED'. The most common use of this is to change the line length for list-directed output, which has a default of 80 columns.

FORT_UNFMT_RECL is used to specify a default RECL (Record Length) value for all Fortran units opened for unformatted I/O. If defined with an unsigned decimal integer value, the environment variable value is used as if that value had been specified for RECL= for OPEN when the RECORDTYPE is not 'FIXED'. The most common use of this is to change the maximum segment length for files opened with RECORDTYPE='SEGMENTED', which has a default of 2040 bytes.

KMP_AFFINITY Environment Variable for OpenMP* Applications

The KMP_AFFINITY environment variable can be used in an OpenMP* application to specify how execution threads should be bound to processors on the system. This setting's effect is to bind each thread, in order of creation, in a round-robin fashion to a processor core in the system for the duration of the program. The value of KMP_AFFINITY should be of the form:


where <level> is a non-negative integer. For example:


The argument <level> specifies the gap between successive thread's bound cores in the machine topology map, which is represented as a binary tree. A level of zero indicates that threads will be bound to successive threading contexts for processors which have Intel® Hyper-Threading Technology enabled, or successive processors if not. The levels increase by one level from threading contexts, to cores, to packages (processors) in sequence. This setting is supported for processors supplied by Intel Corporation only on systems where the required operating system support for thread binding is present.

Change in Linking Mixed Fortran-C++ Applications

Fortran applications are no longer linked against a C++ runtime library by default. If the Intel Fortran driver ( ifort) is used to link mixed C++ and Fortran applications, there are three switches that can be used to specify linking against the correct libraries:

-cxxlib tells the ifort driver to link against the default C++ libraries on the system. If the GNU gcc version is lower than 3.2, the older Intel C++ (Dinkumware*) libraries will be used, otherwise the default GNU g++ libraries will be used. You can change the library selection with one of the following two switches to be used in addition to -cxxlib.

-cxxlib-icc specifies that the older Intel C++ (Dinkumware*) libraries are to be used, regardless of the installed gcc version. Note that current versions of the Intel® C++ Compiler use the gcc libraries by default.

-cxxlib-gcc specifies that the GNU G++ libraries are to be used, regardless of the installed gcc version. Note that link errors may occur if the installed gcc lower than 3.2. You may also specify a path to the gcc libraries you want used with the variant -cxxlib-gcc=pathtolibs.

For example, if you were to use the ifort driver to link a mixed-language application, your command line might be:

ifort prog.f90 prog_cpp_code.o -cxxlib -cxxlib-gcc

-fexceptions Allows C++ Exceptions to Propagate Through Fortran Code

If your application is a mixture of C++ and Fortran, and there is a possibility that a C++ raised exception needs to propagate through a Fortran call frame, (for example, if C++ calls Fortran which calls another C++ routine that raises an exception), you need to compile the Fortran code with the -fexceptions switch. -fexceptions causes additional information to be added to the object file that is required during C++ exception handling.

libimf linking change on Intel EM64T

In some earlier versions of Intel Fortran Compiler, applications built for Intel EM64T linked by default to the dynamic (shared object) version of libimf, even though other libraries were linked statically. As of version 9.0.033, libimf is linked statically unless -i-dynamic is used. This matches the behavior on IA-32 systems. You should use -i-dynamic to specify the dynamic Intel libraries if you are linking against shared objects built by Intel compilers.

A side effect of this change is that users may see the following message from the linker:

warning: feupdateenv is not implemented and will always fail

This warning is due to a mismatch of library types and can be ignored. The warning will not appear if -i-dynamic is used.

Constants Are Now Read-Only

The compiler has changed so that constants, including literals and named constants (PARAMETER), are allocated in a memory section that is protected against write access. This means that if a constant is passed as an actual argument to a procedure and the procedure tries to modify the argument, a segmentation violation (segv fault) will result. For example:

call sub (3)
subroutine sub (i)
i = i + 1 ! Will cause a segv

The Fortran language prohibits changing the definition status of an argument associated with a constant or expression. If your application needs to do so, you can specify the -assume noprotect_constants option. This will instruct the compiler to create and pass a temporary copy of the constant actual argument. The called procedure can then change this copy which will then be discarded when the procedure exits.

Red Hat* Linux 7.3 and Red Hat Advanced Server 2.1 Support Deprecated

The Intel compilers will remove support for Red Hat Linux 7.3 and Red Hat Advanced Server 2.1 in the next major compiler release (version number higher than 9.1.) We recommend that customers plan accordingly.

Fortran 2003 Feature Summary

The Intel Fortran Compiler supports many features that are new to the latest revision of the Fortran standard, Fortran 2003. Additional Fortran 2003 features will appear in future versions. Fortran 2003 features supported by the current compiler include:

Small, Medium and Large Memory Models on Intel® 64-based Systems

Applications built to take advantage of Intel® 64 can be built with one of three memory models:

Small (default)
Code and data are restricted to the first 2GB of address space, so that all accesses of code and data can be done with Instruction Pointer (IP)-relative addressing
Medium (-mcmodel=medium)
Code is restricted to the first 2GB, no restriction on data; code can be accessed with IP-relative addressing, but access of data must use absolute addressing
Large (-mcmodel=large)
No restrictions on code or data; accesses to both code and data use absolute addressing

IP-relative addressing requires only 32 bits, whereas absolute addressing requires 64-bits. This can affect code size and performance (IP-relative addressing is somewhat faster.)

Note: When the medium or large memory models are specified, you must also specify -i-dynamic to ensure that the correct dynamic versions of the Intel run-time libraries are used.

When shared objects (.so) are built, Position-Independent Code (PIC) is specified (-fpic is added by the compiler driver) so that a single .so can support all three memory models. However, code that is to be placed in a static library, or linked statically, must be built with the proper memory model specified. Note that there is a performance impact to specifying the Medium or Large memory models.

System Requirements

Processor Terminology

Intel compilers support three platforms: general combinations of processor and operating system type. This section explains the terms that Intel uses to describe the platforms in its documentation, installation procedures and support site.

IA-32 (Intel Architecture, 32-bit) refers to systems based on 32-bit processors supporting at least the Pentium® II instruction set, for example, Intel® Core™ processor or Intel® Xeon® processor), or processors from other manufacturers supporting the same instruction set, running a 32-bit operating system ("Linux x86").
Intel® 64
Intel® 64 (formerly Intel® EM64T) refers to systems based on IA-32 processors which have 64-bit architectural extensions, for example, Intel® Core™2 processor or Intel® Xeon® processor), running a 64-bit operating system ("Linux x86_64"). If the system is running a 32-bit version of the Linux operating system, then IA-32 applies instead. Systems based on the AMD* Athlon64* and Opteron* processors running a 64-bit operating system are also supported by Intel compilers for Intel® 64-based applications.
Refers to systems based on the Intel Itanium® 2 processor running a 64-bit operating system.
Note: For version 9.1, documentation and product components still use the term Intel® EM64T. In a future release, the term Intel® 64 will be used consistently.

Native and Cross-Platform Development

The term "native" refers to building an application that will run on the same platform that it was built on, for example, building on IA-32 to run on IA-32. The term "cross-platform" or "cross-compilation" refers to building an application on a platform type different from the one on which it will be run, for example, building on IA-32 to run on Intel Itanium®. Not all combinations of cross-platform development are supported and some combinations may require installation of optional tools and libraries.

The following list describes the supported combinations of compilation host (system on which you build the application) and application target (system on which the application runs).

IA-32 Host
Supported target: IA-32
Intel® 64-based Host
Supported targets: IA-32 and Intel® 64
IA-64 Host
Supported target: IA-64

Note: Development for a target different from the host may require optional library components to be installed from your Linux Distribution.

Note: Intel® Cluster OpenMP* is a separately licensed feature and has different system requirements from that of the compilers. Please refer to the Intel Cluster OpenMP documentation for further details.

Requirements to develop IA-32 applications

Requirements to Develop Applications for Intel® 64 or for AMD Opteron Processors

Note: The requirement for the 32-bit (IA-32) libraries is due to the compiler and other tools being 32-bit applications that dynamically link to these libraries. If these libraries are not installed, the following error may be displayed when the compiler is invoked:

error while loading shared libraries: cannot open shared object file: No such file or directory

The error message is confusing as it does not indicate that the IA-32 version of is required. To avoid this problem, be sure that the 32-bit (IA-32) versions of these libraries are installed. Most, but not all, Linux distributions for Intel® 64 will install these by default. Consult the documentation that came with your Linux distribution for instructions on how to install the 32-bit libraries, typically in packages named libstdc++ and libc.  If you still have problems, please contact Intel® Premier Support for further assistance.

Requirements to Develop IA-64 Applications

Note on gcc Versions

The Intel compilers are tested with a number of different Linux distributions, with different versions of gcc. If you are using any of gcc 3.2.3, 3.3.3, 3.3, 2.96, 3.2, 3.4, 4.0, 4.1, you can expect to be successful. However the version of binutils can impact your experience: later ones are generally better and we recommend using at least 2.14. Some Linux distributions may contain header files different from those we have tested, which may cause problems. The version of glibc you use must be consistent with the version of gcc in use.



Please see the separate Installation Guide for information on installing the compiler and setting up the compiler environment. The default installation directories, referred to elsewhere in this document as <install-dir> and <idb-install-dir>, are:

Known Issues

Binary Incompatibility for OpenMP Applications

Programs compiled with the Intel Compiler version 9.0 using the -openmp switch may not run after installing the Intel Compiler version 9.1. For such programs, the loader may exit at run time with an error message about undefined symbols beginning with the string _intel (for example, _intel_fast_memset). If this occurs, please recompile the executable using the Intel Compiler version 9.1 and the loader error message should disappear.

Installation Warning for RPM 4.0.2 and RPM 4.1

RPM 4.0.2 cannot install to a non-default directory. This has been resolved in RPM 4.0.3. RPM 4.1 cannot install to a non-default directory. This has been resolved in RPM 4.11 to 4.2.

Segmentation Violation with Static Link to libpthreads

Applications built with libpthreads.a statically linked, (libpthreads.a is used by default when -static is used), may fail with a segmentation violation on some versions of Linux when the applications use more than 2GB of stack space. This is a known limitation of Linuxthreads. If you encounter this problem, link libpthreads dynamically. As an alternative, on Red Hat Linux 9 and Red Hat Enterprise Linux 3.0, you can install the nptl-devel package and pass "-I/usr/include/nptl -L/usr/lib/nptl" on the ifort command line. This will create a statically-linked binary which will run under nptl only, but which does not have the stack size limitation.

OpenMP Limitations

POSIX threaded programs that require a large stack size may not run correctly on some versions of Linux because of hard-coded stack size limits in some versions of the Linux POSIX threads libraries. These limits also apply to OpenMP programs (-openmp) and automatically generated parallel programs (-parallel) with the Intel compilers, because the Intel compilers use the POSIX threads library to implement OpenMP based and automatically generated parallelism. Threaded programs that exceed the stack space limit usually experience segmentation violations or addressing errors.

To avoid these limitations, use a version of glibc built with the FLOATING_STACKS parameter defined. For some distributions, this implies using the shared rather than the static version of the pthreads library. Then use the ulimit -s or limit stacksize command to set the maximum shell stack size to an explicit large value, in units of KBytes, (not unlimited), and also set the KMP_STACKSIZE environment variable to the needed thread stacksize in bytes. Note, in the bash shell, ulimit -s can be used to set a large maximum stack size only once. In the C shell (csh), limit stacksize , with no dash before the argument, can be used to reset the maximum stacksize repeatedly.

This solution has been tested on glibc version 2.2.4-13 for IA-32 and glibc 2.2.4-19 for IA-64 as found in the RedHat 7.2 Linux distribution. For glibc 2.2.4-13 on IA-32, the shared version of the POSIX threads library must be used, (there should not be a -static flag in the compiler .cfg file or on the command line).

In addition, if a common block is declared as THREADPRIVATE with an OpenMP directive, the common block must have the same length in all the source files in which it is declared.

Itanium Floating Point Software Assistance Handler 1.12 Error on Red Hat Linux 7.2

On Itanium-based systems, the Floating Point Software Assistance handler (FPSWA), part of the system BIOS, performs software completion of floating point operations that generate exceptional values such as NaNs and Infinities. Version 1.12 of the FPSWA has an error which can be revealed on Red Hat Linux 7.2 systems as an unexpected segmentation violation fault when an application runs. Intel is not aware that this issue affects other distributions or versions of Linux on Itanium systems.

To correct this problem, upgrade the system BIOS to one that includes FPSWA version 1.18 or later. Please contact your system manufacturer for BIOS update information.

gprel relocation Error Messages on IA-64 Linux Systems

On IA-64 systems running Linux, when the -shared switch is used to create a Dynamic Shared Object (.so), there may be some "relocation against dynamic symbol" messages generated during the ld phase, similar to:

/usr/bin/ld: for_init.o: @gprel relocation against dynamic symbol for__segv_default_msg
/usr/bin/ld: for_init.o: @gprel relocation against dynamic symbol for__l_fpe_mask
/usr/bin/ld: for_init.o: @gprel relocation against dynamic symbol for__l_undcnt

To fix this problem, add the switches -i_dynamic and -nofor_main to the command line. As of version 9.0, specifying -shared will automatically set -i_dynamic and -nofor_main.

-ipo_obj option is no longer supported

The -ipo_obj option, which forced generation of direct object code, is no longer supported. If the option is specified, a warning is given and the effect is as if -ip was specified instead.

-relax no longer passed to linker on Itanium-based systems

As of version 9.0, the compiler driver no longer passes the -relax switch to the linker on Itanium-based systems, as this conflicts with the -r option. The -relax option is not needed as it is the default when using binutils or later - 2.14 is recommended. If you must use an older binutils and wish to specify the -relax option, use -Xlinker -relax on the compile command which invokes the linker.

ld warning about on SLES 10

When applications are built using the Intel compiler on SUSE LINUX Enterprise Server 10, you may see a warning similar to the following:

ld: warning:, needed by /usr/lib/gcc/ia64-suse-linux/4.1.0/../../..//, may conflict with

A workaround is to add the following line to ifort.cfg:

-L /usr/lib

This issue is expected to be resolved in a future release of the Intel compiler.

Limited debug information with automatic CPU dispatching (-ax*)

Compilation using -ax{W|N|B|P|T} results in two copies of generated code for each function. One for IA-32 generic code and one for CPU specific code. The symbol for each function then refers to an Auto CPU Dispatch routine that decides at run-time which one of the generated code sections to execute. Debugger breakpoints that are set on these functions by name cause the application to stop in the dispatch routine. This may cause unexpected behavior when debugging. This issue may be addressed in a future version of the Intel Debugger and Compilers.

Cannot debug or view traceback for IA-32 programs built without -fp

Compilation using -fp specifies that the IA-32 EBP register be used as a frame pointer rather than a general purpose register. Debuggers and traceback handlers may not be able to properly unwind through a stack that contains a call to a function that is compiled without -fp in effect. If you compile with -g or -O0, -fp is implicitly enabled, but not if you specify a higher optimization level explicitly (such as -O2). If you intend to use the debugger or traceback on an application, and are using some level of optimization higher than -O0, you should also specify -fp to ensure that the debugger and traceback handler can use frame pointers.

GNU* assembler may not recognize -xP generated code

Older versions of the GNU Assembler may not be able to process assembly code generated by compiling with the -[a]xP option. Use binutils version or later, or FSFbinutils 2.15 or later if this is an issue for you.

Use idb with Extended Debug Information

If you use the -debug keywords inline_debug_info, semantic_stepping, variable_locations or extended, you should use the Intel Debugger (idb), as other debuggers may not understand the extended information and may behave unpredictably. We are working with the developers of other debuggers towards their adding support for the extended debug information.

-auto_ilp32 Option Not Supported

The -auto_ilp32 option which specifies that that an application cannot exceed a 32-bit address space, and which is mentioned in the documentation, is not supported.

Technical Support

For information about how to find Technical Support, Product Updates, Users Forums, FAQs, tips and tricks, and other support information, please visit: For general support information please visit

Note: If your distributor provides technical support for this product, please contact them for support rather than Intel.

Resolved Issues

Please review <package ID>_README (e.g. l_fc_p_9.1.xxx_README), available for download along with each compiler update, to see which issues have been resolved in the latest version of the compiler.

Compiler Error Source Reducer (CESR)

Compiler Error Source Reducer (CESR) is a set of utilities which are useful individually or collectively in gathering, reducing, pinpointing, protecting, documenting, and bundling test cases comprised of C/C++ or Fortran source code. It can be helpful if you have a large application for which you want to extract a small test case for submission to Intel® Premier Support. CESR can be downloaded from Intel® Registration Center Product Downloads. Select your product and in the version dropdown, select CESR. CESR is unsupported and should be considered experimental, but we welcome your feedback on it through Intel® Premier Support. CESR requires prior installation of Python 2.2 or newer.


You can view the Intel compiler and related HTML-based documentation with your Web browser. You should use a Web browser that supports JavaScript (such as Firefox*), so it can which provide full navigation, search, index look-up, and hyperlink capabilities amongst the online help files.

The documentation is installed in the <install-dir>/doc directory. An HTML index document can be found at <install-dir>/doc/Doc_Index.htm . The Intel® Debugger Manual is provided in HTML form in the Intel® Debugger doc directory.

Viewing Manpages

The ifort(1) manpage provides a list of command-line options and related information for the ifort compiler command. To display the ifort(1) manpage, type the following command after you set up your environment by using a source command to execute the <install-dir>/bin/ifortvars.*sh file:

$ man ifort

The man command provides single keys or key combinations that let you scroll through the displayed content, search for a string, jump to a location, and perform other functions. For example, type the z to view the next screen or w to view the previous screen. To obtain help about the man command, type the h key; when you are done viewing help, type the q key to return to the displayed manpage. To search, type / character followed by the search string (/string) and press Enter. After viewing the man command text, type q to return to the shell command prompt.

Viewing Documentation

The HTML documentation format has been tested to work with web browsers shipped on supported Linux* distributions. PDF versions of the compiler documentation are available at:

Additional Information

Related Products and Services

Information on Intel software development products is available at

Some of the related products include:

Disclaimer and Legal Information


Intel may make changes to specifications and product descriptions at any time, without notice.

Designers must not rely on the absence or characteristics of any features or instructions marked "reserved" or "undefined." Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them.

The software described in this document may contain software defects which may cause the product to deviate from published specifications. Current characterized software defects are available on request.

This document as well as the software described in it is furnished under license and may only be used or copied in accordance with the terms of the license. The information in this document is furnished for informational use only, is subject to change without notice, and should not be construed as a commitment by Intel Corporation. Intel Corporation assumes no responsibility or liability for any errors or inaccuracies that may appear in this document or any software that may be provided in association with this document. Except as permitted by such license, no part of this document may be reproduced, stored in a retrieval system, or transmitted in any form or by any means without the express written consent of Intel Corporation.

BunnyPeople, Celeron, Celeron Inside, Centrino, Centrino logo, Core Inside, FlashFile, i960, InstantIP, Intel, Intel logo, Intel386, Intel486, Intel740, IntelDX2, IntelDX4, IntelSX2, Intel Core, Intel Inside, Intel Inside logo, Intel. Leap ahead., Intel. Leap ahead. logo, Intel NetBurst, Intel NetMerge, Intel NetStructure, Intel SingleDriver, Intel SpeedStep, Intel StrataFlash, Intel Viiv, Intel vPro, Intel XScale, IPLink, Itanium, Itanium Inside, MCS, MMX, Oplus, OverDrive, PDCharm, Pentium, Pentium Inside, skoool, Sound Mark, The Journey Inside, VTune, Xeon, and Xeon Inside are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.

* Other names and brands may be claimed as the property of others.

Copyright (C) 2007, Intel Corporation.