Intel® Fortran Compiler 9.1 for
Linux*
Release Notes

Contents

Overview

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 Linux for IA-32 applications, version 9.1

Intel® Debugger for IA-32 applications, version 9.1

Intel® Compilers code-coverage tool

Intel® Compilers test-prioritization tool

The product documentation, version 9.1

The documentation index is provided for easy access of all the documents. It is
located at <install-dir>/doc/Doc_Index.htm

The documentation index is provided for easy access of all the documents. It is
located at <install-dir>/doc/Doc_Index.htm

Compatibility

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.

9.1.040

MULT_HIGH_SIGNED intrinsic

KMP_AFFINITY environment variable

VALUE attribute

9.1.039

BIND(C) statement and attribute

FLUSH statement

IS_IOSTAT_END intrinsic

IS_IOSTAT_EOR intrinsic

NEW_LINE intrinsic

SELECTED_CHAR_KIND intrinsic

-std03 command line option

9.1.037

IMPORT statement

OPTIMIZE directive

-heap-arrays command line option

9.1.036

-check pointer command line option

MEMORYTOUCH directive

Environment variables to specify default record lengths for formatted
and unformatted I/O units

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.

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

-inline-factor=<n>

Specifies the percentage multiplier that should be applied to all inlining
options that define upper limits. (Default: off)

-inline-forceinline

Specifies that an inline routine should be inlined whenever the compiler
can do so. (Default: off)

-inline-max-per-compile=<n>

Specifies the maximum number of times inlining may be applied to an entire
compilation unit. (Default: off)

-inline-max-per-routine=<n>

Specifies the maximum number of times the inliner may inline into a particular
routine. (Default: off)

-inline-max-size=<n>

Specifies the lower limit for the size of what the inliner considers
to be a large routine. (Default: off)

-inline-max-total-size=<n>

Specifies how much larger a routine can normally grow when inline expansion
is performed. (Default: off)

-inline-min-size=<n>

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)

-mcmodel=mem_model

Tells the compiler to use a specific memory model to generate code and
store data. (Intel EM64T only, default: -mcmodel=small)

Tells the compiler to display the name of the file being compiled. (Default: -watch
nosource)

-xT

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 IA-32 and Intel EM64T-based systems when SSE instructions were
used for an operation,
denormalized values were flushed to zero by the processor by default,
improving performance.

On IA-32 and Intel EM64T-based systems when X87 instructions were
used for an operation,
-ftz was ignored, and denormalized values preserved. This
had the effect that computations done in X87 instructions could yield
different results from those done in SSE instructions

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:

A non-pointer entity may not be defined or redefined

A pointer entity may not have its association status changed through
the pointer

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:

IS_IOSTAT_EOR Intrinsic Function (Fortran 2003 feature)

MOVE_ALLOC Intrinsic Subroutine (Fortran 2003 feature)

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

Syntax: CALL MOVE_ALLOC (FROM, TO)

Arguments:

FROM

May be of any type and rank and must be allocatable.

TO

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.

Syntax: SELECTED_CHAR_KIND (NAME)

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.

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.

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.

ASSUME_ALIGNED Directive

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

address may not be a derived type component nor a
variable in COMMON.

address may not be use or host associated.

If address has the POINTER attribute, or is
an integer POINTER variable (using the integer POINTER extension),
the presumed alignment applies to the pointer and not its target.

MEMORYTOUCH Directive

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.

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.

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.

Syntax:

cDEC$
OPTIMIZE[:n]
cDEC$ NOOPTIMIZE

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:

compact,<level>

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

compact,1

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:

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

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.

IA-64

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

A system based on an IA-32 processor (minimum 450 MHz Intel Pentium® II
processor or greater - Intel Pentium® 4 or Intel® Core™ or
Intel® Xeon® processor recommended),
or a system based
on an Intel® 64 architecture processor, or a
system based on an AMD* Athlon* or AMD Opteron* processor

256 MB of RAM (512MB recommended).

100 MB of disk space, plus an additional 200 MB during installation
for the download and temporary files.

Linux system with glibc 2.2.4, 2.2.5, 2.2.93, 2.3.2 , 2.3.3, 2.3.4,
or 2.3.5 and the 2.4.X or 2.6.X Linux kernel as represented by the
following distributions. Note: Not
all distributions listed are validated and not all distributions
are listed.

100 MB of hard disk space for the virtual memory paging file.
Be sure to use at least the minimum amount of virtual memory recommended
for the installed distribution of Linux

Linux system with glibc 2.2.93, 2.3.2, 2.3.3, 2.3.4 or 2.3.5 and
the 2.4.X or 2.6.X Linux kernel as represented by the following Linux
distributions, running in 64-bit mode. Note: Not all distributions
listed are validated and not all distributions are listed.

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: libstdc++.so.5: 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 libstdc++.so.5 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

A system based on an Intel® Itanium® 2 processor.

512 MB of RAM (1 GB recommended).

150 MB of disk space, plus an additional 200 MB during installation
for the download and temporary files.

Linux system with glibc 2.2.4, 2.2.93, 2.3.2, 2.3.3, 2.3.4 or 2.4
and the 2.4.X or 2.6.X Linux kernel as represented by the following
distributions. Note: Not
all distributions listed are validated and not all distributions
are listed.

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.

Notes:

Compiling very large source files (several thousands
of lines) using advanced optimizations such as -O3, -ipo and -openmp,
may require substantially larger amounts of RAM.

The above lists of processor model names are not exhaustive - other
processor models correctly supporting the same instruction set as
those listed are expected to work. Please contact Intel® Premier
Support if you have questions regarding a specific processor model

Some optimization options have restrictions regarding the processor
type on which the application is run. Please see the documentation
of these options for more information.

Installation

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:

/opt/intel/fc/9.1.xxx
(for IA-32 and IA-64)

/opt/intel/fce/9.1.xxx (for Intel® 64)

/opt/intel/idb/9.1.xxx
(for IA-32 and IA-64)

/opt/intel/idbe/9.1.xxx (for Intel® 64)

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.

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:

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
2.11.90.0.27 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 libunwind.so.7 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: libunwind.so.7, needed by /usr/lib/gcc/ia64-suse-linux/4.1.0/../../..//libgcc_s.so,
may conflict with libunwind.so.6

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

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.

Documentation

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.

Additional Information

Related Products and Services

The Intel® Software College
provides training for developers on leading-edge software development
technologies. Training consists of online and instructor-led courses covering
all Intel architectures, platforms, tools, and technologies.

The Intel® VTune™ Performance
Analyzer
enables you to evaluate how your application is utilizing the
CPU and helps you determine if there are modifications you can
make to improve your application's performance.

The Intel® C++
and Fortran Compilers
are an important part of making software run at top speeds with full support
for the latest Intel IA-32 and Itanium® processors.

The Intel®
Performance Library Suite provides a set of routines optimized for
various Intel processors. The
Intel® Math Kernel Library, which provides developers of scientific and
engineering software with a set of linear algebra, fast Fourier transforms and
vector math functions optimized for the latest Intel Pentium® and Intel Itanium
processors. The Intel®
Integrated Performance Primitives consists of cross-platform tools to
build high performance software for several Intel architectures and several
operating systems.

Disclaimer and Legal Information

INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL® PRODUCTS.
NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL
PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL'S
TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY
WHATSOEVER, AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO
SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING
TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY
PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. Intel products are
not intended for use in medical, life saving, life sustaining, critical control
or safety systems, or in nuclear facility applications.

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.