Several error messages in the cuda compiler assume context and make discovering of errors is difficult.
Example:
1>C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v7.0\include\thrust/detail/internal_functional.h(322): error : no operator “=” matches these operands
I have 200 000 lines of code. which are these operands? where they come from? what source line, etc.
Go find it by yourself if you want.
I am not sure I follow. nvcc error messages do include the file name and line number at which the problem was detected. In this case it is line 322 of the file “C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v7.0\include\thrust/detail/internal_functional.h”. I do not have that file in front of me, but there is probably just one assignment operator in that line.
A likely source of this kind of error is that the class of the object on the left hand side does not have an appropriate assignment operator defined. Determine the type of the expression on the right hand side, determine the type of the operand on the left hand side, then define an assignment operator for that combination in the class in question. Alternatively, you may find out that such an assignment makes no sense, which probably points to a design issue elsewhere.
This is fairly typical for templated libraries. The error sequence will usually ultimately trace back to one of the files in your project. It’s impossible to demonstrate that with your example, since you’re not providing the whole error output. And if you look at just that one line of your error output, I agree that you will never discover what the problem is.
This is not unique behavior to CUDA. And the compiler that is generating that error message is quite possibly cl.exe, the compiler that ships with Visual Studio (since that particular line of code is in a host device function, it will be compiled by both the host and device compiler).
Here’s a more complete, possibly “typical” error report that I see using thrust:
/usr/local/cuda/bin/..//include/thrust/iterator/iterator_traits.h(45): error: name followed by "::" must be a class or namespace name
detected during:
instantiation of class "thrust::iterator_traits<T> [with T=int]"
/usr/local/cuda/bin/..//include/thrust/iterator/detail/iterator_traits.inl(60): here
instantiation of class "thrust::iterator_system<Iterator> [with Iterator=int]"
/usr/local/cuda/bin/..//include/thrust/detail/scan.inl(263): here
instantiation of "OutputIterator thrust::inclusive_scan(InputIterator, InputIterator, OutputIterator) [with InputIterator=int, OutputIterator=thrust::detail::normal_iterator<thrust::device_ptr<uint32_t>>]"
t835.cu(139): here
If I simply look at:
/usr/local/cuda/bin/..//include/thrust/iterator/iterator_traits.h(45): error: name followed by "::" must be a class or namespace name
Then that error message doesn’t give me much to go on.
But if I look at the subsequent lines of error output:
detected during:
instantiation of class "thrust::iterator_traits<T> [with T=int]"
/usr/local/cuda/bin/..//include/thrust/iterator/detail/iterator_traits.inl(60): here
instantiation of class "thrust::iterator_system<Iterator> [with Iterator=int]"
/usr/local/cuda/bin/..//include/thrust/detail/scan.inl(263): here
instantiation of "OutputIterator thrust::inclusive_scan(InputIterator, InputIterator, OutputIterator) [with InputIterator=int, OutputIterator=thrust::detail::normal_iterator<thrust::device_ptr<uint32_t>>]"
t835.cu(139): here
Then that error ultimate gets linked back to a line of source code (139) in a file in my project (t835.cu) that ultimately led to that error.
It’s still not trivial to deduce what is going on, but again this is not unique to CUDA. the windows and linux host compilers behave similarly.
These kind of complicated error scenarios are typical for C++ programming, and in particular when using templates. In my experience the error messages provided by the CUDA tool chain are on par with what other compilers provide (not very surprising, as the CUDA toolchain uses components that are also used by other toolchains). As txbob points out, the error message in question here may even come directly from the host compiler.