summaryrefslogtreecommitdiffstats
path: root/Modules/Compiler/NVIDIA-CUDA.cmake
Commit message (Collapse)AuthorAgeFilesLines
* Makefiles: Fix dependency extraction with CUDA < 10.2 and host compilerBrad King2021-04-071-1/+9
| | | | | | | | | | | | | | | | | Since commit 2c71d051fa (Makefiles Generators: use compiler for dependencies generation, 2020-10-18, v3.20.0-rc1~392^2) we invoke `nvcc` for CUDA < 10.2 a second time in order to generate a depfile. When `CMAKE_CUDA_HOST_COMPILER` is set, the second invocation is missing its `-ccbin=` option, even after refactoring in commit 8981e3e7cc (NVIDIA-CUDA: rely on new capabilities for deps generation, 2020-12-02, v3.20.0-rc1~362^2). Ideally we should move the `-ccbin=` flag into `Compiler/NVIDIA-CUDA`, but that will add `CMAKE_CUDA_HOST_COMPILER` support on Windows in command-line generators but not the Visual Studio generators. For now, add the flag to the depfile command specifically. Fixes: #22037
* NVIDIA-CUDA: rely on new capabilities for deps generationMarc Chevrier2020-12-021-4/+3
|
* Makefiles Generators: use compiler for dependencies generationMarc Chevrier2020-11-291-0/+8
| | | | | | | | | | | Each source compilation generates a dependencies file. These dependencies files are consolidated in one file per target. This consolidation is done as part of command 'cmake -E cmake_depends` launched before evaluation of makefile dependency graph. The consolidation uses the same approach as `CMake` dependencies management. Fixes: #21321
* Refactoring: Introduce place-holder for dependency target.Marc Chevrier2020-11-281-1/+1
| | | | | | | | These changes are in preparation of compiler generated dependencies support for Makefiles generators * compiler output and dependency target can be different for Makefiles generators * resolve inconsistency naming for dependency file place-holder
* CUDA: Enable support on QNXjanbernloehr2020-11-021-1/+1
| | | | | | | | | | | 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
* CUDA: Use MSVC version to determine supported C++ standard levelsRobert Maynard2020-10-261-4/+11
| | | | Fixes: #21335
* CUDA: Clang separable compilationRaul Tambre2020-09-241-0/+1
| | | | | | | | | | | | 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
* CUDA: Support setting CUDA14/17 when using MSVCRobert Maynard2020-08-241-4/+6
| | | | Fixes #20953
* CUDA: Teach CMake that NVCC 11 supports cuda_std_17Robert Maynard2020-06-101-0/+11
|
* Merge branch 'backport-cuda-default-runtime' into cuda-default-runtimeBrad King2020-05-221-1/+0
|\
| * CUDA: Compute CMAKE_CUDA_RUNTIME_LIBRARY default from toolchainRobert Maynard2020-05-211-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | CUDA: Add support for Clang compilerRaul Tambre2020-05-151-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | CUDA: Device linking use now link optionsMarc Chevrier2020-04-191-0/+5
| | | | | | | | | | | | | | | | | | | | 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
* | CUDA: Add information for LINKER: pattern translationMarc Chevrier2020-04-191-0/+8
| |
* | CUDA: Refactor PTX compilation flag into compiler modulesRaul Tambre2020-04-071-0/+1
| |
* | CUDA: Abstract language flag to compiler modulesRaul Tambre2020-03-111-0/+2
|/ | | | | Separate this detail out into compiler-specific modules. Required for Clang support, as it uses slightly different language flags.
* Merge branch 'backport-cuda-non-device-link'Brad King2020-02-241-1/+1
|\
| * Ninja: Do not use nvcc response files with non-nvcc toolsFrancisco Facioni2020-02-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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
* | CUDA: Add abstraction for cuda runtime selectionRobert Maynard2020-01-271-0/+5
| | | | | | | | | | 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.
* | CUDA: Fix compiler option version checks for nvcc 10.2.19Raul Tambre2020-01-031-2/+2
| |
* | CUDA: Add cuda meta-features (e.g. ``cuda_std_11``) supportRobert Maynard2019-12-101-6/+19
| |
* | CUDA: get header deps from compiler invocation when possibleRobert Maynard2019-11-291-0/+7
| | | | | | | | | | Before CUDA 10.2 `nvcc` didn't support providing header dependency information while compiling.
* | CUDA: forward unknown flags to host compiler when possible.Robert Maynard2019-11-291-0/+16
| | | | | | | | | | | | | | | | | | | | 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.
* | CUDA: Compilers can now state they don't require a device linking stepRobert Maynard2019-08-061-0/+1
|/
* Ninja: Add support for CUDA nvcc response filesFrancisco Facioni2019-06-031-0/+5
|
* CMakeDetermineCompilerABI: pass verbose flag during compilationBrad King2019-01-211-0/+1
| | | | | | | | | | 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>
* CUDA: Do not pass unsupported @rspfile arguments to NVCCBrad King2018-03-071-0/+6
| | | | | | | The nvcc compiler does not support `@<rspfile>` arguments. It does offer a `--options-file` argument that can be investigated later. Fixes: #17797
* CUDA: Add support for requesting C++98 under CUDA 9Robert Maynard2017-09-261-0/+2
| | | | | | | | | 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: Add support for the C++14 standard flag.Robert Maynard2017-05-111-0/+6
| | | | | CUDA 9 toolkit has announced support for C++14 flag, so lets allow users to use it.
* CUDA: Fix default compiler flags on WindowsBrad King2017-02-151-6/+5
| | | | | | | 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++.
* CUDA: Do not use non-existent -Os flag for nvccBrad King2017-02-141-1/+1
| | | | | Fix the CUDA MinSizeRel configuration flags to avoid using the `-Os` flag that nvcc does not support.
* CUDA: Populate NVIDIA compiler information on WindowsBrad King2017-01-121-13/+17
| | | | | | | 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.
* CUDA: Fix default compiler flag initializationBrad King2016-12-091-5/+5
| | | | | | | 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`.
* CUDA: Refactor CMakeCUDAInformation to prepare for separable compilation.Robert Maynard2016-11-141-0/+5
|
* CUDA: Use the host compiler for linking CUDA executables and shared libs.Robert Maynard2016-11-141-2/+4
|
* CUDA: We now properly perform CUDA compiler identification.Robert Maynard2016-11-141-1/+1
|
* CUDA: Add support language levels (98/11)Robert Maynard2016-11-141-6/+7
|
* CUDA: Add basic CUDA language support for *NIX systems.Robert Maynard2016-11-141-0/+16
generated by cgit v0.12 at 2025-02-12 08:17:29 (GMT)