The compile options `--march=<arch>` and `--mcpu=<cpu>` and the
link option `--cpu=<cpu>` are automatically added by CMake based
on `CMAKE_SYSTEM_PROCESSOR` or `CMAKE_SYSTEM_ARCH`. But this is not
sufficient, because armclang also supports enabling or disabling
features using `+<feature>`:
-mcpu=<name>[+[no]<feature>+...]
For example:
-mcpu=cortex-a57+nocrypto+nofp+nosimd+crc
(Reference: https://developer.arm.com/documentation/dui0774/k/Compiler-Command-line-Options/-mcpu?lang=en)
The problem is, even if a project adds a flag with features it needs,
CMake still adds flags, resulting in code that is compiled with wrong
CPU features and unable to run.
Add policy `CMP0123` to not automatically add compile or link options,
and let projects set them instead.
Co-Author: Brad King <brad.king@kitware.com>
Fixes: #21173
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
This should be front end compatible with vanilla clang but giving it a
unique identifier allows a project to pass additional options unique to
Fujitsu and outside the scope of a CMake builtin.
Cray 11.0 adds support for preprocessing with output written to a
specified file (instead of always next to the source). Use it to
enable Cray Fortran with the Ninja generator.
Patch-by: James Elliott
Fixes: #20731
005e2cdfb0 Android: Do not use gold for ndk >= r22
ed7a87f270 Tests: Update RunCMake.Android for NDK r22
4950d35733 Help: Document CMAKE_ANDROID_NDK_VERSION variable
746906242d Android: Detect NDK version number
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5862
C11 was made default in LLVM commit ab506adf7d3ced6abcaf42f92de3d6cd15fa19e8,
released in 3.5.2.
C99 was made default in LLVM commit 17f76e04d244c80e70f1c81c94d4524b53d9772d,
released in 2.1. It was flipped a few times between C89 and C99 during the 2.1
cycle, but the C89 default never made it into a release.
C89, C99 flags in LLVM commit ff43821d5380ee38aff421701f1d461242b524ee.
C90 flag in LLVM commit 229ce60fc9983df5f7e83e25fa6b5c0ca4d2b135.
C1x flag in LLVM commit a686b5f8bf7b5a2ab636c0c2de5ad4c174aa33e0.
C11 flag in LLVM commit 6784aeb9ef96e5735850fa7226ed0cb45cb82e75.
Mark C90, C99 full support since 2.1. Might've been possibly a little later,
but source spelunking that much back is difficult.
Mark C11 full support since 3.0, which added _Static_assert in LLVM commit
3d9cbdc3e66e274d5d3cb94ce81a65478d9baae0.
The PGI ( and NVIDIA HPC ) compilers default C++ standard level
are based on the GCC system headers it is compiling against.
Therefore on newer platforms the default C++ level will be >= 11
and requesting C++98 compilation mode will fail as no explicit
flag will be set.
In commit 4620cf77f2 (Clang: Remove unused CUDA implicit link variables,
2021-02-14) we removed some references. It turns out they are non-empty
and necessary if using a non-scattered installation.
Fixes: #21863
The NAG Fortran compiler's `-mdir` 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 NAG Fortran
compiler so that it will be searched when using modules too.
We already do this for the XL Fortran compiler since commit 210b0b99a9
(XL: Fix using Fortran modules from their output directory, 2020-02-28,
v3.18.0-rc1~640^2~1).
c9244f369a IntelLLVM: Make explicit Fortran preprocessing under Ninja more robust
056d4bf528 Merge branch 'backport-intel-fortran-preprocess'
af074c266e Intel: Make explicit Fortran preprocessing under Ninja more robust
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5826
Tell the Fortran compiler to write preprocessor output directly to a
file, as we do for the GNU compiler. The previous "redirect stdout"
approach could break during ABI detection with some `mpif90` wrappers
that add version information to stdout when called with `-v`.
Issue: #21828
Tell the Fortran compiler to write preprocessor output directly to a
file, as we do for the GNU compiler. The previous "redirect stdout"
approach could break during ABI detection with some `mpif90` wrappers
that add version information to stdout when called with `-v`.
Fixes: #21828
`clang-cl` supports the `-imsvc` flag to tell the compiler an include
directory is intended for system paths. `icx` does not accept this
flag, even on MSVC platforms, so do not tell CMake that it exists.
Fixes: #21801
Signed-off-by: william.r.dieter <william.r.dieter@intel.com>
In commit bb61c2d024 (Clang: use -imsvc for system include dirs when
running on Windows, 2020-09-16, v3.19.0-rc1~162^2) we added `-imsvc`
for all Clang compilers targeting the MSVC ABI. However, the option
only exists for the MSVC-like front-end. The GNU-like front-ends
use `-isystem`.
Fixes: #21789
Using a single ID 'IntelLLVM' for the suite of Intel compilers based on
the LLVM backend. The 'IntelLLVM' ID are used for C, C++, and Fortran.
Data Parallel C++ will be handled in a separate commit.
The C and C++ definitions are based on the Clang definitions. The Intel
LLVM-based C and C++ compilers are based on the Clang front end, so
existing Clang options are more likely to be a good match than options
for the older Intel compilers.
Fortran is based on the older Fortran front end with the LLVM backend.
It has a similar interface to the older versions, though many options
are shared with the C and C++ compilers.
Fixes: #21561
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
Identify the compilers as `NVHPC` to distinguish it from the older PGI
compilers from which they evolved, and from other `NVIDIA` compilers.
Fixes: #20887
