LLVM/Clang 20, when invoked as `clang++ -E -c ...`, now warns:
warning: argument unused during compilation: '-c'
Drop the unnecessary `-c` flag. Also add a `-w` flag to suppress
warnings so their text is not parsed as predefines.
Revert commit b3f1c60aff (MSVC: Use -std:c++23preview flag for C++23
when available, 2025-03-12), except for the VS flag table update.
MSVC documentation states that the flag will be removed in the future
when `-std:c++23` is added. Therefore it is only suitable for manual
specification by end-users.
Issue: #26692
In commit cfa888a6e2 (Clang/CUDA: Add language-wide flags when linking
with compiler driver, 2024-10-07, v3.31.0-rc1~12^2) we added the wrong
placeholder to `CMAKE_CUDA_CREATE_SHARED_LIBRARY` to represent the
language-wide flags. The `<FLAGS>` placeholder is for executables.
The `<LANGUAGE_COMPILE_FLAGS>` placeholder is for shared libraries.
The distinction is for historical reasons.
Fixes: #26563
This was added in commit 98d0f918ba (LFortran: Add support for this
compiler, 2024-01-25, v3.31.0-rc1~303^2~2) because it is needed for
cases covered by CMake's Fortran tests. However, it does not work
with Fortran modules and breaks lfortran's own `examples/project1`.
Move the flag to the test cases that need it, just as the original
commit did with `--implicit-interface`.
Fixes: #26597
Co-authored-by: Brad King <brad.king@kitware.com>
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
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
