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
Revert commit 887f3a88a6 (Intel: Add Intel DPC++ compiler
identification, 2020-09-21, v3.19.0-rc1~124^2). The compiler has
already been released, and is more usable with CMake by pretending to be
upstream Clang than by identifying it as a compiler for which we have
not implemented support.
Fixes: #21551
Revert commit 5c3a93ab88 (Intel: Add Intel Clang compiler
identification, 2020-09-29, v3.19.0-rc1~68^2). The compiler has already
been released, and is more usable with CMake by pretending to be
upstream Clang than by identifying it as a compiler for which we have
not implemented support.
Issue: #21551
48aac247e9 Compile with explicit language flag when source LANGUAGE property is set
2e67a75acd Embarcadero: Simplify addition of -P flag for C++
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5522
This change was originally made by commit 74b1c9fc8e (Explicitly specify
language flag when source LANGUAGE property is set, 2020-06-01,
v3.19.0-rc1~722^2), but it was reverted by commit 30aa715fac (Revert
"specify language flag when source LANGUAGE property is set",
2020-11-19) to restore compatibility with pre-3.19 behavior.
Implement the change again, but add policy CMP0119 to make this change
while preserving compatibility with existing projects.
Note that the `Compiler/{Clang,Intel,MSVC}-CXX` modules do not need to
specify `-TP` for their MSVC-like variants because we already use the
flag in `CMAKE_CXX_COMPILE_OBJECT`. Similarly for `Compiler/XL-CXX`
and `Platform/Windows-Embarcadero`.
Note also that this does not seem possible to implement for XL C.
Even with `-qsourcetype=c`, `xlc` complains about an unknown suffix:
`1501-218 (W) file /.../AltExtC.zzz contains an incorrect file suffix`.
It returns non-zero even with `-qsuppress=1501-218`.
Co-Author: Robert Maynard <robert.maynard@kitware.com>
Fixes: #14516, #20716
2c71d051fa Makefiles Generators: use compiler for dependencies generation
afd0f6785d Refactoring: Abstract Makefile line continuation format
b6068ce407 Refactoring: enhance include file filtering
3401403f69 Refactoring: Introduce place-holder for dependency target.
a97c41bf8b Refactoring: Makefiles Generators: Add support for various depends scanners
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Brad King <brad.king@kitware.com>
Merge-request: !5528
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
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
Rename the `CheckPIESupported` helper functions so that they
don't clobber other internal functions. Also rename them to
document they can't be unified with `CheckCompilerFlag`.
Fixes: #21497
Revert commit 74b1c9fc8e (Explicitly specify language flag when source
LANGUAGE property is set, 2020-06-01, v3.19.0-rc1~722^2) and the lookup
tables from its two immediate ancestors. The purpose of that change was
to convert an explicit `LANGUAGE` source file property into an explicit
language specification compiler flag like `-x c`. This seems reasonable
since the property is documented as meaning "indicate what programming
language the source file is". It is also needed to help compilers deal
with non-standard source file extensions they don't recognize.
However, some projects have been setting `LANGUAGE C` on `.S` assembler
source files to mean "use the C compiler". Passing `-x c` for them
breaks the build because the `.S` sources are not written in C. These
projects should be updated to use `enable_language(ASM)`, for which
CMake often chooses the C compiler as the assembler when using
toolchains that support it (which would have to be the case for projects
using the approach).
Revert the change for now to preserve the old behavior for such projects.
We can re-introduce it with a policy in a future version of CMake.
Fixes: #21469
Issue: #14516, #20716
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
