Additional information on the Intel® Software Development Products is available at http://www.intel.com/software/products/ .
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:
These additional components of the Professional Edition are installed separately and have their own Release Notes.
Note: The installation path for the Intel® C++
Compiler is /opt/intel/cc/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.
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.
The Intel® C++ Compiler for Linux includes compiler integrations for use with either Eclipse*, version 3.3.2, and the C/C++ Development Tools* (CDT), version 4.0.2 or Eclipse*, version 3.2.x, and the C/C++ Development Tools* (CDT), version 3.1.x.
Eclipse is an open source software development project dedicated to providing a robust, full-featured, commercial-quality, industry platform for the development of highly integrated tools. It is an extensible, open source Integrated Development Environment (IDE).
The CDT (C/C++ Development Tools) project is dedicated to providing a fully functional C/C++ IDE for the Eclipse platform. CDT is layered on Eclipse, and provides a C/C++ development environment perspective.
The Intel C++ Compiler integration with the Eclipse/CDT IDE lets you develop, build, and run your Intel C/C++ projects in a visual, interactive environment.
See Also
The following section discusses new features and changes in the Intel C++ 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 now supported on IA-64 architecture-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.
-alias-const[-]-axS-[no-]check-uninit-cxxlib-nostd-diag-<type> <diag-list>-diag-dump-diag-enable port-win -diag-enable sv[1|2|3] -diag-enable sv-include-diag-file[=file] -diag-file-append[=file]-[no-]diag-id-numbers -dumpmachine-f[no-]align-functions[=n]-fargument-noalias-global-fast-f[no-]exceptions-f[no-]instrument-functions-f[no-]jump-tables -f[no]-keep-static-consts-fmudflap-[no-]fp-port-fp:precise. (IA-32
and Intel® 64 architecture only, default: off) -fp-speculation=<mode>-[no-]func-groups -gcc-sys-help [category]-[no-]inline-calloc calloc() as calls to malloc() and memset(). (Default: off) -ipo-jobs<n>-march=core2-mia32-msse[n] -msse2 for
Intel® 64 architecture) -mtune=core2-nostdinc++-openmp-lib typelegacy) -[no-]opt-class-analysis-opt-jump-tables=default|never|large|<max-entries>default) -[no-]opt-loadpair-[no-]opt-mod-versioning-opt-malloc-options=n malloc(). (Default:
0) -[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-par-schedule-<keyword>[[]n]-[no-]prefetch-O3 is in effect. Use on IA-32 architecture
requires specifying -xT. (IA-32 and IA-64 architectures only,
default: off) -no-prof-gen-prof-hotness-threshold=n-no-prof-use-save-temps[-]-shared-intellibguide)-shared-libgcc-static-intellibguide)-static-libgcc-tcheck [<mode>]-tcollect-trigraphs-[no-]unroll-aggressive-[no-]vec-guard-write-Weffc++-W[no-]missing-declarations-Wnon-virtual-dtor-Wreorder -W[no-]strict-prototypes-Wunused-variable-Wwrite-stringsconst char * is converted to (non-const)
char *. (Default: off) -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.
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.
-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 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.
-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
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.
This version features a complete new design of exception handling with simpler internal presentation to provide more opportunities for optimization. Improvements include:
"Mudflap" is a pointer user checking technology based on compile-time instrumentation. It adds protective code to a variety of potentially unsafe C/C++ constructs that detect actual erroneous uses at run time. The class of errors detected includes:
To enable "Mudflap" pointer use checking, specify the -fmudflap compiler
option and specify -lmudflap in the command which links the application.
C++ Class Hierarchy Analysis uses C++ class hierarchy information to provide information to the compiler so that it can resolve more virtual function targets at compile time thus improving performance.
The cpu_dispatch and cpu_specific keywords now
accept the cpuid code core_2_duo_ssse3 for
Intel® Core™2 processors and Intel® Xeon® processors
with Supplemental Streaming SIMD Extensions 3 (SSSE3), and the
code core_2_duo_sse4_1 for Intel® Core™2 processors
and Intel® Xeon® processors with Streaming SIMD Extensions
4.1 (SSE4.1)
This version features a complete redesign of the optimizer that integrates
parallelization (all architectures) and vectorization
(IA-32 and Intel® 64 architecture) 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.
new Expression with Parenthesized
TypeIn a new expression, a parenthesized type followed
immediately by an array index is not valid C++. For example:
int main()
{
char *p1 = new (char *)[20]; // array index is not allowed after ")"
return 0;
}
In previous versions, the Intel C++ compiler would accept this code and either interpret it as if the array index was part of the type being created:
new ((char*)[20])
or not:
(new (char *))[20]
depending upon the reference compiler and compatibility version target. The compiler has now been changed to always give an error if the compatibility version is gcc 3.4 or later. In gcc 3.3 and earlier compatibility modes the compiler assumes that the array index is part of the type (matching the gcc 3.3 behavior).
-std=c99 and -std=c89 When the -std=c99 or -std=c89 options
are used, the 10.1 compiler's behavior is now compatible with gcc
and the __STRICT_ANSI__ macro
is predefined. If your application compiles with errors and you
wish to use the previous version's behavior, add -U__STRICT_ANSI__ to
the command line.
The following functions are used in the algorithmic descriptions of the Advanced Encryption Standard (AES) instruction extensions supported by a future Intel processor. Applications using these intrinsics must ensure that they are running on a processor supporting the AES instructions.
Instruction:
AESDEC xmm1, xmm2/m128
Corresponding Intel® C/C++ Compiler Intrinsic:
__m128i _mm_aesdec_si128(__m128i v, __m128i rkey);
Description:
Perform one round of an AES decryption flow using the Equivalent
Inverse Cipher operating on a 128-bit data (state) from xmm1 with
a 128-bit round key from xmm2/m128.
Instruction:
AESDECLAST xmm1, xmm2/m128
Corresponding Intel® C/C++ Compiler Intrinsic:
__m128i _mm_aesdeclast_si128(__m128i v, __m128i rkey);
Description:
Perform the last round of an AES decryption flow using the Equivalent
Inverse Cipher operating on a 128-bit data (state) from xmm1 with
a 128-bit round key from xmm2/m128.
Instruction:
AESENC xmm1, xmm2/m128
Corresponding Intel® C/C++ Compiler Intrinsic:
__m128i _mm_aesenc_si128(__m128i v, __m128i rkey);
Description:
Perform one round of an AES encryption flow operating on a 128-bit
data (state) from xmm1 with a 128-bit round key from xmm2/m128.
Instruction:
AESENCLAST xmm1, xmm2/m128
Corresponding Intel® C/C++ Compiler Intrinsic:
__m128i _mm_aesenclast_si128(__m128i v, __m128i rkey);
Description:
Perform the last round of an AES encryption flow operating on a
128-bit data (state) from xmm1 with a 128-bit round key from xmm2/m128.
Instruction:
AESIMC xmm1, xmm2/m128
Corresponding Intel® C/C++ Compiler Intrinsic:
__m128i _mm_aesimc_si128(__m128i v);
Description:
Perform the InvMixColumn transformation on a 128-bit round key
from xmm2/m128 and store the result in xmm1.
Instruction:
AESKEYGENASSIST xmm1, xmm2/m128, imm8
Corresponding Intel® C/C++ Compiler Intrinsic:
__m128i _mm_aeskeygenassist_si128(__m128i ckey, const int rcon);
Description:
Assist in AES round key generation using an 8 bits Round Constant
(RCON) specified in the immediate byte operating on 128 bits of
data specified in xmm2/m128 and stores the result in xmm1.
Instruction:
PCLMULQDQ xmm1, xmm2/m128, imm8
Corresponding Intel® C/C++ Compiler Intrinsic:
__m128i _mm_clmulepi64_si128(__m128i v1, __m128i v2, const int
imm8);
Description:
Carry-less multiplication of one quadword of xmm1 by one quadword
of xmm2/m128, stores the 128-bit result in xmm1. The immediate
is used to determine which quadwords of xmm1 and xmm2/m128 should
be used.
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.
When Static Verifier support is enabled within the IDE, the customary final build target (e.g. an executable image) is not created. As such, we recommend that a separate "Static Verification" configuration be created, by cloning the existing Debug (development) configuration, for use when static verification is desired.
The compiler and debugger integrations into Eclipse* and the C/C++ Development Tools* (CDT) are provided for the 10.1 Intel C++ compiler and idb debugger. However, the common Eclipse* base components (the Eclipse* Platform Binary, Eclipse* C/C++ Development Tools* (CDT), and a JRE), which are required by the compiler and debugger integrations, are no longer provided on the compiler kit. Detailed instructions for freely obtaining these common components are provided in the Installation Guide.
We have verified the 10.1 Intel integration support with:
and:
For additional information on Eclipse* versions 3.2.1, see:
http://archive.eclipse.org/eclipse/downloads/
There is no CDT 4.0 support for the IA-64 architecture currently available, due to the fact that there is no Eclipse 3.3 platform support available on the IA-64 architecture, on which CDT 4.0 depends. The Eclipse 3.3 platform support on IA-64 architecture is not available due to the lack of availability of a version 1.6 JVM on IA-64 architecture, which is required to build Eclipse 3.3. The 1.6 JVM support for IA-64 architecture is not expected this calendar year, and without it, Intel will not be able to provide an Intel® compiler integration for CDT 4.0 on IA-64 architecture. Intel is monitoring the situation and awaiting the availability of a 1.6 JVM on IA-64 architecture.
The Intel® C/C++ Compiler Getting Started and User’s Guide that accompany the Intel Compiler kit have not been updated with information about the new CDT 4.0.2 integration. Please refer to the Eclipse CDT Users Guide for general help.
The specification of multiple versions of the Intel C/C++ compiler to build source components in an Intel® compiler Eclipse/CDT C/C++ project within a single project configuration is not supported. In addition, replacing a particular version of the Intel C/C++ compiler "toolchain" with another version within a project configuration within Eclipse/CDT is not supported.
libimf Linking Change on Intel® 64
Architecture In some earlier versions of Intel C++ Compiler, applications built
for Intel® 64 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 -shared-intel is
used. This matches the behavior on IA-32 architecture systems.
You should use -shared-intel 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 -shared-intel is used.
-early-template-check Switch Even though recent versions of g++ (3.4 and newer) parse template definitions,
they do very little semantic checking of such definitions. Most of the semantic
checking is delayed until an actual instantiation is done. As a result,
g++ accepts certain unusable templates provided they are not actually used
in the program. A new option is available (-early-template-check) to allow
Intel C++ users to check the semantics of function template prototypes before
instantiation.
Example:
class A {};
template <class T> struct B {
B () {}; // error with -early-template-check): no initializer for
// reference member "B<T>::a"
A& a;
};
Note that this switch will work in gcc 3.4 and later compatibility
modes only (i.e. -gcc-version=340 and later).
-ansi no longer implies -fp-port In previous versions of the compiler, the -ansi switch implied
-fp-port. In version 10.1, -ansi no longer implies -fp-port.
As a result, the compiler generates more efficient floating-point code under -ansi,
especially when using x87 instructions to implement FP calculations. Use -fp-port in
addition to -ansi if it is important to round FP data to source
precision at assignments and casts.
-cxxlib-icc no longer supported for C++ This release requires using the GNU g++* C++ libraries when linking C++ applications, rather than those from Dinkumware* supported in previous releases. As a result of this change, this release requires systems with gcc 3.2 or higher installed.
__m64 in Intel® 64 Architecture
Applications The __m64 data type used to be treated as a scalar, at least
to the extent of being able to statically initialize __m64 data
with an integer literal. But for compatibility with directions
being taken by other compilers supporting MMX(TM), we are dropping
support for that feature. As a result, an initializer for a variable
of __m64 type
must be enclosed in braces. If your application uses a scalar to
initialize such variables, the compiler will give an error message
such as:
error: a value of type "unsigned long long" cannot be used to
initialize an entity of type "const __m64"
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.Use of the Eclipse* Integrated Development Environment on Red Hat Enterprise Linux AS 2.1 has the following additional requirements:
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/cc/10.1.xxx
(for IA-32 and IA-64)
/opt/intel/cce/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) 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.
In Update 4 to Red Hat Enterprise Linux 3, inline assembly code was added
to the file /usr/include/c++/3.2.3/ia64_Red Hat-linux/bits/os_defines.h.
This causes the Intel C++ Compiler to fail to compile sources referencing
this header. Note that this problem is not known to exist for any
other version of Linux, including earlier versions of EL3 and EL4 or later.
This issue also affects SGI ProPack 3 Service Pack 5.
A modified header file which corrects this problem is available from http://www.intel.com/software/products/compilers/downloads/os_defines.h.90
A good place to put the modified file is in the substitute headers
directory of your installed compiler. For example,
<install-dir>/substitute_headers/c++/bits/os_defines.h.
The path
must end with bits/os_defines.h. If you place it there the compiler
will find it automatically. You should find an existing installer-created
directory
<install-dir>/substitute_headers and should
create
the sub-directory path c++/bits underneath it.
-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.
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.
-g and inlining
There will be an increase in compile time when -g is used together
with inlining. Inlining can happen if the user specifies -ipo, -ip
or compiles a C++/C99 program at option levels -O1 or
above. This is due to the generation of debug information. For many
applications, this combination of compiler options will not increase compile
time or compile-time memory use.
We have identified a problem with glibc version 2.2.4-26 that shipped with the original version of Red Hat AS2.1. This version causes a compiler hang on the command "icc -v or icc -V (with no files to compile). Upgrading to glibc 2.2.4-31.7 fixes the problem. If you have taken any updates to your AS2.1 you will not see this problem. There was also a respin of the original AS2.1 that fixed this problem so only if you have a very early installation of AS2.1 that has never been updated will you see this issue.
We have identified a problem with the gcc binutils linker in some Linux distributions for x86_64 (Intel® 64 architecture and similar) systems. This problem manifests itself when running the SPEC* CPU2006* benchmark test 471.omnetpp, resulting in incorrect output, and has been reproduced using varying versions of the Intel C++ compiler as well as with gcc. Not all Linux distributions have the affected linker. The Bugzilla reports for this problem are http://sourceware.org/bugzilla/show_bug.cgi?id=2655 and http://sourceware.org/bugzilla/show_bug.cgi?id=2657
Please contact your Linux distributor to find out if your distribution has the affected linker.
-relax no longer passed to linker on IA-64
architecture systems As of version 10.1, 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 icc.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 IA-32 architecture 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.
gdb versions with Intel Compilers
Intel compilers for Linux generate Dwarf2-format debugging information,
including several advanced features in Dwarf2 such as declarations nested
within classes. Older gdb debuggers, such as version 5.3.90-*, are
sometimes unable to correctly handle these Dwarf features. For best success on
source code which uses the full expressiveness of the C++ language, please
consider using gdb version 6.1 or newer.
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.
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/clin.
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)
C++ Compiler, 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 C++ Compiler's Package ID with the following commands:
> icc -V
and copy the "Package ID" (e.g. l_cc_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.
<package ID>_README (e.g. l_cc_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 PDF versions of most manuals are available online at http://developer.intel.com/software/products/compilers/clin/docs/manuals.htm .
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.
For information on the GNU glibc C language library, documentation can be obtained from the Linux OS vendor or from the GNU web site, www.gnu.org.
icc(1) manpage provides a list of command-line options and
related information for the icc and icpc compiler
commands. To display the icc(1) manpage, type the following
command after you set up your environment by using a source
command to execute the <install-dir>/bin/iccvars.*sh file:
$
man icc
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/clin/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.