That won’t work either… the host cannot write to test_ptr. You’ll need a combination of cudatGetSymbolAddress and cudaMemcpyToSymbol in order to truly initialize that pointer. But ask yourself if you truly want to do this… There is almost never a good reason to want to do an uncoalesced read from global mem just to get a pointer to perform yet another read from global mem.
I am just reporting a compiler defect. Please don’t read my code literally.
As for workarounds, I guess the simplest one would be to call a host function to init the pointers. But in my real code the tables are supposed to reside constant memory, I haven’t found an acceptable workaround, so suggestions welcome.
Well, I do. I need starting addresses of some variable length tables. I don’t see why not if this happens outside any performance critical loop. Alternative would be a huge case statement.
Actually, you don’t agree MisterAnderson42. He never said that this compiler behaviour was not a compiler bug. If a failed assertion is not a compiler defect for you then I am grateful that you don’t write compilers I am used to use.
MisterAnderson42 only warned me about the adverse performance effect of such statement, and I replied that in my code it is used so marginally, that there would not be any.
Yes, daddy. I will never take constant pointer to a constant again. This is sooooo improper. :">
Seriously, I don’t find your void patronizing statements appropriate.
You can’t tell a legal C statement from an illegal C statement. You can’t tell a failed assertion from a compile time warning. And you even can’t even tell upload form download. It is therefore impossible for you to offend me. By calling me a fool, or in any other way.
You claim that nvcc is full of bugs. So why don’t you disclose the list of bugs you found?
Prior to answering me, ask yourself a question if you really have something to say.