While the Intel® C++ Compiler Classic 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 Classic. In most cases, a modification of the user source file enables successful compilation with both the Intel® C++ Compiler Classic and the Microsoft Visual C++ Compiler. The differences between the compilers are listed as follows:
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
}
For compilations targeted for IA-32 architecture, inline assembly target labels of goto statements are case sensitive. The Microsoft Visual C++ compiler treats these labels in a case insensitive manner. For example, the Intel® C++ Compiler Classic 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 Classic, when a goto statement refers to a label defined in inline assembly, you must match the label reference with the label definition in both name and case.
The Intel® C++ Compiler Classic 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;
}