通过CMake通过NVCC传递给MSVC的令人困惑的标志 [英] Confusing flags passed to MSVC through NVCC with CMake
问题描述
我有一个CMake文件,用于在Windows(NVCC / MSVC)上构建一些CUDA。我正在尝试使用以下方式将MSVC警告级别设置为 / W4
:
add_compile_options( $< $< COMPILE_LANGUAGE:CUDA>:-compiler-options = / W4>)
使用CMake 3.9构建此消息:
(CudaBuildCore目标)->
cl:命令行警告D9025:用'/ W3'覆盖'/ W4'
在CMake 3.15中,策略已更改为不自动在CUDA标志中设置 / W3
,但是使用该版本,我得到:
(CudaBuildCore目标)->
cl:命令行警告D9025:用'/ W1'覆盖'/ W4'
如果使用-verbose
进行构建,则看到3.9:
C:\Program Files\NVIDIA GPU计算工具包\CUDA\v10.1\bin\nvcc.exe -gencode = arch = compute_30,code = \ compute_30,compute_30\ \ --use-local-env -ccbin C:\程序文件(x86)\Microsoft Visual Studio\2017\社区\VC\工具\MSVC\14.16.27023\bin\ \HostX86\x64 -x cu -IC:\Users\eddi\文档\temp\thur\sw\include -IC:\Users\eddi\Documents\temp\共享共享-i C:CProgram Files\NVIDIA GPU计算工具包\CUDA\v10.1\include --keep-dir x64\调试- maxrregcount = 0 --machine 64 --compile -cudart static --compiler-options = / W4 --compiler-options = -Xcompiler = / EHsc -Zi -Ob0 -g -D_WINDOWS -D FISH_BUILD_TYPE = \ DEBUG\ -D CMAKE_INTDIR = \ Debug\ -D CMAKE_INTDIR = \ Debug\ -D_MBCS -Xcompiler / EHsc / W3 / nologo / Od / Fdfish .dir\调试\fish.pdb / FS / Zi / RTC1 / MDd / GR -o fish.dir\调试\fish_cuda.obj C:\Users\eddi\Document\temp\ \thur\sw\fish_cuda.cpp
并带有3.15:
C:\Program Files\NVIDIA GPU计算工具包\CUDA\v10.1\bin\nvcc.exe -gencode = arch = compute_30,code = \ compute_30,compute_30\ --use-local-env -ccbin C:\Program Files(x86)\Microsoft Visual Studio\2017\Community\VC\ \工具\MSVC\14.16.27023\bin\HostX86\x64 -x cu -IC:\Userseded\Documents\temp\thur\sw\include -IC: \用户使用的文档\共享的\temp\thur'sw\共享\包括-I C:\Program Files\NVIDIA GPU Computing Toolkit\CUDAv10.1 \include --keep-dir x64\调试-maxrregcount = 0 --machine 64 --compile -cudart static --compiler-options = / W4 --compiler-options = -Xcompiler = / EHsc -Zi- Ob0 -g -D_WINDOWS -D FISH_BUILD_TYPE = \ DEBUG\ -D CMAKE_INTDIR = \ Debug\ -D CMAKE_INTDIR = \ Debug\ -D_MBCS -Xcompiler / EHsc / W1 / nologo / Od / Fdfish.dir\Debug\fish.pdb / FS / Zi / RTC1 / MDd / GR -o fish.dir\Debug\fish_cuda.obj C:\Users\eddi\Documents\temp \thur\sw\fish_cuda.cpp
扰流器:这些是相同的,除了 -Xcompiler / EHsc / W3 / nologo / Od /Fdfish.dir\Debug\fish.pdb / FS / Zi / RTC1 / MDd / GR
部分。 / p>
尽我所能尝试,我无法找到这组标记的引入位置(CMake等人),因此无法开始研究如何更改行为。
EDIT1:为故事添加色彩...
我为CMake安装了 / nologo
并找到了几个 .cmake
文件,这些文件的行如下:
35:set(CMAKE_CL_NOLOGO / nologo)
我将它们全部更改为
35:set(CMAKE_CL_NOLOGO / nologo_EDD)
但是在混乱的选项集中没有一个出现。因此,是我错过了某些东西,还是从CMake之外的东西中引入了它们?
EDIT2:
@squareskittles说:
您可以从CMAKE_CXX_FLAGS_INIT变量中删除默认标志
足够,我可以看到这样的逻辑:它很简单,并且可以直接解决我的紧迫问题。但这似乎有点钝,而且一开始并没有解决标记的来源。
无论如何,除了反对意见,我还在脚本中添加了这个丑陋的小句:
message( --------------------------- $ {CMAKE_CXX_FLAGS_INIT})
字符串(REGEX REPLACE / W [0-4] CMAKE_CXX_FLAGS_INIT $ {CMAKE_CXX_FLAGS_INIT})
消息( --------------------------- $ {CMAKE_CXX_FLAGS_INIT})
使用CMake 3.9,我会看到:
--------------------------- / DWIN32 / D_WINDOWS / W3 / GR / EHsc
--------------------------- / DWIN32 / D_WINDOWS / GR / EHsc
如希望的那样。但是在3.15中,我看到了:
------------------- -------- / DWIN32 / D_WINDOWS / GR / EHsc
--------------------------- / DWIN32 / D_WINDOWS / GR / EHsc
即 / W3 $ c $由于政策的变化,c>标记最初没有出现(更不用说
/ W1
标记了)。但更糟糕的是,在两种情况下,主要问题仍然存在:
nvcc.exe ... --compiler-options = / W4 -Xcompiler = / EHsc -Zi -Ob0 ... -Xcompiler / EHsc / W3 / nologo / Od /Fdfish.dir\Debug\fish.pdb / FS / Zi / RTC1 / MDd / GR。 ..
EDIT3:有些进步!
进行以下简单更改:
#add_compile_options( $< $< COMPILE_LANGUAGE:CUDA> ;:-compiler-options = / W4>)
add_compile_options( $< $< COMPILE_LANGUAGE:CUDA>:-Xcompiler = / W4>)
没有更多的投诉了!令人困惑的标志仍然存在,但是现在读取:
-Xcompiler / EHsc / W4 / nologo / Od /Ffish.dir\ Debug\fish.pdb
/ FS / Zi / RTC1 / MDd / GR
即。 CMake发现了 / W4
并覆盖了其默认值。
但是尽管搜寻CMake来源,我仍然尚未确定所有步骤在何处完成。
编辑4:MSVC可以完成所有这一切。
神秘选项是MSVC从 .vcxproj
文件自动生成的。如果使用 -Xcompile = / W4
方法,则项目XML包含:
< CudaCompile>
...
< AdditionalOptions>%(AdditionalOptions)-Xcompiler = / EHsc -Zi -Ob1< / AdditionalOptions>
...
<警告> W4< /警告>
< / CudaCompile>
但是使用原始的-compiler-options = / W4
我得到:
< CudaCompile>
< AdditionalOptions>%(AdditionalOptions)--compiler-options = / W4 -Xcompiler = / EHsc -Zi -Ob1< / AdditionalOptions>
...
< / CudaCompile>
这一切都有道理;在未指定警告级别的情况下,MSVC必须默认为W1,因此为投诉。
此外,还有一个线索,具有后见之明:构建步骤具有:
-Xcompiler = / EHsc -Zi -Ob0
-Xcompiler / EHsc / W1 / nologo / Od ...
请注意,其中一个具有等号,而一个并不等于或暗示它们来自不同的地方。
我认为我的调查到目前为止已经足够了。
我自己的毛茸茸的狗的故事的TL; DR摘要:
我有:
add_compile_options( $< $< COMPILE_LANGUAGE:CUDA>:-compiler-options = / W4>)
,但发现:
add_compile_options( $< $< COMPILE_LANGUAGE:CUDA>:-Xcompiler = / W4>)
更合适。
基本上,CMake / NVCC / MSVC管道了解到 -Xcompil er
选项覆盖默认值,但没有意识到-compiler-options
是等效的语句,导致命令行中的指令不明确
I have a CMake file which I'm using to build some CUDA on Windows (NVCC/MSVC). I'm trying to set the MSVC warning level to /W4
, using:
add_compile_options("$<$<COMPILE_LANGUAGE:CUDA>:--compiler-options=/W4>")
Building with CMake 3.9, I get this warning:
(CudaBuildCore target) ->
cl : Command line warning D9025: overriding '/W4' with '/W3'
In CMake 3.15, the policy was changed to not automatically set /W3
in the CUDA flags, but with that version I get:
(CudaBuildCore target) ->
cl : Command line warning D9025: overriding '/W4' with '/W1'
If I do the build step with --verbose
I see the following with 3.9:
"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.1\bin\nvcc.exe" -gencode=arch=compute_30,code=\"compute_30,compute_30\" --use-local-env -ccbin "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\HostX86\x64" -x cu -IC:\Users\eddi\Documents\temp\thur\sw\include -IC:\Users\eddi\Documents\temp\thur\sw\shared\common\include -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.1\include" --keep-dir x64\Debug -maxrregcount=0 --machine 64 --compile -cudart static --compiler-options=/W4 --compiler-options= -Xcompiler="/EHsc -Zi -Ob0" -g -D_WINDOWS -D"FISH_BUILD_TYPE=\"DEBUG\"" -D"CMAKE_INTDIR=\"Debug\"" -D"CMAKE_INTDIR=\"Debug\"" -D_MBCS -Xcompiler "/EHsc /W3 /nologo /Od /Fdfish.dir\Debug\fish.pdb /FS /Zi /RTC1 /MDd /GR" -o fish.dir\Debug\fish_cuda.obj "C:\Users\eddi\Documents\temp\thur\sw\fish_cuda.cpp"
and with 3.15:
"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.1\bin\nvcc.exe" -gencode=arch=compute_30,code=\"compute_30,compute_30\" --use-local-env -ccbin "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\HostX86\x64" -x cu -IC:\Users\eddi\Documents\temp\thur\sw\include -IC:\Users\eddi\Documents\temp\thur\sw\shared\common\include -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.1\include" --keep-dir x64\Debug -maxrregcount=0 --machine 64 --compile -cudart static --compiler-options=/W4 --compiler-options= -Xcompiler="/EHsc -Zi -Ob0" -g -D_WINDOWS -D"FISH_BUILD_TYPE=\"DEBUG\"" -D"CMAKE_INTDIR=\"Debug\"" -D"CMAKE_INTDIR=\"Debug\"" -D_MBCS -Xcompiler "/EHsc /W1 /nologo /Od /Fdfish.dir\Debug\fish.pdb /FS /Zi /RTC1 /MDd /GR" -o fish.dir\Debug\fish_cuda.obj "C:\Users\eddi\Documents\temp\thur\sw\fish_cuda.cpp"
Spoiler: these are identical, except for the -Xcompiler "/EHsc /W3 /nologo /Od /Fdfish.dir\Debug\fish.pdb /FS /Zi /RTC1 /MDd /GR"
portion.
Try as I might, I cannot find where this set of flags is being introduced (by CMake et al.), and hence can't start working out how to change the behaviour.
EDIT1: Adding color to the story...
I grep'd my CMake install for /nologo
and found several .cmake
files with lines like:
35: set(CMAKE_CL_NOLOGO "/nologo")
I changed them all to variations of
35: set(CMAKE_CL_NOLOGO "/nologo_EDD")
But none of them turn up in the confusing set of options. So either I've missed something or they're being introduced from something outside CMake?
EDIT2: @squareskittles said:
you can remove the default flag from the CMAKE_CXX_FLAGS_INIT variable
Fair enough, I can see the logic to that: it's simple and it directly addresses my immediate issue. But it seems a bit blunt and doesn't address where the flags are coming from in the first place.
Anyway, objections aside, I added this ugly morsel to my script:
message( "--------------------------- ${CMAKE_CXX_FLAGS_INIT}")
string (REGEX REPLACE "/W[0-4]" "" CMAKE_CXX_FLAGS_INIT "${CMAKE_CXX_FLAGS_INIT}")
message( "--------------------------- ${CMAKE_CXX_FLAGS_INIT}")
With CMake 3.9, I see:
--------------------------- /DWIN32 /D_WINDOWS /W3 /GR /EHsc
--------------------------- /DWIN32 /D_WINDOWS /GR /EHsc
as hoped. But with 3.15, I see:
--------------------------- /DWIN32 /D_WINDOWS /GR /EHsc
--------------------------- /DWIN32 /D_WINDOWS /GR /EHsc
ie, the /W3
flag isn't there in the first place (let alone a /W1
flag) due to the policy change. But even worse, the primary issue still persists in both cases:
nvcc.exe ... --compiler-options=/W4 -Xcompiler="/EHsc -Zi -Ob0" ... -Xcompiler "/EHsc /W3 /nologo /Od /Fdfish.dir\Debug\fish.pdb /FS /Zi /RTC1 /MDd /GR" ...
EDIT3: Some progress! With this simple change:
#add_compile_options("$<$<COMPILE_LANGUAGE:CUDA>:--compiler-options=/W4>")
add_compile_options("$<$<COMPILE_LANGUAGE:CUDA>:-Xcompiler=/W4>")
there are no more complaints! The confusing flags persist, but now read:
-Xcompiler "/EHsc /W4 /nologo /Od /Ffish.dir\Debug\fish.pdb
/FS /Zi /RTC1 /MDd /GR"
ie. CMake has spotted the /W4
and overridden its default.
But despite scouring the CMake source, I've still yet to determine where all this is done.
EDIT4: MSVC has a hand in all this.
The 'mystery' options are generated somewhat automatically by MSVC from the .vcxproj
file. If I use the -Xcompile=/W4
approach, the project XML contains:
<CudaCompile>
...
<AdditionalOptions>%(AdditionalOptions) -Xcompiler="/EHsc -Zi -Ob1"</AdditionalOptions>
...
<Warning>W4</Warning>
</CudaCompile>
But with the original, --compiler-options=/W4
I get:
<CudaCompile>
<AdditionalOptions>%(AdditionalOptions) --compiler-options=/W4 -Xcompiler="/EHsc -Zi -Ob1"</AdditionalOptions>
...
</CudaCompile>
And this all sort of makes sense; with no Warning level specified, MSVC must default to W1, hence the complaint.
Also, there was a clue-with-hindsight: the build step had:
-Xcompiler="/EHsc -Zi -Ob0"
-Xcompiler "/EHsc /W1 /nologo /Od ..."
Note one has an equals and one does not implying they come from different places.
I think my investigation has gone far enough for now.
A TL;DR summary of my own shaggy-dog-tale of a question:
I had:
add_compile_options("$<$<COMPILE_LANGUAGE:CUDA>:--compiler-options=/W4>")
but found:
add_compile_options("$<$<COMPILE_LANGUAGE:CUDA>:-Xcompiler=/W4>")
to be more appropriate.
Basically, the CMake/NVCC/MSVC pipeline understood that the -Xcompiler
option overrode the default, but didn't realise that --compiler-options
was an equivalent statement, resulting in a command line with ambiguous directives.
这篇关于通过CMake通过NVCC传递给MSVC的令人困惑的标志的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!