1. 26 Jun, 2020 1 commit
  2. 18 Jun, 2020 1 commit
  3. 13 Jun, 2020 2 commits
  4. 10 Jun, 2020 1 commit
  5. 09 Jun, 2020 2 commits
  6. 08 Jun, 2020 1 commit
    • Raul Tambre's avatar
      CUDA: Fix Clang depfile flags when simulating MSVC · 0f88b7a5
      Raul Tambre authored
      __compiler_clang() doesn't call __compiler_gnu() if we're emulating MSVC. Thus
      CMAKE_DEPFILE_FLAGS_CUDA remains unset and compiling doesn't work, due to NVCC
      dependency injection workaround in CMakeCUDAInformation.cmake, which triggers
      for Ninja if they're not set.
      Always set the depfile flags to fix this. Most other compiler modules seem to
      do the same.
  7. 03 Jun, 2020 1 commit
  8. 02 Jun, 2020 2 commits
  9. 01 Jun, 2020 1 commit
  10. 26 May, 2020 1 commit
  11. 21 May, 2020 2 commits
    • Peter Hill's avatar
      Fortran: Add Fortran_PREPROCESS property · b0a61611
      Peter Hill authored
      Issue: #18870
    • Robert Maynard's avatar
      CUDA: Compute CMAKE_CUDA_RUNTIME_LIBRARY default from toolchain · e55b21e2
      Robert Maynard authored
      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
  12. 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
  13. 28 Apr, 2020 2 commits
  14. 19 Apr, 2020 2 commits
  15. 18 Apr, 2020 2 commits
  16. 07 Apr, 2020 3 commits
  17. 31 Mar, 2020 2 commits
    • Brad King's avatar
      XL: Add comment clarifying why we pretend it has full C++11/14 support · 46d9006e
      Brad King authored
      Since commit b0f46c48 (CompileFeatures: Now able to presume full
      language level support, 2019-03-06, v3.15.0-rc1~265^2~1) we pretend that
      the XL compiler has full C++11 and C++14 support so that projects
      specifying granular features will at least get the corresponding
      compiler mode.  This is a work around for our lack of a full feature
      check table for this compiler that works in common cases.  Add a comment
      explaining this.
      Issue: #20521
    • Brad King's avatar
      XL: C++14 language level flags are only available on Linux · 4aaa9ea9
      Brad King authored
      Since commit 458ea9d7 (XL: Add C++14 language level flags, 2019-04-15,
      v3.15.0-rc1~226^2) we use `-qlanglvl=extended1y` for C++14 with XL 16.1.
      However, that flag is only supported on a Linux host.
      Issue: #20521
  18. 26 Mar, 2020 1 commit
  19. 23 Mar, 2020 1 commit
  20. 13 Mar, 2020 2 commits
  21. 12 Mar, 2020 1 commit
  22. 11 Mar, 2020 1 commit
  23. 09 Mar, 2020 1 commit
  24. 28 Feb, 2020 1 commit
    • Brad King's avatar
      XL: Fix using Fortran modules from their output directory · 210b0b99
      Brad King authored
      The XL Fortran compiler's `-qmoddir=` flag sets the module output
      directory but does not add the directory to the search path for using
      modules.  This is inconsistent with other compilers like the GNU Fortran
      compiler's `-J` flag that does both.  In order to make these consistent,
      add the module output directory with a `-I` flag on the XL Fortran
      compiler so that it will be searched when using modules too.
      This fixes our `FortranModules` test's coverage of submodules on
      Ninja + XL.  That test places module files in a subdirectory that with
      Ninja is not the current working directory when the compiler runs.
      Fixes: #20400
  25. 24 Feb, 2020 2 commits
    • Francisco Facioni's avatar
      Ninja: Do not use nvcc response files with non-nvcc tools · 738f3f23
      Francisco Facioni authored
      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
    • Sergey Larin's avatar
      PCH: Clang: Update PCH usage flags to include original header · 5c6d6ec2
      Sergey Larin authored
      Add an additional include flag to PCH usage command line to fix programs
      that rely on `compile_commands.json` file. Pass it to the preprocessor
      directly to avoid compiler driver to change it to '-include-pch'.
      When preprocessor is requested to preprocess a file, it tries to get
      the original filename from '.pch' and uses that file for preprocessing.
      CMake generates a '.pch' file from the '.hxx' file by passing an empty
      '.cxx' source file to the compiler as a compilation unit and the header
      file with the '-include' flag. After that, compiler puts compilation
      unit filename in the '.pch' as the original filename.
      However, CMake build system uses empty file as the source file and
      passes the header file using '-include-pch' flag. As a result, Clang
      uses the wrong file for preprocessing and produces the corrupted
      preprocessed file.
      Fixes: #20355Signed-off-by: Sergey Larin's avatarSergey Larin <cerg2010cerg2010@mail.ru>
  26. 27 Jan, 2020 3 commits
    • Robert Maynard's avatar
      CUDA: Add abstraction for cuda runtime selection · 0d014513
      Robert Maynard authored
      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.
    • skelly-energid's avatar
      QNX: Add support for CMAKE_SYSROOT · 32a6ab1f
      skelly-energid authored
      QCC is a wrapper around GCC, but it is not a fully transparent wrapper.
      Some compile options need to be passed to GCC using a `-Wc` option.
      QCC does not support --sysroot, so setting CMAKE_SYSROOT in a toolchain
      file currently does not work.  This means that it is likely that no one
      is setting CMAKE_SYSROOT in existing QNC toolchain files.  Override the
      GCC option for sysroot in the QCC.cmake file with -Wc,-isysroot.
      This exposes a further issue in that the QNX SDK does not follow the
      same architectural folder structure as linux uses.  That is, on linux
      systems, architecture-specific libraries might be in
      such as
      CMake models this by suffixing the <arch> onto lib directories when
      searching for libraries.
      The QNX SDK is structured differently such that the <arch> should be
      used as a prefix:
      such as
      Add a variable for platform configuration to set whether to prefix or
      suffix the <arch> and set that in the QCC.cmake.
      Use the directory structure of the QNX SDK to compute the <arch> from
      the implicit library directories.  The assumption is that the arch will
      be a single directory directly below the CMAKE_SYSROOT, below which the
      usr/ prefix occurs.
      It would not be appropriate to instruct users to make the <arch> part of
      the sysroot when specified in the toolchain file because:
      1.  That would be non-DRY - The QCC wrapper already determines the <arch>
          by the -V argument passed to the compiler, specified in the toolchain
          file as the CMAKE_C_COMPILER_TARGET variable.
      2.  The includes in the QNX SDK are not below the <arch> directory.
      So, the location of the <arch> in the full path is different on QNX
      compared to, say an embedded linux platform, but the intent is the same.
      Add documentation to recommend the use of CMAKE_SYSROOT in a QNX
      toolchain file.
      As the CMAKE_SYSROOT is always the same for QNX, it would be possible to
      simply set it in QCC.cmake.  However, that would change behavior for
      existing users as when CMAKE_SYSROOT is set, files/paths outside of the
      CMAKE_SYSROOT do not get found.
      The <arch> prefixing is only enabled in cmSearchPath.cxx if
      CMAKE_SYSROOT is set.  This ensures that the user gets consistency in
      the current state without CMAKE_SYSROOT, and gets better consistency
      when using CMAKE_SYSROOT.
    • Hanjiang Yu's avatar
      clang-tidy: Add driver mode argument · f6f4eb09
      Hanjiang Yu authored
      `clang-tidy` does not infer driver mode if it is not provided with a
      JSON compilation database.  This is exactly the way cmake launches it.
      Hence clang-tidy will only use the default driver mode.  Add an explicit
      driver mode argument to avoid this.