Fixes#17559
Replace our hard-coded default of cudart=static with a first-class abstraction to select the runtime library from an enumeration of logical names.
Previously the CMake didn't compute the required set of libraries
needed to properly device link a static library when
CUDA_RESOLVE_DEVICE_SYMBOLS was enabled.
`CUDA_RESOLVE_DEVICE_SYMBOLS` can be used with shared, module, and
executable target types. This relaxation is to allow for better
interoperability with linkers that automatically do CUDA device symbol
resolution and have no way to disable it.
Convert the `CudaOnly.LinkSystemDeviceLibraries` test to a new
`Cuda.ProperDeviceLibraries` test. The former covered only the
`cublas_device` library which is removed by CUDA 10. Extend the new
test to also cover various cases of using threads.
Issue: #18008
Use `curand_static` to identify directories containing device libraries
because `cublas_device` is deprecated and will be removed in the future.
Issue: #18290
The nvcc device linker is designed so that each static library
with device symbols only needs to be listed once as it doesn't
care about link order. If you provide the same static library
multiple times it will error out. To make sure this occurs
we find the unique set of link items.
Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`. Use `clang-format` version 6.0.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
The CUDA Toolkit Visual Studio Integration does not honor the
`ClCompile.ProgramDataBaseFileName` field when telling `nvcc` how to
invoke `cl`. Work around this problem by passing `-Xcompiler=-Fd...`
ourselves through `AdditionalOptions`.
Fixes: #17647
Previously we dropped non-target items from the device link line because
nvcc rejects paths to shared library files, and only with target items
do we know the kind of library. However, this also prevents projects
from linking to system-provided libraries like `cublas_device` that
contain device code.
Fix this by passing more link items to device linking. Items that are
not file paths, such as `-lfoo`, can simply be passed unconditionally.
Items that are targets known to be shared libraries can still be
skipped. Items that are paths to library files can be passed directly
if they end in `.a`. Otherwise, pass them using `-Xnvlink` to bypass
nvcc's front-end. The nvlink tool knows to ignore shared library files.
Issue: #16317
506fda1c Genex: Enable COMPILE_LANGUAGE for INCLUDE_DIRECTORIES with VS and Xcode
c2f79c98 Genex: Enable COMPILE_LANGUAGE for COMPILE_DEFINITIONS with VS and Xcode
0795d25b cmVisualStudio10TargetGenerator: Factor out include dir computation
1ab4d186 cmLocalVisualStudio7Generator: Clarify variable name of compiled language
07e1a743 cmLocalVisualStudio7Generator: Clarify condition for target that compiles
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1657
The MSVC CUDA build customizations before CUDA 9 would not explicitly
add the -x cu option when building. This caused .cpp and .c files
invoked with CudaCompile to be compiled as host code and not
cuda. Now when we detect CUDA < 9 we will explicitly add this
option to correct this bug.
The set of compile flags used for a target's C and C++ sources is based
on the linker language. By default this is always the C++ flags if any
C++ sources appear in the target, and otherwise the C flags. Therefore
we can define the `COMPILE_LANGUAGE` generator expression in
`INCLUDE_DIRECTORIES` to match the selected language.
This is not exactly the same as for other generators, but is the best VS
and Xcode can do. It is also sufficient for many use cases since the
set of include directories for C and C++ is frequently similar but may
be distinct from those for other languages like CUDA.
Fixes: #17435
The set of compile flags used for a target's C and C++ sources is based
on the linker language. By default this is always the C++ flags if any
C++ sources appear in the target, and otherwise the C flags. Therefore
we can define the `COMPILE_LANGUAGE` generator expression in
`COMPILE_DEFINITIONS` to match the selected language.
This is not exactly the same as for other generators, but is the best VS
and Xcode can do. It is also sufficient for many use cases since the
set of definitions for C and C++ is frequently similar but may be
distinct from those for other languages like CUDA.
Issue: #17435
The previous version had two bugs that caused the JIT runtime errors.
1. It was building the executable without separable compilation enabled
2. All kernel launches will fail if any kernel is missing a symbol, that
is why the call to file2_launch_kernel had to be removed
2ae880fa Genex: Enable COMPILE_LANGUAGE for COMPILE_OPTIONS with Visual Studio
2b7d59f3 Genex: Enable COMPILE_LANGUAGE for file(GENERATE) with Visual Studio
0f6f7c8a Genex: Fix COMPILE_LANGUAGE messages to allow file(GENERATE) with Xcode
c5a82d0f Tests: Decouple COMPILE_LANGUAGE in file(GENERATE) from COMPILE_OPTIONS
25773650 Tests: Remove unnecessary result files from RunCMake.File_Generate
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Jason Juang <jasjuang@gmail.com>
Merge-request: !1511
Since commit v3.9.0-rc4~3^2~1 (VS: Fix target_compile_options for CUDA,
2017-06-21), the evaluation of `COMPILE_LANGUAGE` receives the proper
language. The set of compile flags used for a target's C and C++
sources is based on the linker language. By default this is always the
C++ flags if any C++ sources appear in the target, and otherwise the C
flags. Therefore we can define the `COMPILE_LANGUAGE` generator
expression in `COMPILE_OPTIONS` to match the selected language.
This is not exactly the same as for other generators, but is the best VS
can do. It is also sufficient for many use cases since the set of
allowed flags for C and C++ is almost the same in Visual Studio.
Furthermore, since the VS generator moves many of the flags to
declarative `.vcxproj` elements, it will automatically avoid passing
C++ flags for C sources.
Issue: #17435
The change in commit v3.9.0-rc4~3^2 (VS: Improve workaround for CUDA
-Xcompiler placement bug, 2017-06-21) accidentally appended to the
`AdditionalOptions` as if it were a `;`-separated list, but it is
actually a command-line string. Append with a space instead.
While at it, fix the same problem for the `AdditionalOptions` added to
`CudaLink` by commit v3.9.0-rc3~1^2 (CUDA: When linking device code
suppress CUDA 8.0+ deprecation warnings, 2017-06-09).
Fixes: #17008
In commit v3.9.0-rc1~431^2~6 (VS: Place CUDA host compiler options in
proper project file fields, 2017-03-07) we worked around a bug in the
CUDA VS integration by dropping `AdditionalCompilerOptions`. However,
this silently drops `-Xcompiler=` options given by the user that don't
map to one of CudaCompile's dedicated settings. Improve the workaround
to instead put the remaining `AdditionalCompilerOptions` into the
`AdditionalOptions` field behind `-Xcompiler=` ourselves.
Fix the VS generator to honor `COMPILE_OPTIONS` for CUDA. The exclusion
added by commit v3.9.0-rc1~431^2~7 (VS: Do not pass CUDA compile options
to C compiler, 2017-03-07) was correct but we need additional logic to
pass the CUDA compile options to the CUDA compiler. Also we should
still pass the CXX or C options to MSVC (ClCompile) when those languages
are enabled even if the link language is CUDA.
If a static library has the property CUDA_RESOLVE_DEVICE_SYMBOLS enabled
it will now perform the device link step. The normal behavior is
to delay calling device link until the static library is consumed by
a shared library or an executable.
CUDA 8.0 MSBuild rules do not pass `-x cu` to nvcc and so cannot support
a custom file extension. Fix our test for this to use a `.cu` extension
instead.
Add `.clang-format` configuration files for Cuda test directories that
use `Standard: Cpp11`. Otherwise clang-format splits the triple angle
brackets used for CUDA kernels.
