Open krasznaa opened 1 month ago
Hmm, I wonder if the following preprocessor condition fires on MSVC:
#elif defined(__clang__) || defined(__GNUC__) || defined(__GNUG__) || defined(__CUDACC__)
If so, that makes sense. I know that clang sets __GNUC__
, so MSVC might do the same.
All other uses of both __memorder_vecmem_to_builtin
and __atomic_fetch_add
are guarded by the VECMEM_HAVE_MEMORDER_DEFINITIONS
and VECMEM_HAVE_BUILTIN_ATOMIC_FETCH_ADD
, which should be defined correctly... :thinking:
Hmm, no it doesn't: https://godbolt.org/z/o65TPMGPa
Okay, that's super weird. I'm not really familiar with how CUDA compilation works with MSVC, but the line indicated in the error (187) is the following:
#elif defined(VECMEM_HAVE_BUILTIN_ATOMIC_LOAD) && \
defined(VECMEM_HAVE_MEMORDER_DEFINITIONS)
return __atomic_load_n(m_ptr, __memorder_vecmem_to_builtin(order));
where VECMEM_HAVE_BUILTIN_ATOMIC_LOAD
is defined iff:
#if defined __has_builtin
#if __has_builtin(__atomic_load_n)
#define VECMEM_HAVE_BUILTIN_ATOMIC_LOAD
#endif
#endif
and VECMEM_HAVE_MEMORDER_DEFINITIONS
is defined at the same time as the __memorder_vecmem_to_builtin
function:
#if defined(__ATOMIC_RELAXED) && defined(__ATOMIC_CONSUME) && \
defined(__ATOMIC_ACQUIRE) && defined(__ATOMIC_RELEASE) && \
defined(__ATOMIC_ACQ_REL) && defined(__ATOMIC_SEQ_CST)
constexpr int __memorder_vecmem_to_builtin(memory_order o) {
switch (o) {
case memory_order::relaxed:
return __ATOMIC_RELAXED;
case memory_order::consume:
return __ATOMIC_CONSUME;
case memory_order::acquire:
return __ATOMIC_ACQUIRE;
case memory_order::release:
return __ATOMIC_RELEASE;
case memory_order::acq_rel:
return __ATOMIC_ACQ_REL;
case memory_order::seq_cst:
return __ATOMIC_SEQ_CST;
default:
assert(false);
return 0;
}
}
#define VECMEM_HAVE_MEMORDER_DEFINITIONS
#endif
Does MSVC + CUDA work differently than on Linux, where the nvcc compiler driver causes the preprocessor definitions to be evaluated twice; once for the host code and the device code? If this differs somehow, that could explain the problem.
Nevermind, I think I know what's going on.
Unfortunately #275 seems to have introduced a failure in a setup that's not too easy to test in the CI. 😦 While building the latest code on Windows, with CUDA available, I bump into:
So
nvcc
is trying to compiletest_cuda_edm_kernels.cu
, and gets confused about how to usevecmem::device_atomic_ref
.The preprocessor flags will need to be tweaked to fix this. 🤔