Example programs fail compilation due to HANDLE being undefined

[Q-Minh]

Using VS2019, CMake 3.18.4 and CUDA Toolkit 11.4, I get a compilation error when trying to build the examples from this repository.
Essentially, in cuda/api/virtual_memory.hpp, the type HANDLE is undefined. There might be some #include directive missing somewhere such that the WinAPI's HANDLE is not defined. I tried a quick fix by adding #include <windows.h> on top of cuda/api/virtual_memory.hpp, but now a macro named max gets defined, such that the expression std::numeric_limits<int>::max() is ill-formed when used in cuda/nvrt/program.hpp, because the max substring in it gets string-replaced by the preprocessor to something else.

I've successfully compiled all the samples from the CUDA Toolkit v11.4 with VS2019, so I know I have a CUDA 11.4 capable environment.
The cuda-api-wrappers example targets that I've tested with failed compilations are device_management and array_management. Other targets also have the same problem.

[eyalroz]

Perhaps you could help me out on where to get this type definition from. Have a look at this:

enum CUmemAllocationHandleType

Flags for specifying particular handle types
Values

CU_MEM_HANDLE_TYPE_NONE = 0x0
    Does not allow any export mechanism. > 
CU_MEM_HANDLE_TYPE_POSIX_FILE_DESCRIPTOR = 0x1
    Allows a file descriptor to be used for exporting. Permitted only on POSIX systems. (int) 
CU_MEM_HANDLE_TYPE_WIN32 = 0x2
    Allows a Win32 NT handle to be used for exporting. (HANDLE) 
CU_MEM_HANDLE_TYPE_WIN32_KMT = 0x4
    Allows a Win32 KMT handle to be used for exporting. (D3DKMT_HANDLE) 
CU_MEM_HANDLE_TYPE_MAX = 0x7FFFFFFF

It's some kind of Win32 memory handle. Which file is it coming from? Or - what type is it, actually?

[eyalroz]

Also... could you try replacing HANDLE with void *?

[Q-Minh]

Ok, so I found that HANDLE is a typedef for void* and it comes from the winnt.h header of Windows API (line 659 for version 10.0.18362 of Windows SDK). I tried replacing HANDLE with void* or simply having an #include <winnt.h> at the top of the cuda/api/virtual_memory.hpp file.

When I replace HANDLE with void* in cuda/api/virtual_memory.hpp line 123, now all the examples compile successfully except for:

• jitify, which complains about std::experimental::filesystem being deprecated by Microsoft, because I am using C++17
• memMapIPCDrv, which attempts to access the iterator_category alias/typedef on std::iterator_traits<enumerator<std::vector<HANDLE,std::allocator<HANDLE>>>::const_iterator>, but it looks like no such alias/typedef exists, I don't know if std::iterator_traits supports void*, and I suspect this is what causes the waterfall of subsequent compilation errors for memMapIPCDrv.
• simpleDrvRuntimePTX has the error cuda-api-wrappers\examples\modified_cuda_samples\simpleDrvRuntimePTX\simpleDrvRuntimePTX.cpp(82,27): error C3861: 'mkstemp': identi fier not found [C:\git\cuda-api-wrappers\build\examples\simpleDrvRuntimePTX.vcxproj
• vectorAddMMAP has the error cuda-api-wrappers\examples\modified_cuda_samples\vectorAddMMAP\vectorAddMMAP.cpp(163,107): error C2665: 'cuda::memory::virtual_::se t_access_mode': none of the 2 overloads could convert all the argument types
• vectorAdd_profiled has the error cuda-api-wrappers/src\cuda/nvtx/profiling.hpp(339): error : no instance of function template "cuda::profiling::detail_::name_host_t hread" matches the argument list

When I keep the using type = HANDLE in cuda/api/virtual_memory.hpp lin 123, but I have the #include <winnt.h> at the top of the file, then I get a whole bunch of other errors. If you need to see the errors, I can show them, just let me know.

[eyalroz]

These are all separate issues :-P ... which need to be filed and handled separately. If it's too much of a hassle for you then I'll do it.

Anyway, my workaround for HANDLE is just using a void* directly, and I think we can live with that for the time being and move on to the other issues.

[Q-Minh]

These are all separate issues :-P ... which need to be filed and handled separately. If it's too much of a hassle for you then I'll do it.

Anyway, my workaround for HANDLE is just using a void* directly, and I think we can live with that for the time being and move on to the other issues.

I see you beat me to it, I believe you've already reported these issues separately yourself. Thank you for the swift assistance!

[eyalroz]

@Q-Minh : Actually, not really. The 1st, 4th and 5th issues are unfiled...

[Q-Minh]

I've opened them quickly, but more details can be added if need be. See #345 #344 #343