Intel® oneAPI DPC++/C++ Compiler Developer Guide and Reference

Development Reference Guides

Contents

Microsoft* Compatibility

This content is specific to C++; it does not apply to
DPC++
.
The
Intel® oneAPI
DPC++/C++
 Compiler
 is fully source- and binary-compatible (native code only) with Microsoft Visual C++* (MSVC). You can debug binaries built with the
Intel oneAPI
DPC++/C++
 Compiler
 from within the Microsoft Visual Studio* environment.
The compiler supports security checks with the /GS option. You can control this option in the Microsoft Visual Studio IDE by using
C/C++
Code Generation
Buffer Security Check
.

Microsoft Visual Studio Integration

The compiler is compatible with Microsoft Visual Studio 2017, 2019, and 2022 projects.
Support for Microsoft Visual Studio 2017 is deprecated as of the Intel® oneAPI 2022.1 release, and will be removed in a future release.

Unsupported Features

Unsupported project types:
.NET*-based CLR C++ project types are not supported by the Intel® oneAPI DPC++/C++ Compiler. The specific project types will vary depending on your version of Visual Studio, for example: CLR Class Library, CLR Console App, or CLR Empty Project.
Unsupported major features:
  • COM Attributes
  • C++ Accelerated Massive Parallelism (C++ AMP)
  • Managed extensions for C++ (new pragmas, keywords, and command-line options)
  • Event handling (new keywords)
  • Select keywords:
    • __abstract
    • __box
    • __delegate
    • __gc
    • __identifier
    • __nogc
    • __pin
    • __property
    • __sealed
    • __try_cast
    • __w64
Unsupported preprocessor features:
  • #import
     directive changes for attributed code
  • #using
     directive
  • managed
    ,
    unmanaged
     pragmas
  • _MANAGED
     macro
  • runtime_checks
     pragma

Mixing Managed and Unmanaged Code

If you use the managed extensions to the C++ language in Microsoft Visual Studio .NET, you can use the compiler for your non-managed code for better application performance. Make sure managed keywords do not appear in your non-managed code.
For information on how to mix managed and unmanaged code, refer to the article, An Overview of Managed/Unmanaged Code Interoperability, on the Microsoft Web site.

Precompiled Header Support

There are some differences in how precompiled header (PCH) files are supported between the
Intel® oneAPI
DPC++/C++
 Compiler
 and the Microsoft* Visual C++* Compiler:
  • The PCH information generated by the
    Intel oneAPI
    DPC++/C++
     Compiler
     is not compatible with the PCH information generated by the Microsoft Visual Studio Compiler.
  • The
    Intel oneAPI
    DPC++/C++
     Compiler
     does not support PCH generation and use in the same translation unit.

Compilation and Execution Differences

While the
Intel® oneAPI
DPC++/C++
 Compiler
 is compatible with the Microsoft Visual C++* Compiler, some differences can prevent successful compilation. There can also be some incompatible generated-code behavior of some source files with the
Intel oneAPI
DPC++/C++
 Compiler
. In most cases, a modification of the user source file enables successful compilation with both the
Intel oneAPI
DPC++/C++
 Compiler
 and the Microsoft Visual C++ Compiler. The differences between the compilers are:
  • Inline Assembly Target Labels (IA-32 Architecture Only)
    This content is specific to C++; it does not apply to
    DPC++
    .
    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 oneAPI
    DPC++/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 oneAPI
    DPC++/C++
     Compiler
    , 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.
  • Inlining Functions Marked for dllimport
    The
    Intel oneAPI
    DPC++/C++
     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 need 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
    .
    header.h: 
    #ifndef _HEADER_H
#define _HEADER_H
namespace Foo_NS { 

        class Foo2 { 
        public: 
                Foo2(){}; 
                ~Foo2(); 
                static int test(int m_i); 
        }; 
} 
#endif
    bug.cpp: 
    #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; 
}

Enum Bit-Field Signedness

The
Intel® oneAPI
DPC++/C++
 Compiler
 and Microsoft* Visual C++* differ in how they attribute signedness to bit fields declared with an
enum
 type. Microsoft Visual C++ always considers
enum
 bit fields to be signed, even if not all values of the
enum
 type can be represented by the bit field.
The
Intel oneAPI
DPC++/C++
 Compiler
 considers an
enum
 bit field to be unsigned, unless the
enum
 type has at least one
enum
 constant with a negative value. In any case, the
Intel oneAPI
DPC++/C++
 Compiler
 produces a warning if the bit field is declared with too few bits to represent all the values of the
enum
 type.

Product and Performance Information

1

Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex.