| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
This fixes the following two issues with the CUDA support on QNX:
* cuda target name is not derived correctly (should be `aarch64-qnx`).
* linking `cudart` must not be linked against `rt`, `dl`, `pthread`.
This enables to use cmake's native cuda support on QNX.
Fixes: #21381
|
| |
|
|
| |
Fixes: #21335
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For NVCC the compiler takes care of device linking when passed the "-dlink"
flag.
Clang doesn't support such magic and requires the buildsystem to do the work
that NVCC does behind the scenes.
The implementation is based on Bazel's device linking documentation:
https://github.com/tensorflow/tensorflow/blob/7cabcdf073abad8c46e9dda62bb8fa4682d2061e/third_party/nccl/build_defs.bzl.tpl#L259
Closes: #20726
|
| |
|
|
| |
Fixes #20953
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since commit 0d0145138f (CUDA: Add abstraction for cuda runtime
selection, 2019-11-29, v3.17.0-rc1~83^2) we add CUDA runtime library
selection flags by default.
To maintain backwards compatibility the default CUDA runtime
library needs to be computed based on what libraries are found
on the initial compiler invocation. For example a toolchain
could establish initial flags that have all CUDA compilations
using the runtime version, and if we don't detect this we will
try to link to both the static and shared runtime.
Co-Author: Brad King <brad.king@kitware.com>
Fixes: #20708
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When crosscompiling we pass the sysroot.
We need to try various architecture flags. Clang doesn't automatically
select one that works. First try the ones that are more likely to work
for modern installations:
* <=sm_50 is deprecated since CUDA 10.2, try sm_52 first for
future compatibility.
* <=sm_20 is removed since CUDA 9.0, try sm_30.
Otherwise fallback to Clang's current default. Currently that's `sm_20`,
the lowest it supports.
Separable compilation isn't supported yet.
Fixes: #16586
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
properties LINK_OPTIONS and INTERFACE_LINK_OPTIONS are propagated
to the device link step.
To control which options are selected for normal link and device link steps,
the $<DEVICE_LINK> and $<HOST_LINK> generator expressions can be used.
Fixes: #18265
|
| | | |
|
| | | |
|
| |/
|
|
|
| |
Separate this detail out into compiler-specific modules.
Required for Clang support, as it uses slightly different language flags.
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since commit d91b5a72cd (Ninja: Add support for CUDA nvcc response
files, 2019-05-30, v3.15.0-rc1~8^2) we use NVCC's `--options-file`
option to avoid long link command lines via a response file. However,
for non-device linking the host tools are used and the option does not
make sense. Update the logic to use `--options-file` only for device
linking. Linking with the host tools already has its own logic for
response files.
Fixes: #19954
|
| | |
| |
| |
| |
| | |
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.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
Before CUDA 10.2 `nvcc` didn't support providing header dependency
information while compiling.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Starting with CUDA 10.2 the nvcc compiler has gained support
to automatically forward unknown flags to the host compiler.
This behavior is highly desired as projcts that mix CUDA, C, C++
run into situation where flags such as `-pthread` which aren't
supported by nvcc, are being applied to all source files and
therefore break CUDA compilation.
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Default to the same flag that is used for verbose link information, but
provide another internal platform information variable to use a
compilation-specific variant. Populate it for CUDA where we use a
different compiler for compilation and linking and therefore need
different flags.
Co-Author: Chuck Cranor <chuck@ece.cmu.edu>
|
| |
|
|
|
|
|
| |
The nvcc compiler does not support `@<rspfile>` arguments. It does
offer a `--options-file` argument that can be investigated later.
Fixes: #17797
|
| |
|
|
|
|
|
|
|
| |
Starting in CUDA 9 the default compilation mode is C++14, and you need
to explicitly enable C++98/03 mode.
While at it, document `14` among the values for `CUDA_STANDARD`. This
was accidentally left out of commit v3.9.0-rc1~118^2 (CUDA: Add support
for the C++14 standard flag, 2017-05-11).
|
| |
|
|
|
| |
CUDA 9 toolkit has announced support for C++14 flag, so lets allow users
to use it.
|
| |
|
|
|
|
|
| |
Fix the default values of `CMAKE_CUDA_FLAGS[_<CONFIG>]` on Windows to
make the host compiler flags match those produced for C++ by the
`Platform/Windows-MSVC` module. This makes the flags consistent with
those used for C++.
|
| |
|
|
|
| |
Fix the CUDA MinSizeRel configuration flags to avoid using the `-Os`
flag that nvcc does not support.
|
| |
|
|
|
|
|
| |
Port Windows-specific compilation and linking rules over from the
`Platform/Windows-MSVC` module and adapt it for NVIDIA CUDA. On Windows
nvcc and its host compiler (MSVC) do not understand or use options like
`-fPIC` or `-std=`, so condition those out.
|
| |
|
|
|
|
|
| |
Since commit v3.7.0-rc1~392^2 (Honor CMAKE_<LANG>_FLAGS[_<CONFIG>]_INIT
set in toolchain files, 2016-07-05) our convention is to initialize
compiler flag variables via `string(APPEND)` rather than `set()`.
Fix the convention for `CMAKE_CUDA_FLAGS[_<CONFIG>]_INIT`.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
