This product provides tools for Linux* 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.
This product is available in two editions.
The Standard Edition contains the following components:
<install-dir>/doc/Doc_Index.htm The Professional Edition includes all of the Standard Edition and adds the Intel® Math Kernel Library, which contains highly optimized, extensively threaded, mathematical functions for engineering, scientific, and financial applications that require maximum performance..
Note: The installation path for the Intel® Fortran
Compiler is /opt/intel/fc/10.1.xxx , where xxx represents
a 3-digit update number. The term <install-dir> is used
in throughout this document to refer to the default installation path.
Installation of the Intel® Math Kernel Library is separate from that of the compiler. Please see the Intel® Math Kernel Library Installation Guide for details.
To receive technical support and product updates for the tools provided in this product you need to register. For how to register, please see Technical Support section below.
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 10.1.
The following section discusses new features and changes in the Intel Fortran Compiler since version 10.0. Version numbers may not represent a released update - the indicated and later versions have these changes. Please see the separate release notes for the Intel Debugger.
-no-prof-gen and -no-prof-use documented-prof-gen-sampling and -ssp will be
removed in a future release-prof-hotness-threshold added-[no-]opt-prefetch-excl-hint added
-opt-malloc-options-mia32 added-opt-jump-tables added-[no-]opt-loadpair added-opt-malloc-options=4 value added-[no-]opt-mod-versioning added-[no-]opt-prefetch-initial-values added-[no-]opt-prefetch-next-iteration added-[no-]unroll-aggressive now available on IA-64 architecture The following is a listing of command line options that are new or have changed since the initial version 9.1 release. Please refer to the compiler documentation for more information on these options.
-assume [no]old_boz -assume noold_boz) -assume [no]old_unit_star -assume old_unit_star) -assume protect_parensREAL and COMPLEX expression
evaluations by not reassociating operations. (Default: off) -assume [no]realloc_lhs -assume [no]std_mod_proc_name -axS-check [no]pointerALLOCATABLE variables. (Default: off)-cxxlib-nostd-diag-<type> <diag-list>-diag-dump-diag-enable sv[1|2|3] -diag-enable sv-include-diag-file[=file] -diag-file-append[=file]-[no-]diag-id-numbers -f[no-]align-functions[=n]-fast-f[no-]instrument-functions-f[no]-keep-static-consts-[no-]fp-port-fp:precise. (IA-32 and Intel® 64
architecture only, default: off) -fp-speculation=<mode>-[no-]func-groups -gdwarf-2-heap-arrays[-]-help [category]-ipo-jobs<n>-march=<cpu> -mia32-msse[n] -msse2 for
Intel® 64 architecture) -mtune=core2-openmp-lib typelegacy) -opt-jump-tables=default|never|large|<max-entries> default) -[no-]opt-loadpair-opt-malloc-options=n malloc(). (Default: 0) -[no-]opt-mod-versioning-[no-]opt-multi-version-aggressive-[no-]opt-prefetch-initial-values-[no-]opt-prefetch-issue-excl-hint-[no-]opt-prefetch-next-iteration-opt-ra-region-strategy [=keyword]default) -opt-streaming-stores keywordauto) -[no-]par-runtime-control-no-prof-gen-prof-hotness-threshold=n-no-prof-use-par-schedule-<keyword>[=n]-[no-]prefetch-xT. (IA-32 and IA-64 architectures
only, default: off) -save-temps[-]-shared-intellibguide)-shared-libgcc-static-intellibguide) -static-libgcc-std or -stand-std03 or -stand f03 -tcheck [<mode>]-tcollect-[no-]unroll-aggressive-[no-]vec-guard-write-xO-xSFor 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 section Compiler Options > Deprecated and Removed Compiler Options in the on-disk documentation.
-opt-malloc-options=4In version 10.1.008 the -opt-malloc-options compiler option
was added. This specifies options to be used for calls to malloc() by
means of a call to mallopt(). In version 10.1.008 the values
0 through 3 were defined. Version 10.1.009 adds a new value 4. The meanings
of these values are shown below. For more information, please refer to the
documentation for the C library routine mallopt().
-opt-jump-tables=default|never|large|<max-entries> This option allows user control for the size of jump tables generated by the compiler. Jump tables are used for switch statements. Switch statements are either implemented as jump tables or a series of if-then-else constructs. The method used typically have an impact on performance of the generated code, and on the size of the data area. Using jump tables will favor speed over size.
This option allows user control for the size of jump tables generated by
the compiler. Jump tables are used for SELECT CASE constructs,
which are implemented either as jump tables or a series of if-then-else constructs.
The method used typically has an impact on performance of the generated code,
and on the size of the data area. Using jump tables will favor speed over
size.
The available values are:
defaultnever large max-entries>-fast Changed The -fast option is a shorter way of specifying a set of options
that generally improve run-time performance. As documented, the set
of options may change over time. In version 10.0, -fast sets -xT,
whereas in earlier versions it set -xP. If this change is not
appropriate for you, you must specify the individual options you want
instead of using -fast. Please see the Compiler Options section
of the on-disk documentation for further information.
-stand ChangedIn version 10.0, the meaning of the -stand option, when specified
without a following keyword, is changed to mean -stand f03,
or checking for conformance to Fortran 2003. You can select checking
against Fortran 90 or Fortran 95 by specifying -stand f90 or -stand
f95. -std is an alternate spelling of -stand.
Note that the Intel® Fortran Language Reference still highlights
Fortran 2003 features as extensions to Fortran 95.
-xW Enabled by Default on Intel® 64 Architecture Systems On Intel® 64 architecture systems, -xW is enabled by default;
this has the effect of enabling vectorization and you may see vectorization
report messages displayed where you did not when using previous releases.
To disable the vectorization report messages, use -diag-disable vec.
You may still specify alternate options such as -xP or -axT.
-prof-hotness-threshold=n optionThis option lets you set the hotness threshold for function grouping and function ordering. The "hotness threshold" is the percentage of functions in the application that should be placed in the application's hot region. The hot region is the most frequently executed part of the application. By grouping these functions together into one hot region, they have a greater probability of remaining resident in the instruction cache. This can enhance the application's performance.
The argument n specifies the hotness threshold. n is
a percentage having a value between 0 and 100 inclusive. If you specify
0, there will be no hotness threshold setting in effect for function
grouping and function ordering. The default value is 10.
For this option to take effect, you must specify option -prof-use and
either -prof-func-groups or -prof-func-order
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.
As of version 10.1 you can specify that OpenMP libraries compatible with
gcc* 4.2 (or later) be used by specifying -openmp-lib compat.
This may be desirable if your application contains some source modules built
with gcc or g++ and your application uses OpenMP. The default is -openmp-lib
legacy which uses the Intel-supplied OpenMP libraries that are not
link-compatible with gcc OpenMP libraries.
Applications using the compat libraries must be built with
version 10.0 or later of the Intel C++ and/or Fortran compilers with -openmp-lib
compat specified.
In a future release, the default will change to -openmp-lib compat,
and in a release after that, the legacy libraries will be removed.
Fortran 2003 defines behaviors for language features that were either extensions to previous standards or left unspecified in earlier standards. While version 10.1 of the Intel Fortran Compiler does not yet support all of Fortran 2003, the compiler now selects the Fortran 2003 behavior in some cases where earlier compiler versions chose a different behavior. In some other cases, the compiler defaults have not yet changed. These are described below.
In Fortran 95, assignment to an allocatable array required that the left
and right hand side of the assignment match in shape and length parameters.
In Fortran 2003, if the shapes and length parameters do not match,
the variable being assigned to is deallocated and then reallocated
to shape and length parameters matching the expression being assigned.
As of version 10.1, the compiler can perform the extra actions specified
by Fortran 2003, but as these can significantly hurt performance, the
default is to retain the Fortran 95 behavior requiring that the shapes and
length parameters match. If you want the Fortran 2003 behavior that
deallocates and reallocates the variable on a shape mismatch, specify -assume
realloc_lhs
In Fortran 95, binary, octal and hexadecimal constants ("BOZ constants") were allowed in DATA statements only and were restricted to initializing scalar integer variables. As an extension to Fortran 95, the Intel Fortran Compiler allowed BOZ constants in any context, with the type interpretation determined by the context. Fortran 2003 expands the use of BOZ constants permitting them to initialize any numeric type and in arguments to the INT, REAL, DBLE and CMPLX intrinsics.
The Fortran 2003 semantics for use of BOZ constants match the previous extended implementation of Intel Fortran except for the case of a BOZ constant as an argument to INT, REAL, DBLE and CMPLX. Fortran 2003 specifies that in these contexts a BOZ constant is interpreted as a binary value which is interpreted directly as the data type returned by the intrinsic, whereas the previous Intel Fortran interpretation was to treat the BOZ constant as a signed integer value which was then converted.
For example:
print *, real(Z'40490FDB')
with the old behavior (-assume old_boz) prints 1.0785300E+09
and with the new behavior (-assume noold_boz) prints 3.141593.
As of version 10.0, the default behavior for Intel Fortran is that of Fortran
2003, to transfer the binary value without conversion. If your application
needs the old behavior, compile with the option -assume old_boz.
In the Intel Fortran Compiler, I/O unit * and the implied units used by
the ACCEPT, PRINT and TYPE statements,
are by default associated with unit numbers distinct from those that could
be specified in an OPEN statement, such as unit 5 or 6. Fortran
2003 requires that the programmer be able to OPEN these default units, which
is incompatible with the current Intel Fortran behavior.
In version 10.0, the -assume [no]old_unit_star compile command
option has been added to control this behavior. The default, -assume
old_unit_star,
retains the current and past behavior with unit * being distinct from
units 5 and 6. If you want to use the Fortran 2003 behavior, or if
you will be using the Fortran 2003 intrinsic module ISO_FORTRAN_ENV and
its defined constants INPUT_UNIT and OUTPUT_UNIT,
specify -assume noold_unit_star to have unit * (and ACCEPT, PRINT and TYPE)
use units 5 (input) and 6 (output).
The default for this behavior may change in a future release.
RECL= unit for unformatted filesIn version 10.0, as in versions 8.x and 9.x of Intel Fortran, when opening
a file for unformatted I/O, the value specified for the RECL= keyword
in OPEN is in four-byte units, the size of a default integer.
Previous Fortran standards have said that the RECL= unit was "implementation-dependent",
but Fortran 2003 "recommends" that it be single bytes. To specify
that the RECL= unit for unformatted I/O be bytes, use the existing
compiler option -assume byterecl. You must also use this option
if your application uses the FILE_STORAGE_SIZE named constant
from the intrinsic module ISO_FORTRAN_ENV.
.XOR. Intrinsic OperatorThe Intel Fortran compiler defines, as an extension, an intrinsic operator .XOR..
This can cause conflicts with a user-defined operator of the same name
as the intrinsic operator has a different precedence than user-defined
operators. If you are definining your own operator .XOR. you
can specify -assume no_old_xor to
disable the compiler's definition of .XOR. as an intrinsic operator.
The Intel Fortran compiler constructs the global name for module procedures
and variables by joining the module name with the procedure or variable
name, separated with the string "_mp_", and then applying
the standard name decoration rules. For example, a procedure SUB in
module MYMOD would have a global name of MYMOD_mp_SUB.
This method could conflict
with a user procedure whose name contains the string _mp_. If
your application has this conflict, specify the option -assume noold_mod_proc_name which
will switch the case of the separator to be the opposite of the default
name case. You must specify the same option for the entire application
so that the names are consistent.
As of version 10.1, the compiler supports the Fortran 2003 Stream I/O feature,
which provides the ability to read and write files as a stream of bytes.
To enable stream access, open the file specifying ACCESS='STREAM'.
The READ and WRITE statements
support a POS= keyword to specify file position. For more information,
please refer to the Intel Fortran Compiler Language Reference.
Intel Fortran has supported, as an extension, the RECORDTYPE values STREAM, STREAM_CR and STREAM_LF in the OPEN statement. In previous versions, neither the documentation nor the implementation were correct and the two were inconsistent. The old behavior was as follows:
Furthermore, if CARRIAGECONTROL='NONE' was specified, the behavior changed.
In version 10.1, the behavior changes as follows:
A new option is defined as follows:
CARRIAGECONTROL no longer affects the behavior of RECORDTYPE.
On Windows, the default formatted record delimiter is CR-LF; on Linux and Mac OS* X it is LF. With these changes, it is now possible to specify a particular delimiter type on all three operating systems in a consistent fashion.
If you wish to change the run-time behavior of an application without editing
the source, a new environment variable FOR_FMT_TERMINATOR can
be defined. The value of this environment variable takes the form:
mode[:ulist][;mode[:ulist]...]
where mode is one of CR, LF or CRLF and
ulist is an optional range of unit numbers to which that mode applies, for
example, 2,17-20, 91
The following features from the Fortran 2003 standard have been added since the initial release of version 9.1. Some of these features first appeared in updates to version 9.1. For additional details, please see the Intel® Fortran Language Reference.
/assume:byterecl and /assume:noold_unit_star for
correct values) COMMAND_ARGUMENT_COUNT intrinsic procedureFor details on the following new language features, please see the Intel® Fortran Language Reference
Two new environment variables are available to change the run-time behavior
of applications: FORT_FMT_RECL and FORT_UFMT_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_UFMT_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.
This version features a complete redesign of the optimizer that integrates
parallelization (all architectures) and vectorization
(IA-32 and Intel® 64 architectures) at O2 and O3 optimization
levels with memory and loop optimizations.
Performance can be substantially improved by:
Loop Transformation (HLO) Optimization reports tell you why the compiler was unable to apply loop interchange transformations on a set of loops and suggests loop interchange if the reported bottlenecks can be removed by source changes. These reports have been enhanced to provide more detailed information and to be easier to understand.
Static Verifier is a new compiler feature which performs static analysis of a program across multiple source files. It can detect different kinds of defects and doubtful or inconsistent uses of language features in user code and report them according to their severity level. Static Verifier understands C/C++ and Fortran code and can also perform analysis of OpenMP directives.
In this release, when Static Verifier is enabled the linker is not invoked so an executable or static/dynamic link library is not produced, object files that were produced as a result of invocation of Static Verifier are not valid and should not be used for generating of real executable or static/dynamic link libraries. The current usage model is that Static Verifier is added as an alternate build option to produce a diagnostic report.
Static Verifier cannot be used in conjunction with cross-file interprocedural optimization (/Qipo).
For more information, please refer to the section on Building Applications > Error Handling > Handling Compile Time Errors > using Static Verification Diagnostic Options in the on-disk documentation.
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:
This section lists planned behavior changes in a future major release of the Intel® C++ Compiler
-mtune itanium option will
be deprecated. This option specified optimization tuning to favor
the original Intel® Itanium® processor. In the future,
this option will cause a diagnostic to be issued and it will be ignored
- the default tuning will favor the Intel® Itanium® 2
processor.-xW. Intel recommends, if you wish
to ensure continued generated code compatibility with earlier processors,
that you add the -mia32 option to your build scripts
now. -prof-gen-sampling and -ssp options
will be removed, along with the profrun and pronto_tool executables.
These options and tools relate to hardware sampling-based profile-guided
optimization, which will no longer be supported. Instrumented profile-guded
optimization will continue to be supported. 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 that will run on the same platform that it was built on, for example, building on IA-32 architecture to run on IA-32 architecture. 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 architecture to run on IA-64 architecture. 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: Intel® Cluster OpenMP* has different system requirements from that of the compilers. Please refer to the Intel Cluster OpenMP documentation for further details.
compat-libstdc++ providing libstdc++.so.5 compat-libstdc++ providing libstdc++.so.5ia32-libs) compat-libstdc++ providing libstdc++.so.5
The Intel compilers are tested with a number of different Linux distributions, with different versions of gcc. 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. For best results, use only the gcc versions as supplied with distributions listed above.
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/10.1.xxx
(for IA-32 and IA-64)
/opt/intel/fce/10.1.xxx (for Intel® 64)
/opt/intel/idb/10.1.xxx
(for IA-32 and IA-64)
/opt/intel/idbe/10.1.xxx (for Intel® 64)
If you specify the NAME= keyword for the BIND(C) attribute, the compiler should apply whatever name decoration rules, such as leading underscore, would be used by the C compiler for the same name. Some previous versions of the Intel Fortran Compiler did not apply this decoration, but the correct behavior was restored as of the January 2008 update. If you had added the decoration to the value of NAME= you will now need to remove it.
Programs compiled with the Intel Compiler version 9.0 using the -openmp switch
may not run after installing the Intel Compiler version 10.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 10.1 and the loader error message should disappear.
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.
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.
It is noted that Linux thread local storage (TLS) is not fully supported
by the default installations of /usr/lib/libpthread.a and /usr/lib/libc.a on
certain versions of Linux (Red Hat Enterprise Linux 4 and earlier are
known examples). When using the Linux TLS mechanism and linking with -static,
the inclusion of -openmp or calls to libpthread may
trigger a runtime failure when trying to access thread local storage.
To fix this problem, install the nptl-devel.rpm package
(included on the Linux installation CD) and compile with -L/usr/lib/nptl.
THREADPRIVATE with
an OpenMP directive, the common block must have the same length in
all the source files in which it is declared. gprel relocation Error Messages on IA-64
Architecture Linux SystemsOn IA-64 architecture 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 IA-64 architecture systems As of version 9.0, the compiler driver no longer passes the -relax switch
to the linker on IA-64 architecture 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 10When 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.
(-ax*)Compilation using -ax[code] results in two copies of generated
code for each function. One for 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 architecture
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.
Older versions of the GNU Assembler may not be able to process assembly
code generated by compiling with the -[a]xP, T or S options.
Use binutils version 2.17.50.0.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.
In some cases, enabling run-time checks using the -check or -C option may
cause the compiler to issue diagnostics for the requested condition
at compile-time, if it can be diagnosed then. For example, an array
bounds violation with a constant subscript may result in a compile-time
error if -check bounds or -CB is specified.
If you did not register your compiler during installation, please do so at the Intel® Software Development Products Registration Center. Registration entitles you to free technical support, product updates and upgrades for the duration of the support term.
For information about how to find Technical Support, Product Updates, Users Forums, FAQs, tips and tricks, and other support information, please visit: http://www.intel.com/software/products/support/flin.
Note: If your distributor provides technical support for this product, please contact them for support rather than Intel.
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.
Note: Please notify your support representative prior to submitting source code where access needs to be restricted to certain countries to determine if this request can be accommodated.
> 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 -V
and copy the "Package ID" (e.g. l_fc_x_10.1.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_x_10.1.xxx_README),
available for download from Intel® Software
Development Products Registration Center Product Downloads, to see which
issues have been resolved in the latest version of the compiler.
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® Software Development Products Registration Center Product Downloads. Select your product and in the version dropdown, select CESR. CESR is unsupported and should be considered experimental, but we welcome your feedback on it through Intel® Premier Support. CESR requires prior installation of Python* 2.2 or newer.
You can view the Intel compiler and related HTML-based documentation with your Web browser. You should use a Web browser that supports JavaScript (such as Firefox*), so it can which provide full navigation, search, index look-up, and hyperlink capabilities amongst the online help files.
The documentation is installed in the <install-dir>/doc directory.
An HTML index document can be found at <install-dir>/doc/Doc_Index.htm
. The Intel® Debugger Manual
is provided in HTML form in the Intel® Debugger doc directory.
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(R) 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. UNLESS OTHERWISE AGREED IN WRITING BY INTEL, THE INTEL PRODUCTS ARE NOT DESIGNED NOR INTENDED FOR ANY APPLICATION IN WHICH THE FAILURE OF THE INTEL PRODUCT COULD CREATE A SITUATION WHERE PERSONAL INJURY OR DEATH MAY OCCUR.
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 information here is subject to change without notice. Do not finalize a design with this information.
The products described in this document may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request.
Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing your product order.
Copies of documents which have an order number and are referenced in this document, or other Intel literature, may be obtained by calling 1-800-548-4725, or by visiting Intel's Web Site.
Celeron, Centrino, Intel, Intel logo, Intel386, Intel486, Intel Core, Itanium, MMX, Pentium, VTune, and Xeon are trademarks of Intel Corporation in the U.S. and other countries.
* Other names and brands may be claimed as the property of others.
Copyright (C) 2009, Intel Corporation. All Rights Reserved.