IntelŪ Fortran Compiler 9.0 for Linux*
Release Notes

Contents

Overview

This product provides tools for Linux* software developers to create applications that run at top speeds on all IntelŪ IA-32 processors, Intel processors with IntelŪ Extended Memory 64 Technology (IntelŪ EM64T) and the Intel ItaniumŪ 2 processors. Optimizations include support for Streaming SIMD Extensions 2 (SSE2) in the Intel PentiumŪ 4 and Pentium M processors, Streaming SIMD Extensions 3 (SSE3) in the Intel Pentium 4 processors with SSE3 support, and software pipelining in the Intel ItaniumŪ 2 processor. Inter-procedural optimization (IPO) and profile-guided optimization (PGO) can provide greater application performance. Intel Compilers support multi-threaded code development through autoparallelism and OpenMP* support.

The paper, Optimizing Applications with the IntelŪ C++ and Fortran Compilers for Windows* and Linux, explains how to use the Intel compilers to optimize for the Pentium 4 and Itanium processors and is available at http://www.intel.com/software/products/compilers/ . Additional information on the Intel Software Development Products is available at http://www.intel.com/software/products/ .

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:

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 - if you are using third-party libraries that do not support Intel Fortran, please let us know which ones through IntelŪ Premier Support at https://premier.intel.com. Fortran sources built with Intel Fortran 8.0 or later do not need to be recompiled for use with version 9.0.

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

Changes in Version 9.0

The following section discusses new features and changes in the Intel Fortran Compiler version 9.0 and updates to 9.0. Please see the separate release notes for the Intel Debugger. For a quick summary of changes after the 9.0 release, please refer to the Change History.

Compiler

New Compiler Options

Some compiler options are only available on certain systems, as indicated by these labels:

i32
The option is available on IA-32 based systems
i32em
The option is available on IA-32-based systems with Intel® Extended Memory 64 Technology (Intel® EM64T)
i64
The option is available on Itanium®-based systems

If no label appears, the option is available on all supported systems. If "only" appears in the label, the option is available on the identified system(s) only.

For more details on the options, refer to the Alphabetical Compiler Options section of the Intel Fortran Compiler for Linux User's Guide.

-allow [no]fpp_comments
Specifies the comment style in fpp-preprocessed source. See below for more details.
-assume [no]2underscores
Specifies whether or not the compiler appends two underscores to external names containing an underscore, for compatibility with g77 naming behavior. (Note that this does not provide object compatibility with g77.)
-B<prefix>
Specifies where to find libraries, headers and executables for the compiler itself.
-cxxlib
Specifies that C++ run-time libraries are to be linked in to the application. See the section below on building mixed Fortran-C++ applications for more information.
-cxxlib-gcc[=pathname]
Specifies that the GNU C++ libraries are to be used when -cxxlib is also specified. This is the default when -cxxlib is specified and the installed gcc version is greater than 3.2. An optional path to the GNU C++ libraries may be optionally specified.
-cxxlib-icc
Specifies that the older Intel C++ (Dinkumware*) libraries are to be used when -cxxlib is also specified. This is the default when -cxxlib is specified and the installed gcc version is 3.2 or lower.
-debug [no]inline_debug_info
Specifies whether enhanced source position information is produced for inlined code.
-debug [no]semantic_stepping
Specifies whether enhanced debug information useful for breakpoints and stepping is produced.
-debug extended
Enables all -debug options except inline_debug_info.
-debug-parameters all
Specifies that debug information should be generated for all declared PARAMETER constants
-debug-parameters used
Specifies that debug information should be generated for only those PARAMETER constants used in the code. Same as -debug-parameters
-debug-parameters none
Specifies that debug information should not be generated for PARAMETER constants
-fexceptions
Specifies that additional object code information is to be generated to allow C++ exceptions to propagate through Fortran call frames
-f[no-]math-errno
Tells the compiler that errno can be reliably tested after calls to standard math library functions.
-f[no-]omit-frame-pointer ( i32 only)
Indicates whether the compiler should use the frame pointer for IA32. -fno-omit-frame-pointer is a synonym for -fp.
-ftrapuv
Initializes stack local variables to an unusual value that may help detect uninitialized variables.
-funroll-loops
Tells the compiler to unroll user loops based on the default optimization heuristics. Synonym for -unroll.
-[no]gen-interfaces
Tells the compiler to generate an interface block for each routine in a source file.
-[no-]global-hoist
Determines whether certain optimizations are enabled that can move memory loads to a point earlier in the program execution than where they appear in the source.
-i-dynamic
Links Intel-provided libraries dynamically (required if using -mcmodel=medium or -mcmodel=large for EM64T)
-i-static
Links Intel-provided libraries statically.
-map-opts
Enables a tool that maps a command line to another platform (Windows* to Linux* or vice versa).
-m[no-]ieee-fp
Controls whether the compiler uses IEEE floating point comparisons.
-mtune=<keyword>
Performs optimizations for a particular CPU.
-[no-]prec-sqrt ( i32, i32em only)
Determines whether or not to disable certain optimizations that improve performance of square root operations while slightly reducing precision.
-print-multi-lib
Displays information about libraries being used.
-prof-gen-sampling
Asks the compiler to prepare the code for use with the sample-gathering tool profrun.
-sox
Causes the compiler to save compiler version and compilation options in the object and executable files (new for i64)
-ssp (i32 only)
Enables the software-based speculative pre-computation (SSP) optimization to generate prefetching helper threads.
--version
Displays compiler version information.
-warn [no]interfaces
Lets you check the interfaces of all SUBROUTINEs called and FUNCTIONs invoked in your compilation - used in conjunction with -gen-interfaces.
-WB
Turns a compile-time bounds check error into a warning.

