What are conflicting memory spaces? compiler warning

When compiling a rather large CUDA kernel (a port of the raytracing application from the SPLASH2 benchmark suit), I get the following warning:

./hutv.cuh(959): Warning: Found conflicting memory spaces being pointed to

Before getting into more detail, I’d like to know what this warning really means. I suspect one of the following (in decreasing order of plausibility to me):


The compiler wants to put some pieces of code and / or data at overlapping memory sections? In this case, “memory spaces” would not allude to global, shared or constant memory but to different sections of program text / data? (The cubin file, obtained from nvcc -keep, has a size of 266KB. Probably much inlining takes place. Compilation with nvcc -arch sm_13 takes about 4.5 minutes.)

The compiler wants to put the same piece of data into (e.g.) global memory space at one time and into shared memory space at another time? (The line complained about is: “r->ri = ri;”)

I wouldn’t expect any problem with transfering data between different memory spaces (like global, shared, constant) like in e.g. “global_var.x = shared_result.x”.

Anything else.

I’d be glad if someone could point me to a source of information explaining the exact meaning of this warning message. What (kind of thing) would be the “memory spaces” and what (kind of thing) would it be that “pointed to” them…?

(The resulting executable can run the kernel many times with input data not accessing the code section complained about. Otherwise the kernel terminates with an ULF (unspecified launch failure). I’ve implemented some logging facilities: Rerunning the same executable first fetches data from the logging data structures in device memory, before these are initialized / cleared for the current run. Using this kind of hack I appear to be able to get logging data from the previous run producing an ULF. These data indicate that the single global function producing an ULF (detected immediately after the kernel call) actually finished in the previous run! The logging mark issued immediately before the last closing bracelet of the global function is present.)

Is it so, that a kernel may actually continue its execution even after something happened that flagged the current call to return with an ULF (unspecified launch failure)? (Allthough one was denied normal access to the failed context.)

The findings described at the end of my previous post in this thread appear to suggest this an explanation and I’m having difficulties imagining other explanations.

What might be the reason for such a kind of ULF or is this even the standard behavior?

This is most likely shared memory vs. global memory. Pointers to shared memory and pointers to global memory require different instructions to load from or store to. If a pointer can sometimes point to shared memory and sometimes point to global memory, (or if the compiler can’t tell) then the compiler will warn you and generate code for dereferencing a global memory pointer. At runtime, if it is a pointer to shared memory, then it is probably not a valid global memory pointer, and dereferencing it will give a ULF.

Thank you very much Jamie K for this most enlightening explanation.

Accordingly, the answers to my original questions would be:

    A “memory space” would be something like constant, shared, global, or local memory.

    The kind of thing that pointed to them could be any single pointer dereferenced at different times of execution (not e.g. two different values being stored in different memory spaces (at the same time)).

(Thus, in my case, it could not be any of the “ri” in “r->ri = ri”, leaving only “r” as the objective. In fact, this line could be reached following different execution paths. But, in all of these, “r” should point to local memory (of active functions). Recently, I discovered a bug in my code involving macro arguments not being properly enclosed inside parentheses. Correcting this, also cleared the warning about conflicting memory spaces.)

It would be nice to have comprehensive lists of error and warning messages specific to nvcc together with explanations of their meaning in the documentation pdf of nvcc. The current nvcc_2.3.pdf does not contain such a list (nor do CudaReferenceManual.pdf, NVIDIA_CUDA_BestPracticesGuide_2.3.pdf, or NVIDIA_CUDA_ProgrammingGuide_2.3.pdf). I’d be happy to learn about any place where such explanations were gathered.