1. 07 Apr, 2021 1 commit
    • Brad King's avatar
      Makefiles: Fix dependency extraction with CUDA < 10.2 and host compiler · 8e38985d
      Brad King authored
      Since commit 2c71d051 (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 8981e3e7
      (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
      8e38985d
  2. 02 Dec, 2020 1 commit
  3. 29 Nov, 2020 1 commit
    • Marc Chevrier's avatar
      Makefiles Generators: use compiler for dependencies generation · 2c71d051
      Marc Chevrier authored
      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
      2c71d051
  4. 28 Nov, 2020 1 commit
    • Marc Chevrier's avatar
      Refactoring: Introduce place-holder for dependency target. · 3401403f
      Marc Chevrier authored
      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
      3401403f
  5. 02 Nov, 2020 1 commit
    • Jan Bernlöhr's avatar
      CUDA: Enable support on QNX · bcdd486b
      Jan Bernlöhr authored and Brad King's avatar Brad King committed
      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
      bcdd486b
  6. 26 Oct, 2020 1 commit
  7. 24 Sep, 2020 1 commit
  8. 24 Aug, 2020 1 commit
  9. 10 Jun, 2020 1 commit
  10. 21 May, 2020 1 commit
    • Robert Maynard's avatar
      CUDA: Compute CMAKE_CUDA_RUNTIME_LIBRARY default from toolchain · e55b21e2
      Robert Maynard authored and Brad King's avatar Brad King committed
      Since commit 0d014513 (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
      e55b21e2
  11. 15 May, 2020 1 commit
    • Raul Tambre's avatar
      CUDA: Add support for Clang compiler · 5df21adf
      Raul Tambre authored
      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
      5df21adf
  12. 19 Apr, 2020 2 commits
  13. 07 Apr, 2020 1 commit
  14. 11 Mar, 2020 1 commit
  15. 24 Feb, 2020 1 commit
    • Francisco Facioni's avatar
      Ninja: Do not use nvcc response files with non-nvcc tools · 738f3f23
      Francisco Facioni authored and Brad King's avatar Brad King committed
      Since commit d91b5a72 (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
      738f3f23
  16. 27 Jan, 2020 1 commit
  17. 03 Jan, 2020 1 commit
  18. 10 Dec, 2019 1 commit
  19. 29 Nov, 2019 2 commits
  20. 06 Aug, 2019 1 commit
  21. 03 Jun, 2019 1 commit
  22. 21 Jan, 2019 1 commit
    • Brad King's avatar
      CMakeDetermineCompilerABI: pass verbose flag during compilation · c765ae49
      Brad King authored
      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>
      c765ae49
  23. 07 Mar, 2018 1 commit
  24. 26 Sep, 2017 1 commit
    • Robert Maynard's avatar
      CUDA: Add support for requesting C++98 under CUDA 9 · fe37b994
      Robert Maynard authored and Brad King's avatar Brad King committed
      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).
      fe37b994
  25. 11 May, 2017 1 commit
  26. 15 Feb, 2017 1 commit
    • Brad King's avatar
      CUDA: Fix default compiler flags on Windows · 55fb46d2
      Brad King authored
      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++.
      55fb46d2
  27. 14 Feb, 2017 1 commit
  28. 12 Jan, 2017 1 commit
    • Brad King's avatar
      CUDA: Populate NVIDIA compiler information on Windows · 11551702
      Brad King authored
      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.
      11551702
  29. 09 Dec, 2016 1 commit
    • Brad King's avatar
      CUDA: Fix default compiler flag initialization · 7552d16d
      Brad King authored
      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`.
      7552d16d
  30. 14 Nov, 2016 5 commits