New Language Features

The following features from the Fortran 2003 standard are now supported by the Intel Fortran Compiler

The following is a list of additional new and changed language features. Please see the Intel Fortran Language Reference for more information.

Loop Directives May Now Be Used For Array Assignments

Loop directives such as IVDEP and NOUNROLL may now be placed preceding array assignments and will apply to loops generated by the compiler for such assignments. For more information, see the Language Reference section "Rules for Loop Directives that Affect Array Assignment Statements" in the chapter on Directives.

OpenMP WORKSHARE Directive Supported

The OpenMP* 2.0 WORKSHARE directive is now supported.

IF and DO Nesting Maximum Level Increased to 256

The maximum nesting level for IF and DO constructs (combined) has been increased from 128 to 256.

Automatic Interface Checking

The compiler is now able to perform some degree of consistency checking between call and called routine in an application in the absence of explicit interfaces, even across multiple source files. The new -gen-interfaces option instructs the compiler to generate and compile a Fortran module source with an explicit interface for all global procedures not in a module. The names of the generated files are based on the procedure name with a suffix of "_mod" and the file type .f90 and .mod. The generated interface includes name, type and rank of each dummy argument. It does not include other attributes such as INTENT and OPTIONAL that may have been specified in the procedure.

The new -warn interfaces option instructs the compiler to look for a generated module of the appropriate name when it sees a reference to a procedure lacking an explicit interface. If it finds one, it behaves as if a USE of that module had been specified for the program unit being compiled. If the call is inconsistent with the implicitly imported interface, the compiler issues a diagnostic message as if the same interface had been explicitly specified.

For best results, specify both -gen-interfaces and -warn interfaces. The compiler will ensure that all calls within a source file are properly verified. Calls to procedures in separately compiled source files will be verified if the defining source is compiled first.

Choice of Comment Style in fpp-Preprocessed Source

The -allow [no]fpp_comments switch has been introduced in order to allow the user to control how the fpp preprocessor treats Fortran end-of-line comments in preprocessor directive lines. Consider for example the following source line:

#define MAX_ELEMENTS 100 ! Maximum number of elements

