Known Limitations ================= NOTE WELL: Redhat Linux 7.0 is not currently supported and is known not to work with the current compiler build. The Intel 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 the Microsoft* Visual C++* Compiler. LDB variable display ==================== LDB does not update display variables when execution is continued after the stack frame context is modified. Use of commands such as "up" or "frame[n]" to modify the frame context must be followed by the "frame" command before execution is continued to work around this problem. The problem does not occur when LDB is run under the Data Display Debugger (ddd). Legacy IO Stream Limitations ============================ A number of limitations existed in the implementation of iostream in Beta releases. Many of these are now resolved. - forward class declaration of ostream, which is now a template This remains a problem if the class declaration is before the include of the header containing the template. Otherwise, it is no longer an issue. - The seekoff, sync, out_waiting, and overflow member functions of class streambuf were not made public This is fixed. - The stream.h header file is not provided This is now provided. - There is no conversion that allows an fpos object to be compared to an integer. There is now a conversion function to a "streamoff" type which happens to be a long. - No third argument on filebuf::open for file permissions This is fixed. - No file permission argument allowed on the ostream constructors This is fixed. - No support for the ios::nocreate and ios::noremove bits This is fixed. The following problems remain: - There is a problem with the legacy io formatting functions, form, oct, hex, dec, str and chr. These are declared as C++ names in the headers but they are C names in the headers. As a result, you will get a link time error because the references will be name mangled while the names in the libraries are not mangled. If you encounter this problem, you can work around it by changing the declarations in stream.h, adding extern "C" in front of each declaration. This was not done in the released headers because of concern that the resulting namspace pollution would cause more problems than it would fix. This change will not be required in a future release. 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 ==================================== The Intel C++ Compiler does not allow initialization of an unsigned short array with a wide character literal string when the string is cast to unsigned short *. The following code fragment fails to compile with the Intel C++ Compiler for this reason: struct { unsigned short buf[32]; } s = { (unsigned short *) L"hello" }; A workaround for this problem is to remove the cast to unsigned short *, because it is unnecessary. The same problem affects unsigned char arrays initialized with non-wide string literals. The Intel C++ Compiler issues an error if an identifier with a base type is redeclared using a different base type of the same size. The Microsoft Visual C++ Compiler generates a warning in this situation. The following code fragment fails to compile with the Intel C++ Compiler for this reason: int a; long a; float a; The Intel C++ Compiler generates an error for a character array initialization containing a mixture of characters and strings such as the following: char a[5] = {'a', "bcd"}; 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 =================================== The Intel C++ Compiler can generate incorrect code if an invocation of the alloca function (or of the A2W or W2A macro, which use alloca) appears in an argument list in which a parameter type has a copy constructor. This problem can occur even if the invocation of alloca appears as an argument to a nested function call. For example: class X { public: X(X const &); }; void f(X); f(...g(...alloca(...)...)...); Incorrect code may be generated for the statement that calls f. This problem can be avoided by moving the invocation of alloca (or A2W or W2A) to a separate, previous statement, or by changing the parameter type. In the above example, by changing the parameter type of f from (X) to( X const &). If a class is derived from a class with a private copy constructor, and also has a constructor taking a reference to a base class, the Intel C++ Compiler can report access violations for code which MSVC++ accepts. For example: class CObject {private: CObject(CObject const &);}; class CMyObject1: public CObject { }; class CMyObject2: public CMyObject1 { public: CMyObject2(CMyObject1 const &); }; void f(CMyObject2); void g(CMyObject2 &x) { f(x); } An error is reported against the call to f, because the (compiler-generated) copy constructor is selected to do the copy, but the definition of the copy constructor can't be generated because of the private base-class copy constructor. With MSVC++, the user-declared constructor for CMyObject2 is selected instead. This problem can be avoided by adding a true copy constructor to the class containing the "pseudo" copy constructor (taking the base class reference). The definition of the true copy constructor can initialize the base class with the private copy constructor in the same way that the "pseudo" copy constructor does. Based pointers are not fully supported in C++ code. Although they are accepted (i.e. do not result in an error), they are not taken into account in name mangling, for example. The Intel C++ Compiler does not fully support conversions between pointer-to-member types involving virtual base classes. Use of this feature may result in aborted compilations, and may also result in code which produces incorrect results at run-time. The Intel C++ Compiler emits an error when this situation arises to prevent the possibility of tracking down a difficult run-time problem. You can avoid this error by specifying the /GR option to enable RTTI run-time support, or by specifying /Qw259 on the command line to downgrade the error to a warning. 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. Function Declaration in Function Scope of Function Defined in a Namespace In accordance with the C++ language specification, if a function declaration is encountered within a function definition, the function referenced is taken to be another member of the namespace of the containing function, whether or not the containing function definition is lexically within a namespace definition.