How do I fix an error such as “error: unknown type name” when I migrate files
with “dpct –in-root=srcdir –out-root=dstdir *.cu”?
The problem may be caused by files in the
list, which can
be used as header files (included with an
and are not supposed to be parsed as a standalone file. In this
case, the Intel® DPC++ Compatibility Tool reports an error if it
cannot parse the file because the file depends on the
definitions/declarations in other files. Use one of the methods
below to migrate your content:
Rely on the Intel® DPC++ Compatibility Tool to decide which
files to migrate with:
compile_commands.json: “dpct -p=compile_commands.json --in-root=srcdir --out-root=dstdir”
Manually pass specific files to migrate, but do not pass the
files that are included in other files and not supposed to be
compiled as a standalone file in the original application. The
header files are migrated automatically when they are included
by the files provided as the input to the tool and are located
dpct --in-root= srcdir --out-root=dstdir sample.cu
How do I fix a parsing error such as “no member named ‘max’ in namespace ‘std’”
or “no member named ‘min’ in namespace ‘std’” when migrating code on Windows?
Use one of the following methods to resolve the error:
to the source file before using
Define the NOMINMAX macro by inserting
How do I fix a compilation error such as “error: dlopen not declared” when I
compile code on a Windows machine, that was originally migrated on Linux?
When the Intel® DPC++ Compatibility Tool generates the source code, it uses dynamic loading
APIs specific to the OS on which the Intel® DPC++ Compatibility Tool is running.
are used on Linux and
are used on Windows.
If your code was migrated on a OS that is different from the OS you
need to compile the generated code on, migrate the project again with the
Intel® DPC++ Compatibility Tool on the target OS or fix the code manually.
Why didn’t the “atomic*” APIs get migrated?
The Intel® DPC++ Compatibility Tool may assume that the “atomic*” APIs are user-defined
APIs, in which case they are not migrated.
This can occur in the following scenarios:
The CUDA include path is specified by both
but the paths are different
The CUDA include path is specified by
, but there are other CUDA include
files located on the default CUDA install path
To make sure “atomic*” APIs are migrated, don’t use
to specify the CUDA
include path with the
migration command. Instead, use only
to specify the CUDA include path.
Why did my migration fail with “error: restrict requires a pointer or reference”?
The C++ standard does not support the restrict qualifier and the C standard
supports the restrict qualifier only on pointers to an object type.
Based on these language standards the Intel® DPC++ Compatibility Tool emits the parsing error.
You may need to adjust the source code.