b365385d66 Clang: Record Clang 6.0+ as fully supporting C++17
5d26efe38f Clang: Add final C++20 flag for Clang 11.0+
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4887
74b1c9fc8e Explicitly specify language flag when source LANGUAGE property is set
457170a476 CXX: Compile when possible with explicit `Cxx` language flag set
644d3b86eb C: Compile when possible with explicit `C` language flag set
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4780
__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.
allows cmake to fall back to CMAKE_SYSTEM_ARCH in case CMAKE_SYSTEM_PROCESSOR is not in armclang -mcpu=list
additionally checks if CMAKE_SYSTEM_PROCESSOR belongs to armlink --cpu=list
Fixes: #19962
The PCH settings are shared by C and CXX languages but do not make sense
for Fortran. In particular, `CMAKE_PCH_EXTENSION` should not be set
because it can overwrite the value set for C/C++ languages, which may
have a different compiler vendor than the Fortran compiler.
Fixes: #20752
GitLab now uses a `/-/` component between the `group/project` part of
the URL and the `{issues,merge_requests,tree}` part so that it can
support `group/subgroup/project` with arbitrary depth.
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
65c1320719 Compiler/TI: Fix C++ toolchain command-lines
4110d9dffb Compiler/TI: Fix linker command line for C++
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4627
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
These standard flags are the same for CXX, OBJCXX and CUDA.
Refactor them into a single macro to reduce duplication and so we can easily reuse them.
Updated bootstrap script to search in the general Clang module instead of the language-specific.
46d9006efa XL: Add comment clarifying why we pretend it has full C++11/14 support
4aaa9ea96c XL: C++14 language level flags are only available on Linux
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4551
Since commit b0f46c48f6 (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
Since commit 458ea9d76c (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
9728839b9e ASM: Fix executable link lines with GNU 'as' tool as CMAKE_ASM_COMPILER
5932f0be4f ASM: Fix depfile flags for GNU 'as' tool
0d0aa98c84 ASM: Record vendor-specific output matched to identify assembler
ee3ec27465 CMakeDetermineCompilerId: Set locale to C for vendor output match
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4460
The GNU `as --help` shows `--MD <file>` as an option to generate depfiles
as needed by Ninja. There is no `-MT <target>` flag but fortunately the
generated files automatically account for the `-o <obj>` flag.
Issue: #20426
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
