-- Detect GHS compiler and version
Detect ARCHITECTURE_ID for PPC / ARM / 86 targets
Detect PLATFORM_ID for Integrity and Integrity178 platforms
Using defines specified in the documents for the compilers: 201416 PPC / 201754 ARM / 201714 86
-- Fallback C/CXX compiler ID to GHS if not otherwise detected and using GHS MULTI generator
Works around issue with some GHS compilers not setting __ghs__ compiler define
-- Tweak Compiler ID checking so major id of 002017 is not replaced with 217
-- Prefer try_compile() library targets when testing for working GHS compilers
-- Avoid CMake errors if reading past end of file for checking if file is PE executable
-- Do not use CMAKE_C_FLAGS_RELEASE flags when CMAKE_BUILD_TYPE is empty
if CMAKE_BUILD_TYPE was not set the generator would use Release settings
this does not match the documented behavior of CMAKE_BUILD_TYPE
-- CMAKE_C_FLAGS_<CONFIG> not used when -kernel is present
Fixes issue where CMAKE_C_FLAGS_<CONFIG> is ignored when -kernel option is present as a compiler option
When the -kernel option is added to an executable it uses a different set of language flags
This does not occur -kernel=<type> is used or if it is added as part of a link flag
The variables CMAKE_<LANG>_GHS_KERNEL_FLAGS_<CONFIG> are removed
NOTE: By default this only added the flag -ldebug which links in the debugger library.
-- Separate compiler options by newlines
-- add missing executable linker libs from:
CMAKE_C_STANDARD_LIBRARIES
-- add missed transitive link libraries
-- add skipped library linker options
-- The linker expects -l../relative/path/to/lib.a to be relative to the top-level project
Because there can be multiple top-level projects convert the path to an absolute path to target
-- Set output and object file locations
-- Suffixes are no longer being forced but will now follow the target properties
By default GHS tools have no suffix for executable files so
CMAKE_EXECUTABLE_SUFFIX was changed to meet this behavior
-- Remove #if 0 blocked out code; it has been replaced.
Forcing the -relprog option has been removed from non-kernel executable targets.
The default value of this option (if it is even available) is determined by the
tool-chain for the specified target and platform (Some tool-chains default to
-locatedprogram). The use of -relprog can have unexpected results as it cannot
always produce a fully relocated executable.
-- Clarify use of CMAKE_BUILD_TYPE to control build configuration
By default, we generate an export list for a shared library and pass
that file on the link line. The problem was that it could not be
overridden by a target when a specific export file is being used.
Multiple `-bE` flags on the link are overridden by subsequent `-bE`
flags, so only the last one is used.
Fixes: #13282
Tested compiler detection with the QNX 7.0 list of compiler targets:
* gcc_ntoaarch64le
* gcc_ntoaarch64le_cxx
* gcc_ntoarmv7le
* gcc_ntoarmv7le_cxx
* gcc_ntox86_cxx
* gcc_ntoaarch64le_gpp
* gcc_ntox86_64_gpp
* gcc_ntoarmv7le_gpp
* gcc_ntox86_64_cxx
* gcc_ntox86
* gcc_ntox86_gpp
* gcc_ntox86_64
This commit fixes some of the problems described in:
https://cristianadam.eu/20181202/a-better-qnx-cmake-toolchain-file/
Running flang with `-E` now ignores any `-o` option and always prints
preprocessed output to stdout. Use shell redirection to place it in a
file instead.
Fixes: #18497
If these are not detected then we cannot support the IAR compiler.
Fail early with an explicit message instead of silently proceeding
and getting strange errors.
Issue: #18333
AUTOMOC used to fail to generate ``moc_predefs.h`` when ``ccache`` was used
as a compiler starter by e.g. configuring a project with the environment
variable CXX="ccache g++".
The reason was that ``CMAKE_<LANG>_COMPILER_ARG1`` wasn't respected in the
definition of ``CMAKE_<LANG>_COMPILER_PREDEFINES_COMMAND`` for various
compilers. This is fixed by this patch.
Fixes#17275.
The XL compiler does not have a dedicated "pie" option so use at least
`-qpic`. This missing setting was exposed by the `ExportImport` and
`PositionIndependentTargets` tests with XL on an ELF platform.
In commit v3.12.0-rc1~20^2 (Move GNU COMPILER_PREDEFINES_COMMAND from
Platform to Compiler, 2018-06-01), `Compiler/GNU.cmake` introduced the
`-dM` flag, which requires `-Wp` prefix for the QNX compiler wrapper.
Intel compilers define `__cpp_constexpr` to `200704` even in C++14 mode.
This indicates that the `cxx_relaxed_constexpr` feature is not
available. However, Intel 17 and above document support for it. In
commit v3.8.0~9^2 (Features: Update features for Intel C++ 17.0.2 on
UNIX, 2017-03-31) we added a special check for this case. Intel 17 and
19 work. However, Intel 18 does not seem to work and fails our test
case. Add a special case to disable the feature for Intel 18.
Moves `CMAKE_${lang}_COMPILER_PREDEFINES_COMMAND` from linux specific
[Modules/Platform/Linux-GNU.cmake](Modules/Platform/Linux-GNU.cmake) to
[Modules/Compiler/GNU.cmake](Modules/Compiler/GNU.cmake).
This enables compiler predefines generation (in AUTOMOC) on all
platforms that run gcc (and clang).
3f82c5904d Clang: Add standard flags support when simulating MSVC
8381bc12ad Clang: Avoid extra C++ feature detection when simulating MSVC
6cddf7ba32 Clang: Refactor standard flags logic when simulating MSVC
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1906
Apply the optimization from commit v3.10.0-rc1~131^2 (MSVC: Avoid
unnecessary C++ feature detection steps, 2017-09-11) to the case of
Clang simulating a version of MSVC that does not define standards.
Issue: #17274
VS 15.3 has more features than we recorded in commit v3.7.0-rc1~156^2~2
(Features: Record features for VS 15 Preview 4, 2016-09-05).
While at it, update comments and simplify some cases.
Android NDK r16b comes with
Android clang version 5.0.300080 (based on LLVM 5.0.300080)
Although it claims version 5, it does not support the `-std=c++17`
or `-std=c++2a` flags that upstream Clang does.
Android NDK r17-beta1 comes with
Android (4639204 based on r316199) clang version 6.0.1
that does have the flags.
8570dc7f64 Help: Update compiler versions in cmake-compile-features.7.rst
874d3d2948 Help: Add release note for C++ 20 support
7f295b1bd3 Features: Activate C++ 20 support for Clang 5.0+
71cb8ce3a1 Features: Activate C++ 20 support for GNU 8.0+
8f146c4508 Features: Activate C++ 20 support for MSVC 19.12.25835+
7fe580a362 Features: Add infrastructure for C++ 20 language standard
1b328e09a3 Features: Use -std=c++17 for C++ 17 on Clang 5.0+
0bc3e5788a Features: Use -std=c++17 for C++ 17 on GNU 8.0+
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1892
The MSVC C compiler has no notion of C language standards or flags.
Tell CMake to assume that all language standards are available.
Record available C language features depending on the version of
the compiler.
Fixes: #17858
Features recorded by commit v3.6.0-rc1~120^2~5 (Features: Record
standards and features for Intel C++ on UNIX, 2016-04-28) for the Intel
compiler left out initializer list support because our test case in
`Tests/CompileFeatures/cxx_generalized_initializers.cpp` caused an
internal compiler error. It turns out this is because the Intel
compiler asserts the `initializer_list` constructor signatures to verify
that they match its own `<initializer_list>` header. It was our dummy
implementation used to test the language feature without any headers
that caused the ICE. Revise it to use a constructor signature accepted
by the Intel compiler.
Fixes: #17829
