MantisBT - CMake
View Issue Details
0013450CMakeModulespublic2012-08-02 09:472016-06-10 14:31
Jan Rüegg 
Kitware Robot 
highminoralways
closedmoved 
64-bitArchlinux
CMake 2.8.8 
 
0013450: FindCuda: nvcc chockes on -std=c++11
When adding a library with
CUDA_ADD_LIBRARY
and CUDA_PROPAGATE_HOST_FLAGS is set (as is the default) and -std=c++11 then making the project crashes since nvcc cannot handle it. Errors like this appear:

Building NVCC (Device) object AVTLibraries/FutureVideoLibs/CudaPack/CMakeFiles/CudaPack.dir/src/./CudaPack_generated_convolutionSeparable_kernel.cu.o
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/x86_64-unknown-linux-gnu/bits/c++config.h(177): error: identifier "nullptr" is undefined

/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/x86_64-unknown-linux-gnu/bits/c++config.h(177): error: expected a ";"
Checking if -std=c++11 is enabled and removing it from the flags forwarded to nvcc should solve the problem. (Something like this:

if(CMAKE_COMPILER_IS_GNUCC)
  string(REPLACE "-std=c++11" "" CUDA_HOST_FLAGS "${CUDA_HOST_FLAGS}")
  string(REPLACE "-std=c++0x" "" CUDA_HOST_FLAGS "${CUDA_HOST_FLAGS}")
endif()

in CUDA_WRAP_SRC)
No tags attached.
Issue History
2012-08-02 09:47Jan RüeggNew Issue
2012-08-03 14:14James BiglerNote Added: 0030165
2012-08-08 16:13Mathias GaunardNote Added: 0030193
2012-08-09 02:44Jan RüeggNote Added: 0030195
2012-08-09 15:19James BiglerNote Added: 0030200
2016-06-10 14:28Kitware RobotNote Added: 0042100
2016-06-10 14:28Kitware RobotStatusnew => resolved
2016-06-10 14:28Kitware RobotResolutionopen => moved
2016-06-10 14:28Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0030165)
James Bigler   
2012-08-03 14:14   
Right. There are a number of C++ only compiler flags that NVCC chokes on. I wish the nvcc compiler was smart enough to not pass -Xcompiler flags to their various preprocessing stages.

At any rate, I've some local changes that do this for another flag (-fvisibility-inlines-hidden). I should probably generalize this to allow removal of a list of flags that are known to cause problems and also allow the user to specify additional ones without having to modify their set of CXX flags explicitly.
(0030193)
Mathias Gaunard   
2012-08-08 16:13   
Wouldn't it be a better idea to get rid of CUDA_PROPAGATE_HOST_FLAGS entirely?
Propagating host flags is a terrible idea to begin with.
(0030195)
Jan Rüegg   
2012-08-09 02:44   
What about a whitelist of flags? Forwarding flags like "-g", "-O2" or the Warnings "-Wall", "-Wshadow" might still be a good idea...
(0030200)
James Bigler   
2012-08-09 15:19   
Isn't having your host code compiled with different flags than your .cpp files be a worse idea?

This all sprang up from flags such as /MD and /MT from the windows side as well as other flags such as -fPIC. I couldn't foresee the list of opt-in flags, and it's more surprising to have things to be slightly different than to have the occasional C++ only flag cause a problem.

Besides, Mathias, if you don't like propagation of host flags, you can set CUDA_PROPAGATE_HOST_FLAGS to OFF in your builds. That's why I made it an option. For most people it does the right thing by default.
(0042100)
Kitware Robot   
2016-06-10 14:28   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.