How is the preprocessor supposed to treat the text "! Maximum number of elements"? Is it treated as a Fortran comment and therefore ignored, or is it part of the value for the MAX_ELEMENTS definition? Given that the functionality of fpp is essentially that of the C preprocessor cpp, and on many platforms, a cpp itself is used to provide Fortran preprocessing, to cpp, this would just be text that is part of the value being defined..

The Intel Fortran Compiler default, specified by -allow fpp_comments, is to recognize Fortran-style end-of-line comments on preprocessor lines. Therefore, by default, the line above would define MAX_ELEMENTS to be simply "100". If -allow nofpp_comments is specified, then Fortran end-of-line comment conventions are not used and "!" has no special meaning. An example of where you may want to use -allow nofpp_comments is to have a Fortran directive as a define value, for example:

#define dline(routname) !dec$ attributes alias:"__routname":: routname

Please note that there is not widespread agreement among Fortran vendors for this behavior.

Debug Information for PARAMETER Constants

The compiler is now able to generate debug information for numeric (scalar and array) PARAMETER constants, so that the values of these may be examined while debugging. Character and derived type constants are not supported in this version. The new -debug-parameters option controls this feature. If -debug-parameters is specified with no other keyword, the default is used, meaning that only those PARAMETER constants used in the source will be visible in the debugger. -debug-parameters all specifies that all declared PARAMETER constants shall be visible - this can significantly increase code size. -debug-parameters none disables generation of debug information for PARAMETER constants - this is the default if -debug-parameters is not specified.

Additional Optimization at -O2

When the default optimization level (-O2) is specified, the compiler now performs certain interprocedural and loop optimizations that were formerly performed only when -ip or -O3 were specified. We invite your comments as to the effect of this change on performance (both run-time and compile-time) as well as application results.

Optimization Improvements

The compiler is now able to vectorize loops made parallel through the use of OpenMP directives. Additional optimization improvements have been made that could lead to improved performance. Examples are loop blocking for better cache utilization; runtime dependency checking and loop versioning.

Loop Optimization Reports Improved

A number of improvements have been made to the optimization reports. For example, loop optimization reports, selected with -opt_report_phase hlo, now have more detailed line number information for unrolled loops, and identifiers for multiple versions of loops.

Multiple Object Default for -ipo

When - ipo is specified, the compiler now, by default, can produce multiple intermediate object files for input to the linker, rather than a single file. This can improve performance of the link phase. You can adjust this behavior by specifying a value for -ipo. Please refer to the Compiler Options Guide for more information.

Software-based Speculative Pre-Computation (IA-32 Only)

The new -ssp option enables Software-based Speculative Pre-computation (SSP) optimization, which is also called Helper-Threading optimization. This feature provides a way to dynamically prefetch data cache blocks to reduce the impact of memory latency. It exploits the properties of source code constructs (such as delinquent loads and pointer-chasing loops) in applications.

SSP directly executes a subset of the original program instructions, called a slice, on separate threads alongside the main computation thread, in order to compute future memory accesses accurately. The helper threads run ahead of the main thread and trigger cache misses earlier on its behalf, thereby hiding the memory latency.

To be effective, SSP techniques require construction of efficient helper threads and processor-level support, such as Hyper-Threading Technology (HT Technology) support, which allows multiple threads to run concurrently with a shared cache. These techniques include:

The results of SSP vary because each program has a different profile and different opportunities for SSP optimizations. For guidelines to help you determine if you can benefit by using SSP, see the topic "Software-based Speculative Precomputation (IA-32)" in the Profile-Guided Optimization section of your Optimizing Applications guide.

CALL of Function with Implicit Interface No Longer Allowed

In previous versions of the compiler, a CALL to a name given a type, thus making it a function with an implicit interface, was allowed in some cases. For example:

REAL F
CALL F(X)

This is not allowed by the Fortran language, and, depending on the platform and the actual or declared datatype of the function, could cause corruption of the floating point stack. As of version 9.0, attempting to CALL a typed identifier will give an error. If your application took advantage of this feature, replace the CALL with a function reference assigned to a variable. Note that a CALL to a function with an explicit interface has not been allowed in the past - that behavior has not changed.

