Developer Guide and Reference


Compilation and Execution Differences

While the Intel® C++ Compiler is compatible with the Microsoft* Visual C++* compiler, some differences can prevent successful compilation. Also there can be some incompatible generated-code behavior of some source files with the Intel® C++ Compiler. In most cases, a modification of the user source file enables successful compilation with both the Intel® C++ Compiler and the Microsoft* Visual C++* compiler. The differences between the compilers are listed as follows:

Evaluation of Left Shift Operations

The Intel® C++ Compiler differs from the Microsoft* Visual C++* compiler in the evaluation of left shift operations where the right operand, or shift count, is equal to or greater than the size of the left operand expressed in bits. The ANSI C standard states that the behavior of such left-shift operations is undefined, meaning a program should not expect a certain behavior from these operations. This difference is only evident when both operands of the shift operation are constants. The following example illustrates this difference between the Intel® C++ Compiler and the Microsoft* Visual C++* compiler:
int x; int y = 1; //set y=1 void func() {   x = 1 << 32;   // Intel C++ Compiler generates code to set x=1   // Visual C++ Compiler generates code to set x=0     y = y << 32;   // Intel C++ Compiler generates code to set y=1   // Visual C++ Compiler generates code to set y=1 }

Inline Assembly Target Labels (IA-32 Architecture Only)

For compilations targeted for IA-32 architecture, inline assembly target labels of
statements are case sensitive. The Microsoft* Visual C++* compiler treats these labels in a case insensitive manner. For example, the Intel® C++ Compiler issues an error when compiling the following code:
int func(int x) { goto LAB2; // error: label "LAB2" was referenced but not defined __asm lab2: mov x, 1 return x; }
However, the Microsoft* Visual C++* compiler accepts the preceding code. As a work-around for the Intel® C++ Compiler, when a
statement refers to a label defined in inline assembly, you must match the label reference with the label definition in both name and case.

Inlining Functions Marked for dllimport

The Intel compiler will attempt to inline any functions that are marked dllimport but Microsoft will not. Therefore, any calls or variables used inside a dllimport routine needs to be available at link time or the result will be an unresolved symbol.
The following example contains two files: header.h and bug.cpp.
#ifndef _HEADER_H #define _HEADER_H namespace Foo_NS { class Foo2 { public: Foo2(){}; ~Foo2(); static int test(int m_i); }; } #endif
#include “header.h” struct Foo2 { static void test(); }; struct __declspec(dllimport) Foo { void getI() { Foo2::test(); }; }; struct C { virtual void test(); }; void C::test() { Foo* p; p->getI(); } int main() { return 0; }

Product and Performance Information


Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice.

Notice revision #20110804