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/ .
The IntelŪ Fortran compiler for IA-32 based applications contains the following components:
<install-dir>/doc/doc_index.htm
<install-dir>/doc/doc_index.htm
The IntelŪ Fortran compiler for Itanium-based applications contains the following components:
<install-dir>/doc/doc_index.htm
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".
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.
Some compiler options are only available on certain systems, as indicated by these labels:
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.
The following features from the Fortran 2003 standard are now supported by the Intel Fortran Compiler. These features are described in Language Reference Manual and are not further discussed here. Additional Fortran 2003 features, implemented after the initial 9.0 release, are described later in these Release Notes.
The following is a list of additional new and changed language features. Please see the Intel Fortran Language Reference for more information.
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.
WORKSHARE Directive SupportedThe OpenMP* 2.0 WORKSHARE directive is now supported.
The maximum nesting level for IF and DO constructs (combined) has been increased from 128 to 256.
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.
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.
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.
-O2When 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.
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.
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.
-ipoWhen - 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.
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.
-xP and -axP Code Generation Switches The -xP and -axP switches specify generation of
specialized code for Intel processors supporting the Streaming SIMD Extensions
3 (SSE3), including the Intel® Core™ processors.
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.
KIND Now DiagnosedIn 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.
In earlier versions of the Intel Fortran Compiler, if a specific routine in a generic interface had a dummy argument declared as an interface to a subroutine, for example:
interface mygeneric
subroutine specific1 (arg1, f)
real(4), intent(in) :: arg1
interface
subroutine f (i)
integer, intent(in) :: i
end subroutine f
end interface
end subroutine specific1
end interface
the compiler would allow an actual argument declared as EXTERNAL to
match the subroutine dummy argument. Interpretation 00101 to Fortran 95 specifies
that this is incorrect behavior, and that EXTERNAL actual arguments
do not match procedure arguments with an explicit interface. The compiler
no longer matches such arguments and may give an error stating that no specific
procedure was found for the generic reference.
The solution to this is to remove the EXTERNAL declaration
and replace it with an explicit interface. This can be an INTERFACE block
or it can be a module procedure.
FLUSH Library RoutineIn 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 StatusA 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.
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.
As of version 9.0.032, 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.
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 VariableIf you specify a value for the GCC_EXEC_PREFIX environment
variable, the compiler uses the value as a prefix to the following:
ld and as 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):
-Ldir -Bdir GCC_EXEC_PREFIX environment variable The compiler for Intel EM64T now defines the preprocessor symbol __X86_64__ for
use in conditionalizing applications for this platform.
Applications built to take advantage of Intel EM64T can be built with one of three memory models:
-mcmodel=medium)-mcmodel=large)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 CodeIf 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 EM64TIn 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.
In the current version, 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.
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.)
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.
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.
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:
FROMTOFROM, 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 an variable
to a larger size without copying the data twice.
The Intel Visual 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:
This section provides a summary of behavior changes in updates to 9.0.
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.
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).
Note: Development for a target different from the host may require optional library components to be installed from your Linux Distribution.
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.
We recommend using binutils 2.14 or later, especially if using shared libraries as there are known issues with binutils 2.11.
Notes:
-O3, -ipo and -openmp,
may require substantially larger amounts of RAM.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.0
(for IA-32 and Itanium)
/opt/intel/fce/9.0
(for Intel EM64T)
/opt/intel/idb/9.0
(for IA-32 and Itanium)
/opt/intel/idbe/9.0 (for Intel EM64T)
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.
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.
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.
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.
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 SystemsOn 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 supportedThe -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.
(-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.
-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.
-xP generated codeOlder 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.
idb with Extended Debug InformationIf 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 SupportedThe -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.
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/.
Go" button next to the "Product"
drop-down list.
Submit Issue" link in the left navigation bar.
Development Environment (tools,SDV,EAP)" from the "Product
Type" drop-down list.
Intel(R) Fortran
Compiler for Linux*" from the "Product Name"
drop-down list.
> uname -a > rpm -qa | grep glibcrpm installed, use the command below: > ls /lib/libc*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.
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.
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.
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.
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
Information on Intel software development products is available at http://www.intel.com/software/products.
Some of the related products include:
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.
*Other names and brands may be claimed as the property of others.
Copyright © 2006, Intel Corporation.