Intel(R) C++ Compiler for IA-32, Version 7.1 Release Notes
===========================================================
Known Limitations
=================
The Intel(R) Premier Support website contains
more up to date information on errata and the availability of new versions
of the compiler.
The following are known defects in the Intel C++ Compiler, which might
be fixed in a future version. This list is divided into defects that
can affect both C and C++, and defects that affect only C++ programs.
Where relevant, the behavior of the Intel C++ Compiler is compared
against the behavior exhibited by Gnu C,
Object file incompatibility between version 6.0 and 7.0, 7.1
============================================================
Object files built with version 6.0 of Intel(R) Compilers may not link
properly with objects built with version 7.0 or 7.1 of Intel(R) Compilers.
Rebuilding of the object files is suggested.
Excess parameters in function calls cause a warning rather than an error
=========================================================================
This was originally changed from an error to a warning to provide Microsoft
compatibility. This was not turned back into an error for the linux compiler.
To make this an error, add the flags -Qwr1125 and -Qwe140 to the icc.cfg file.
A Simple Demangler
==================
To help with demangling of entry points, a simple demangler, iccfilt, is
supplied. Any text that you pipe through this will be checked for mangled
names and any such names will be demangled.
So, for example, you can pipe the output from nm through this to get demangled
external names. You can also use it for unresolved error messages from the
linker, etc.
Defects Specific to Streaming SIMD Extensions Features
======================================================
The compiler may incorrectly perform optimizations across use of the
_mm_setcsr and _mm_sfence intrinsics. A work-around is to disable
optimization for functions that use these intrinsics or to use inline
assembly to access these instructions.
Defects Affecting C and C++ Programs
====================================
Alignments are different when using assembled .asm files as compared
to directly generated objects.
In an inline asm block, the conditional jumps, jcxz and jecxz, should
not be used to jump to another function. For instance, jcxz and jecxz
will not have the correct target location in the following code:
int main(void);
void DoneThat(void);
void BeenThere(void);
int main()
{
BeenThere();
return 0;
}
void BeenThere()
{
__asm jcxz DoneThat
__asm jecxz DoneThat
}
void DoneThat()
{
exit(0);
}
Defects Affecting Only C++ Programs
===================================
None known at present.
Compatibility with Gnu C
========================
A number of Gnu extensions are not supported by the Intel compiler at this time.
A list of Gnu extensions can be found at http://gcc.gnu.org/onlinedocs/gcc_6.html#SEC84.
The following list of unsupported extension is believed to be complete.
Nested functions
Constructing calls
naming types of expressions
generalized lvalues
arithmetic on function pointers
cast to union type
attributes: constructor destructor packed transparent_union
prototypes and old style function declarations
controlling names used in assmbler code
variables in specified registers
getting the return or frame address of a function
Limitations and Tool Notes
==========================
The following are limitations of the Intel C++ Compiler.
Redefining Standard ANSI Library Functions in Your Program
Programs that redefine standard ANSI library functions, like strcat(),
atoi(), or memset() might fail to link with /Qprof_gen. This is because
the runtime support linked in to support the program instrumented for
profiling makes calls to some standard library routines that in turn
may pull in other standard routines. Note that a program can redefine
standard ANSI library functions legally only if the corresponding standard
header files are not included. Furthermore, the routine must be defined
as static. The workaround is to rename the user-defined version of the
standard library function.
Use of Friend Injection: Not Recommended Sometimes a class is a member
of a namespace , and contains a friend declaration of a function not
already declared. In such cases, the Intel C++ Compiler injects the
function declaration into the namespace containing the class, even if
the class definition is not lexically within the namespace definition.
Avoiding need to use LD_LIBRARY_PATH
====================================
The file icc.cfg in the compiler bin directory can be used to give default options.
You can avoid the need to set LD_LIBRARY_PATH with the following linker directive.
-Xlinker -rpath -Xlinker /compiler70/ia32/lib
Where is the directory the compiler is installed in - by default, /opt/intel.
This is a standard ld option and more information about this can be found in the
documentation on ld.
Note that if you intend to distribute your components as part of a product, you may not
want to use this directive, or you may want to change it to point to a directory in which
your product will be installed. In the latter case, you will have to create that directory
with the appropriate libraries in it on your build machine. Your End User License Agreement
should also be consulted for a list of the compiler components that you are permitted to
redistribute.
This line is present in the shipped version as it is believed this is a convenience
for the user.
=======================================================================================
Intel, Pentium, Pentium Pro, Itanium and MMX are trademarks or registered trademarks of
Intel Corporation or its subsidiaries in the United States and other countries.
*Third-party brands and names are the property of their respective owners.
Copyright 1998-2003, Intel Corporation, All Rights Reserved.