CUDA ERROR
a value of type "void *" cannot be assigned
nvcc compiles .cu files as C++, which will not convert void*. On CUDA 12.6, the diagnostic said cannot be used to initialize, not cannot be assigned.
nvcc compiles a .cu file as C++, and C++ refuses the implicit void* conversion that C allowed.
| Kind | Compile-time, language rules. No cudaError code |
| Captured with | CUDA 12.6 (V12.6.85), 2026-09-01 |
| Source | code/errors/_toolchain/evidence/run-2026-09-01.txt |
The full string continues past the title with the type you were assigning to. Both forms are printed below.
Strings a reader might paste
Captured on this project's own node, CUDA 12.6 (V12.6.85), from code/errors/_toolchain/evidence/run-2026-09-01.txt:
$ nvcc -std=c++17 -arch=sm_75 -c voidptr.cu
voidptr.cu(2): error: a value of type "void *" cannot be used to initialize an entity of type "float *"
int main() { float* p = malloc(16); (void)p; return 0; }
^
1 error detected in the compilation of "voidptr.cu".
Note the verb. Our capture says cannot be used to initialize, because the code declares and assigns in one statement. The widely searched form says cannot be assigned to an entity of type "int *", which is what nvcc prints when the assignment is separate from the declaration; that wording is the one a learner reported at https://github.com/Infatoshi/cuda-course/issues/5 (checked 2026-08-29). Same rule, two diagnostics, and searching for one will not find a page that only prints the other, which is why both are on this one.
The host compiler's version of the same complaint, if the file is a .cpp built with g++, is invalid conversion from 'void*' to 'float*' [-fpermissive].
Cause 1: C code compiled as C++
The whole of it. malloc returns void*. C converts that to any object pointer silently; C++ does not, and nvcc is a C++ compiler.
float* p = malloc(16); // legal C, rejected by nvcc
Fix: cast it. float* p = (float*)malloc(16); or, preferably in C++, static_cast<float*>(malloc(16)). If the file has no device code in it at all, the other fix is to keep it as a .c file and link it, which is cause 3.
Cause 2: cudaMalloc with the wrong level of indirection
The same rule bites a second time, in the opposite direction, because cudaMalloc takes a void**:
cudaMalloc((void*)&d_a, bytes); // one star short
Fix: cudaMalloc((void**)&d_a, bytes). The bare cudaMalloc(&d_a, bytes) also compiles, because the CUDA runtime headers provide a template overload that accepts T** directly, and that is why you see both spellings in the wild without either being wrong.
Cause 3: a .c file renamed to .cu
Everything else follows from this one. Renaming the extension changed the language, and every C idiom that C++ tightened now needs attention: void* conversions, stricter enum rules, and char* from string literals.
Fix: decide deliberately. Either accept C++ rules for the whole file, or keep the host code in .c, compile it with a C compiler, and give the CUDA half its own .cu.
Confirm it
No tool needed, and that is the point of the page. If the file ends in .cu, it is C++. Compile the same source as C with gcc -c file.c and watch the error vanish; that one experiment settles it faster than reading about the difference.
Prevention
- Cast every
malloc, or usenewandstd::vectorfor host buffers and stop meeting the problem. - Keep the mental model:
.cumeans C++ plus CUDA extensions, and the C++ half is where beginners lose their first afternoon.
Related errors
calling a __host__ function from a __device__ function: the other language rule that stops day-one learners, from the same capture session.nvcc fatal: Unsupported gpu architecture: the next compile-time wall, once the language errors are gone.invalid argument(1): where acudaMallocwritten with the wrong indirection surfaces if it does compile.
The lesson
Day 0 covers the C and C++ you need before any CUDA, and names this error specifically. Day 39 is where the C++ half stops being an obstacle and starts being the tool. The full code table is on the error hub; installing a toolkit at all is /setup/install-cuda.
Written 2026-09-01. Compiler output from code/errors/_toolchain/evidence/run-2026-09-01.txt, captured 2026-09-01 with CUDA 12.6 (V12.6.85) on ornn-internal-t4-spot-5v08. This is a compile-time error, so no GPU was needed to reproduce it. Author and reviewer: not yet assigned; this page does not publish until both are named.