| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
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`.
|
| |
|
| |
|
| |
|
| |
|
|
|