Mismatch of Argument KIND Now Diagnosed

In previous versions, the compiler would silently allow a mismatch of KIND for an argument when calling a routine that had an explicit interface. For example, consider the following:

interface
  subroutine sub (x)
  real(8) :: x
  end subroutine sub
end interface
...
call sub(3.0)

The 3.0 in the call is of type "default real", or real(4). Previously, the compiler would accept this and convert the value on the call and return. Now, the compiler will give an error such as:

Error: The type of the actual argument differs from the type of the dummy argument. [3.0]
call sub(3.0)
---------^

This issue also arises for mismatches of integer and logical kinds. If your application took advantage of the earlier compiler's failure to diagnose this error, you can correct the problem by making sure that the argument is the correct kind. For constants, you can add the kind specifier suffix, such as 3.0_8 or 50_2. For constants or expressions, use the COMPLEX, INT, LOGICAL or COMPLEX intrinsics with the second KIND argument to convert the argument to the proper kind. For variables, you will need to correct the declaration of the variable to make sure that it matches the expected kind. In some cases, the TRANSFER intrinsic may be useful for this purpose.

Change in Behavior of FLUSH Library Routine

In versions 8.0 and 8.1 of the Intel Fortran Compiler, the FLUSH library routine from module IFPORT waited until the data was written to disk before returning control to the application. In version 9.0, FLUSH empties the internal buffers and waits for the operating system to acknowledge receipt of the data, but it does not wait for the disk to be updated, thus improving performance. If your application requires that the data be written to the physical disk file, use the COMMITQQ library routine instead.

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 which use direct-access I/O to access records in order, but may harm performance for applications which 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.

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 3.2 or earlier, 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 version is 3.2 or lower. 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

GCC_EXEC_PREFIX Environment Variable

If you specify a value for the GCC_EXEC_PREFIX environment variable, the compiler uses the value as a prefix to the following:

If the value specified is a directory, the compiler treats it as a path. For example, if GCC_EXEC_PREFIX=/my/path/ then gcc tool ld becomes /my/path/ld and the compiler treats it as a path to the tool. Note that the tool must exist in the specified path or the path is ignored and the compiler searches for the tool in default directories.

Library search paths are modified to include the specified prefix for crt*.o objects. The prefix is also used as an -L search path.

This feature is useful if you want to use an alternate set of gcc tools and libraries.

Note that if –Ldir or –Bdir is specified on the command line, they take precedence for library search paths over the environment variable.

The order of precedence is as follows (highest to lowest):

Predefined Preprocessor Symbol for Intel EM64T

The compiler for Intel EM64T now defines the preprocessor symbol __X86_64__ for use in conditionalizing applications for this platform.

Small, Medium and Large Memory Models on Intel EM64T

Applications built to take advantage of Intel EM64T 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.

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

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:

Change History

This section provides a summary of behavior changes in updates to 9.0.

9.0.024
9.0.025
9.0.028
 

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 from the Intel Pentium® family, (for example, Pentium® 4, Pentium® D, Celeron® or Intel® Xeon®), or processors from other manufacturers supporting the same instruction set, running a 32-bit operating system ("Linux x86").
EM64T
Intel® EM64T (Intel® Extended Memory 64 Technology) refers to systems based on IA-32 processors which have 64-bit architectural extensions, running a 64-bit operating system ("Linux x86_64") . Systems based on the AMD* Athlon64* and Opteron* processors running a 64-bit operating system are also supported by Intel compilers for EM64T-based applications.
Itanium®
Refers to systems based on the Intel Itanium® 2 processor running a 64-bit operating system.

Native and Cross-Platform Development

The term "native" refers to building an application on a platform type the same as the one on which it will be run, 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® EM64T-based Host
Supported targets: IA-32 and Intel® EM64T
Intel® Itanium®-based Host
Supported target: Intel® Itanium®

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

Requirements to develop IA-32 applications

Requirements to Develop Applications for Systems with Intel EM64T or 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: 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 EM64T 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 Itanium-based Applications

