Since commit 474eafe28c (clang-cl: Add support for C++23, 2024-09-13,
v3.31.0-rc1~97^2) we use a Clang-specific flag to enable C++23 since
`clang-cl` has no `-std:c++23` flag, and `-std:c++latest` may enable an
even newer version of C++. However, in `.vcxproj` files there is no way
to express a target-wide `-clang:-std=c++23` flag for only C++ sources
when the target also has C sources. Add a special case to map back to
`-std:c++latest` for targets with C++23 and C together.
Fixes: #26508
De-duplicate IBMClang compiler information by detecting the base clang
version and following the same logic as we do for any other clang of
that version. This helps maintain support for new IBMClang features
inherited from new base Clang versions.
We already use this approach for other Clang variants, like CrayClang
and FujitsuClang.
Setting the `armlink --list` option without other diagnostic flags is
misleading because it produces an empty file and prevents the user from
printing diagnostics to the standard output or redirecting them to
another file.
It's unclear why the flag was added when support for ARMClang was first
added by commit 7b0abaac31 (ARMClang: Add support for Clang-based ARM
compiler, 2019-05-13, v3.15.0-rc1~111^2).
Fixes: #21538
We do this for other compiler/language combinations, but these flags
were left out by commit 5df21adf46 (CUDA: Add support for Clang
compiler, 2020-03-07, v3.18.0-rc1~145^2~1).
Although there is no `cl -std:c++23` flag, the underlying Clang compiler
does have a C++23 mode we can activate by passing `-std=c++23` through a
`clang-cl` wrapper flag.
Fixes: #26061
In commit 94df5b6ef1 (Tasking: Add support for several compiler
toolsets, 2022-07-20, v3.25.0-rc1~133^2) the extension mode flags were
added with an extra space-only argument. Remove it. Also fix the C++98
mode flag that looks like a C mode flag.
Fixes: #26244
When using the IAR Compiler without a license, CMake issues a
fatal error message about a missing linker and librarian.
This message is misleading.
In the previous detection, CMakeFindBinUtils.cmake would rely
on information collected from try_compile() which depends on a
working license.
In the new detection scheme, the IAR BinUtils are automatically
detected regardless of an existing license, based solely on the
compiler's path.
The failure point will be when trying to compile a C or a CXX
source file, where there will be no CMAKE_${lang}_COMPILER_VERSION
available.
This change improves the resulting message for when trying to use
the compiler without a license.
aff38fed4f ci: Add nightly jobs for LFortran on Fedora
a0def56402 ci: Add lfortran to Fedora base image
98d0f918ba LFortran: Add support for this compiler
c6f81bdacf Tests/RunCMake: Pass Fortran compiler id into more tests
fa1b748389 Tests/RunCMake/DependencyGraph: Specify Fortran function return type
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: scivision <michael@scivision.dev>
Acked-by: Matthew Thompson <fortran@gmail.com>
Merge-request: !9188
A new set of files are dedicated to linker configuration.
This set of files enable a fine-tuned configuration based of the linker
type as identified during compiler detection.
Fixes: #25360
While an `-fvisibility` flag was added in the previous version, it
throws warnings indicating it would be ignored unless given to the
linker and fails to work properly.
Tested on Solaris 11.3 SPARC and Solaris 11.4 x86/SPARC.
Add a variable to indicate the latest standard known to be supported for
each language:
* `CMAKE_C_STANDARD_LATEST`
* `CMAKE_CXX_STANDARD_LATEST`
* `CMAKE_CUDA_STANDARD_LATEST`
* `CMAKE_HIP_STANDARD_LATEST`
* `CMAKE_OBJC_STANDARD_LATEST`
* `CMAKE_OBJCXX_STANDARD_LATEST`
These variables, more generally referred to as
`CMAKE_<LANG>_STANDARD_LATEST`, are assigned an integer value which
represents the minimum between the latest version of the associated
language standard supported by the current compiler and the latest
version supported by CMake.
Add documentation for these variables in a new page called
`CMAKE_<LANG>_STANDARD_LATEST` was added under the "Variables for
Languages" section of the `cmake-variables(7)` page.
Update each compiler-specific CMake script under
`${CMAKE_ROOT}\Modules\Compiler` to manually define the relevant
`CMAKE_<LANG>_STANDARD_LATEST` variable as necessary. This will
require updating and maintaining as newer compiler versions become
recognized by CMake.
Closes: #25717
Set the requirement for Objective C 23 support for AppleClang to
`11.0.3` in `${CMAKE_ROOT}\Modules\Compiler\AppleClang-OBJC.cmake`.
This is consistent with the requirement for C 23 support as
indicated in `${CMAKE_ROOT}\Modules\Compiler\AppleClang-C.cmake`.
Unset irrelevant compile option variables in the following scripts:
* `${CMAKE_ROOT}\Modules\Compiler\ARMClang-C.cmake`
* `${CMAKE_ROOT}\Modules\Compiler\TIClang-C.cmake`
* `${CMAKE_ROOT}\Modules\Compiler\TIClang-CXX.cmake`
These scripts all include either
`${CMAKE_ROOT}\Modules\Compiler\Clang-C.cmake` or
`${CMAKE_ROOT}\Modules\Compiler\Clang-CXX.cmake`, and those scripts
will set various compile option variables based on what the
standard version of Clang supports. However, these do not
necessarily apply to ARMClang and TIClang. This commit thus
explicitly unsets all of the compile option variables which are not
manually defined for these compilers.
Fat LTO objects contain both traditional object code and the LTO bitcode
IR, but the GNU compiler does not support them on Apple platforms.
A compile error is raised when `-f[no-]fat-lto-objects` flags are used,
so avoid them.
This also implies that static Fortran libraries cannot be built with IPO.
Fixes: #25931
4af20bb794 NAG-Fortran: Do not repeat preprocessing with Ninja on Apple platforms
91bb8dd872 NAG-Fortran: Fix MODULE library creation on Apple platforms
e056006116 NAG-Fortran: Tell the Ninja generator how to preprocess Fortran sources
765a611956 NAG-Fortran: Added initial default compilation flags
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9407
Compilers may implement this by implementing a `_cmake_cxx_import_std`
function which takes the standard version as an argument (e.g., `23`)
and creating a target named `CMake::CXX${std}` that represents how
`import std;` should be represented within CMake.
