Since commit d44c0db0b2 (clang: setup correct configuration in gnu mode,
2019-02-20, v3.15.0-rc1~41^2~5) we support the GNU-like Clang that
targets the MSVC ABI. However, Clang cannot compile with the MSVC
standard library unless it runs in a mode aware of C++14 (since MSVC
itself does not even have a lower mode). When `CMAKE_CXX_STANDARD` is
set to 98 or 11, use C++14 anyway.
Since Clang's default mode is aware of C++14, another option is to not
add any flags for 98 or 11. However, if a future Clang version ever
defaults to a higher C++ standard, setting the standard to 98 or 11
should at least not use a mode higher than 14.
Also revert test updates from commit 4819ff9647 (Tests: fix failures
with gnu mode clang on windows, 2019-03-21, v3.15.0-rc1~41^2~3) that
were meant to work around the standard selection problem.
Fixes: #19496
b0bcd4d7d2 Fortran: Add support for submodules on Cray
33de4d27eb Fortran: Support compilers using no module prefix on submodule files
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3504
Define `CMAKE_Fortran_SUBMODULE_{SEP,EXT}` for the Cray Fortran
compiler. Use an empty separator to tell CMake that this compiler does
not use the enclosing module name as a prefix on submodule files.
Issue: #18925
74829f01b1 Help: Add notes for topic 'clang-gnulike-support'
19669abe1d Tests: handle string escaping differences with NMake+clang
a2a90f41e3 Tests: require C++14 for the Tutorial
4819ff9647 Tests: fix failures with gnu mode clang on windows
26af0b25e7 cmake: use correct stack size with gnu mode clang on windows
d44c0db0b2 clang: setup correct configuration in gnu mode
b7d5ef23e9 cmGlobalNinjaGenerator: use gnu compatible paths with clang in gnu mode
3d0210d8dc binutils: add the llvm-* variants to the tool lists.
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Francesco Bertolaccini <francesco@bertolaccini.dev>
Acked-by: Stanislav Ershov <digital.stream.of.mind@gmail.com>
Acked-by: Saleem Abdulrasool <compnerd@compnerd.org>
Merge-request: !2992
d156f8f5a2 CompileFeatures: Record when MSVC gained full CXX14 support
62dbe53a8a CompileFeatures: Record when Intel gained full CXX14 support
1ebb0d79fe CompileFeatures: Relax cxx_relaxed_constexpr compiler requirements
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3292
Use the infrastructure added by commit 646fb1a646 (CompileFeatures:
memoize C++ compilers with full language level support, 2019-03-27) to
avoid using a `try_compile` to check for C++14 feature support when the
running compiler is known to have all features.
Use the infrastructure added by commit 646fb1a646 (CompileFeatures:
memoize C++ compilers with full language level support, 2019-03-27) to
avoid using a `try_compile` to check for C++14 feature support when the
running compiler is known to have all features.
Use the infrastructure added by commit 646fb1a646 (CompileFeatures:
memoize C++ compilers with full language level support, 2019-03-27) to
avoid using a `try_compile` to check for C++14 feature support when the
running compiler is known to have all features.
Use the infrastructure added by commit 646fb1a646 (CompileFeatures:
memoize C++ compilers with full language level support, 2019-03-27) to
avoid using a `try_compile` to check for C++14 feature support when the
running compiler is known to have all features.
Use the infrastructure added by commit 646fb1a646 (CompileFeatures:
memoize C++ compilers with full language level support, 2019-03-27) to
avoid using a `try_compile` to check for C++11 feature support when the
running compiler is known to have all features.
In commit 8e4899fd6c (CompileFeatures: Record which C features the MSVC
compiler supports, 2019-04-12) our `cmake_record_c_compile_features`
macro was accidentally left not setting the `_result` variable, which
had previously been set by `_record_compiler_features`. The variable is
expected by the call site in `cmake_determine_compile_features` and used
to switch between "failed" and "done" reports. Set it now.
Also record `c_variadic_macros` only for cl 14 (VS 2005) and higher
because it is not supported before that version.
SunPro 5.15 supports `-std=c++14` and several C++14 features.
SunPro 5.14 accepts `-std=c++14` but does not update its definition of
`__cplusplus` or any other macro to distinguish it from `-std=c++11`,
so we need to blacklist a couple features that do work but that we
cannot report for that version. We can still support `cxx_std_14`.
Co-Author: Robert Maynard <robert.maynard@kitware.com>
Use the infrastructure added by commit f92ccbc306
(CompileFeatures: memoize C compilers with full language level support)
to avoid using a `try_compile` to check for C 90/99/11 feature support when the running compiler is known to have a fixed set of feature support.
Use the infrastructure added by commit 646fb1a646 (CompileFeatures:
memoize C++ compilers with full language level support, 2019-03-27) to
avoid using a `try_compile` to check for C++98 feature support when the
running compiler is known to have all features.
613ac56e50 Add a test to verify meta-feature parity with granular features
b0f46c48f6 CompileFeatures: Now able to presume full language level support
646fb1a646 CompileFeatures: memoize C++ compilers with full language level support
0d641fcfad Tests: Remove outdated portion of CompileFeatures genex test
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3176
Previously compilers that only supported the meta-level flags
would not have any of the granular features listed. Now we
presume that they have full support and enable all the features.
Update granular feature tests to skip the actual compilation
checks for the presumed features.
Previously compilers that had full support for a language standard level
were still verified every time a new build directory was created. Now
we record this information and insert the correct granular compile
features instead of doing a `try_compile`.
