As outlined in the CUDA 12.9 release notes sm_5X, sm_6X, and sm_70
are being removed in CUDA 13:
> Maxwell, Pascal, and Volta architectures are now feature-complete with
> no further enhancements planned. While CUDA Toolkit 12.x series will
> continue to support building applications for these architectures,
> offline compilation and library support will be removed in the next
> major CUDA Toolkit version release.
bf1bb62e74 macOS: Restore support for LLVM/Clang without explicit CMAKE_OSX_SYSROOT
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10734
a1b4c30f24 CUDA: Add CUDA 12.9 new architectures and family syntax
b2251e0deb CUDA/Clang: Update architectures supported by CUDA 12.8
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10738
In commit 7b19531291 (macOS: Do not pass any SDK/-isysroot to compilers
by default, 2024-11-06, v4.0.0-rc1~511^2) we broke support for using
upstream LLVM/Clang to build for macOS because the compiler has no
default sysroot. Handle empty `CMAKE_OSX_SYSROOT` with LLVM/Clang by
falling back to the macOS SDK reported by `xcrun --show-sdk-path` .
Fixes: #26863
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.
This makes the default CUDA architecture consistent across compilers,
and makes it more likely that the resulting binary will run on the
user's hardware.
This also makes hardware requirements for CI builds more consistent.
See commit 4f2178c4a8 (ci: add tags to tie CUDA jobs to runners with
hardware supporting them, 2025-04-21).
Since commit 7b19531291 (macOS: Do not pass any SDK/-isysroot to
compilers by default, 2024-11-06, v4.0.0-rc1~511^2) our default
invocation of compilers targeting macOS no longer passes `-isysroot`.
Without that, Xcode's compilers search `-L/usr/local/lib` by default
even though the macOS dynamic loader does not. Since `/usr/local/lib`
is not a fully-implemented implicit link directory, exclude it from our
detected `CMAKE_<LANG>_IMPLICIT_LINK_LIBRARIES` so that our generators
do not suppress `RPATH` entries for dependencies in that directory.
Fixes: #26867
In Xcode 7.3 and above, the `TEST_HOST` setting causes Xcode to
implicitly place the test module inside the executable bundle regardless
of the module's own location settings. Since commit a364d2513a (Xcode:
Fixup XCTest bundle location for Xcode 7.3, 2016-03-25, v3.5.2~6^2) we
explicitly tell CMake to put the test module in the same location so
that generator expressions used by `xctest_add_test` agree with where
Xcode actually puts it. In Xcode 16 and above, our explicit location
settings for the test module conflict with Xcode's `TEST_HOST` rules,
causing errors about multiple commands producing the same path.
Fix this by dropping CMake's explicit location for the test module
unless needed to match a project-specified location for the testee.
Instead, teach `xctest_add_test` to express the xctest module location
selected by `TEST_HOST` by using generator expressions referencing the
testee bundle.
Fixes: #26301Fixes: #26514
In commit f69b9b7305 (CUDAToolkit: Restore ability to find cupti
headers, 2023-12-08, v3.28.1~8^2) we did not update the CUPTI library
searches to add the extra search path needed for certain install layouts
(only the header search path). Add the additional library search paths.
Fixes: #26770
Issue: #25484
Commit 1a8e43d57d (FindPackageHandleStandardArgs: Clarify the FOUND_VAR
option, 2024-12-31, v4.0.0-rc1~247^2) simplified the
`<PackageName>_FOUND` and `<PACKAGENAME>_FOUND` variables one step
further but missed that this specific module sets the `QT4_FOUND`
variable also for the case where `find_package_handle_standard_args()`
isn't called (for example, when the found package is Qt3 or Qt5 and
later). Restore the `set()` call in case `QT4_FOUND` is used in the
code.
Previously we saved it in the cache, which:
* Persists even if a new version of CMake changes how the check works.
* Does not propagate to `try_compile` checks.
Export `tbss` (thread variable but part of `bss` section) variables, e.g.:
[125] m 0x00000010 .tbss 1 extern s2n_errno
[126] a4 0x00000004 0 0 CM UL - -
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
b3f1c60aff MSVC: Use -std:c++23preview flag for C++23 when available
1b4a802413 MSVC: Split C++23 flag selection into dedicated block
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10462
Add a missing `find_program` call to populate `RPM_EXECUTABLE`.
This was left out of two previous changes that intended to query
the `rpm` executable:
* In commit 9b53eca317 (CPack/RPM: Fix weak dep support, 2021-06-29,
v3.21.0-rc2~4^2), without `RPM_EXECUTABLE` the query always failed,
so we were concluding that weak dependencies are not supported even
when they are.
* In commit 488de6294a (CPack: correctly perform querytags on old
versions of RPM, 2025-01-09, v4.0.0-rc1~182^2~3), without
`RPM_EXECUTABLE` the query always failed. This change has not
yet been in a release anyway.
Also fix the test case for the "suggests" field to verify this.
Issue: #22350
Reported-by: Balazs Kosaras <balazskosaras@gmail.com>
`FindThreads` requires that C or CXX be enabled. Previously we were
only checking that `CMAKE_{C,CXX}_COMPILER` have been set, which does
not mean the languages have been enabled.
