If you believe this "bug with
cl" is something that should be addressed by
nvcc, you are free to file a bug with NVIDIA. There should be a sticky note at the top of this forum on how to do that.
If the root cause of the issue is something that
cl does incorrectly, the correct course of action seems to be to file a bug with Microsoft, as it is always preferable to fix root causes, not add layers of workarounds. More people filing bug reports on the same issue could move the bug up in the priority list.
Looking more closely at
nvcc builds with MSVC, it does seem to add a
-Zi to the response file it passes to
nvcc is invoked with
-g, indicating a debug build. And if one manually adds an
-Xcompiler /Z7, this is inserted in the response file before the
-Zi, which means the latter overrides the former and one winds up with
The main difference between
/Z7 is that the former dumps the debug information into a separate
.pdb file, while the latter dumps it directly into the
.obj object file. The linker can later collect the debug information from the object files into a
.pdb file when it creates the executable. Therefore, specifying
/Z7 could have an impact on build times and debugger functionality. Whether it has a negative impact on the CUDA toolchain, I cannot say.
If I recall correctly, the distinction between
/Z7 was introduced with Microsoft’s first 32-bit toolchain (Microsoft C/C++ Optimizing Compiler 8) in 1993, where
/Z7 was for backwards compatibility with version 7 of that compiler. Which leads me to believe that
/Z7 invokes a less capable legacy mode.
I would suggest filing an enhancement request with NVIDIA (using the bug reporting mechanism) to let a user-specified
/Zi (maybe by simply changing the order in which compiler flags are added to the response file) and see what they come back with.