We recommend using binutils 2.14 or later, especially if using shared libraries as there are known issues with binutils 2.11.

Notes:

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:

Known Issues

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.

-debug parameters Not Yet Functional

The -debug parameters switch, described in the documentation, is not functional in this release. It will be made available in a future update. We apologize for the inconvenience.

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 Itanium Processor Family 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 Itanium-based Linux Systems

On Itanium-based 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 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.

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

Compilation using -ax{W|N|B|P} 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.

Technical Support

Your feedback is very important to us. To receive technical support for the tools provided in this product and technical information including FAQ's and product updates, you need to be registered for an IntelŪ Premier Support account on our secure web site, https://premier.intel.com. Please register at https://registrationcenter.intel.com/ .

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

For information about the Intel Fortran Compiler's Users Forums, FAQ's, tips and tricks, and other support information, please visit: http://support.intel.com/support/performancetools/fortran/linux/. For general support information please visit http://www.intel.com/software/products/support/.

Submitting Issues

Steps to submit an issue:

  1. Go to https://premier.intel.com/.
  2. Log in to the site. Note that your username and password are case-sensitive.
  3. Click on the "Go" button next to the "Product" drop-down list.
  4. Click on the "Submit Issue" link in the left navigation bar.
  5. Choose "Development Environment (tools,SDV,EAP)" from the "Product Type" drop-down list.
  6. If this is a software or license-related issue, choose "Intel(R) Fortran Compiler for Linux*" from the "Product Name" drop-down list.
  7. Enter your question and complete the fields in the windows that follow to successfully submit the issue.

Guidelines for problem report or product suggestion:

  1. Describe your difficulty or suggestion.
    For problem reports please be as specific as possible, so that we may reproduce the problem. For compiler problem reports, please include the compiler options and a small test case if possible.
  2. Describe your system configuration information.
    Get the version of glibc and kernel with following commands:
        > uname -a
        > rpm -qa | grep glibc
    If you don't have rpm installed, use the command below:
        > ls /lib/libc*
    and copy the information into the corresponding Intel® Premier Support fields.

    Get the Intel Fortran Compiler's Package ID with the following command:
        > ifort -what
    and copy the "Package ID" (e.g. l_fc_c_9.0.xxx) from the output into the corresponding Intel® Premier Support field. Please include any other specific information that may be relevant to helping us to reproduce and address your concern.

  3. If you were not able to install the compiler or cannot get the Package ID, enter the filename you downloaded as the package ID.

Resolved Issues

Please review <package ID>_README (e.g. l_fc_c_9.0.xxx_README), available for download from IntelŪ Premier Support, https://premier.intel.com, to see which issues have been resolved in the latest version of the compiler.

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 . A training tutorial Enhancing Performance with IntelŪ Compilers is also available from links in the documentation index. 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: http://developer.intel.com/software/products/compilers/flin/docs/manuals.htm

Additional Information

Related Products and Services

Information on Intel software development products is available at http://www.intel.com/software/products.

Some of the related products include:

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.

BunnyPeople, Celeron, Centrino, Centrino logo, Chips, Dialogic, EtherExpress, ETOX, FlashFile, i386, i486, i960, iCOMP, InstantIP, Intel, Intel logo, Intel386, Intel486, Intel740, IntelDX2, IntelDX4, IntelSX2, Intel Inside, Intel Inside logo, Intel NetBurst, Intel NetMerge, Intel NetStructure, Intel SingleDriver, Intel SpeedStep, Intel StrataFlash, Intel Viiv, Intel XScale, IPLink, Itanium, MCS, MMX, MMX logo, Optimizer logo, OverDrive, Paragon, PDCharm, Pentium, Pentium II Xeon, Pentium III Xeon, Performance at Your Command, skoool, Sound Mark, The Computer Inside., The Journey Inside, VTune, Xeon, and Xircom are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.

Intel's trademarks may be used publicly with permission only from Intel. Fair use of Intel's trademarks in advertising and promotion of Intel products requires proper acknowledgement.

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

Copyright © 2006, Intel Corporation.