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.