CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2024-03-13T05:21:50-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/25763CUDA: Separable compilation fails with Clang and native/all/all-major archs2024-03-13T05:21:50-04:00Garima GuptaCUDA: Separable compilation fails with Clang and native/all/all-major archsCMake fails when CMAKE_CUDA_ARCHITECTURES is set to native, all or all-major with Clang for targets with CUDA_SEPARABLE_COMPILATION setting as ON, then cmake does not detect correct value for architecture
When env is clang and CMAKE_CUD...CMake fails when CMAKE_CUDA_ARCHITECTURES is set to native, all or all-major with Clang for targets with CUDA_SEPARABLE_COMPILATION setting as ON, then cmake does not detect correct value for architecture
When env is clang and CMAKE_CUDA_ARCHITECTURES is set to native, all, or all-major then targets which has CUDA_SEPARABLE_COMPILATION set to ON, gives error because it uses architecture as sm_native if native is set and sm_all if all or all-major is set for CMAKE_CUDA_ARCHITECTURES
The targets which are set with CUDA_SEPARABLE_COMPILATION as ON, calls internally in cmake "cmMakefileExecutableTargetGenerator::WriteDeviceExecutableRule" function in file cmMakefileExecutableTargetGenerator.cxx (https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5221/diffs#47db539af92be7d459f78d00c444a672f76bc133)
```
if (this->Makefile->GetSafeDefinition("CMAKE_CUDA_COMPILER_ID") == "Clang") {
this->WriteDeviceLinkRule(commands, targetOutput);
} else {
this->WriteNvidiaDeviceExecutableRule(relink, commands, targetOutput);
}
```
so when env is gnu, then it calls WriteNvidiaDeviceExecutableRule which does not use CMAKE_CUDA_ARCHITECTURES variable but when env is clang, it calls WriteDeviceLinkRule and it uses the value of CMAKE_CUDA_ARCHITECTURES variable. And this does not find the exact architecture value when CMAKE_CUDA_ARCHITECTURES is native, all or all-major.https://gitlab.kitware.com/cmake/cmake/-/issues/25731CMake does not support C++20 modules with clang-cl.exe2024-03-05T06:02:25-05:00Sharadh RajaramanCMake does not support C++20 modules with clang-cl.exeSupplying `CMAKE_CXX_COMPILER=clang-cl` with a target containing `FILE_SET CXX_MODULES` does not work, and during configuration, CMake errors with:
```
CMake Error in CMakeLists.txt:
The target named "main" has C++ sources that may us...Supplying `CMAKE_CXX_COMPILER=clang-cl` with a target containing `FILE_SET CXX_MODULES` does not work, and during configuration, CMake errors with:
```
CMake Error in CMakeLists.txt:
The target named "main" has C++ sources that may use modules, but the
compiler does not provide a way to discover the import graph dependencies.
See the cmake-cxxmodules(7) manual for details. Use the
CMAKE_CXX_SCAN_FOR_MODULES variable to enable or disable scanning.
```
`clang-cl.exe` is in fact _exactly_ (read: bit-for-bit equal, and therefore have equal file checksums) the same binary as `clang.exe` in the official LLVM distribution for Windows, with only differing file names. It is able to [forward arguments to the GNU-style driver with `/clang:`](https://github.com/llvm/llvm-project/blob/051e910b8b6c59fc94d019fa01ae4507b1c81498/clang/docs/UsersManual.rst#L4397), and therefore [straightforwardly supports C++20 module compilation](https://discourse.llvm.org/t/clang-cl-exe-support-for-c-modules/72257/28) equally as well as the latter.https://gitlab.kitware.com/cmake/cmake/-/issues/25637CMake fails to configure CUDA using clang++-142024-01-26T08:10:49-05:00Eyal Rozenbergeyalroz1@gmx.comCMake fails to configure CUDA using clang++-14<sub>(Filed following [this SO answer](https://stackoverflow.com/a/77879291/1593077).)</sub>
I'm trying to configure a build with the following list file:
```
cmake_minimum_required(VERSION 3.24)
project(vector_addition_with_clang CUDA)...<sub>(Filed following [this SO answer](https://stackoverflow.com/a/77879291/1593077).)</sub>
I'm trying to configure a build with the following list file:
```
cmake_minimum_required(VERSION 3.24)
project(vector_addition_with_clang CUDA)
add_executable(vectorAdd vectorAdd.cu)
set_target_properties(vectorAdd PROPERTIES CUDA_ARCHITECTURES native)
```
and with the following command-line:
```
cmake -B build -DCMAKE_CUDA_HOST_COMPILER=clang++-14 -DCMAKE_CUDA_COMPILER=clang++-14
```
Now, if I replace clang++-14 with clang++-16, everything works fine. But with clang++-14 (and with `--debug-output`), I get:
```
-- The CUDA compiler identification is unknown
Called from: [3] /opt/versions/cmake/3.28.1/share/cmake-3.28/Modules/CMakeDetermineCompilerId.cmake
[2] /opt/versions/cmake/3.28.1/share/cmake-3.28/Modules/CMakeDetermineCUDACompiler.cmake
[1] /tmp/1_vector_addition/CMakeLists.txt
CMake Error at /opt/versions/cmake/3.28.1/share/cmake-3.28/Modules/CMakeDetermineCUDACompiler.cmake:270 (message):
Failed to detect a default CUDA architecture.
Compiler output:
Call Stack (most recent call first):
CMakeLists.txt:2 (project)
Called from: [2] /opt/versions/cmake/3.28.1/share/cmake-3.28/Modules/CMakeDetermineCUDACompiler.cmake
[1] /tmp/1_vector_addition/CMakeLists.txt
-- Configuring incomplete, errors occurred!
```
I get the same output if I replace the `native` architecture choice with a concrete value, e.g. `61`, corresponding to that of a GPU on my system.
Artifacts:
* Project source file and CMake list file: [bug_25637.tar.gz](/uploads/005559aa43ff689857481c6dc7d71e69/bug_25637.tar.gz)
* Trace file: [`trace.log.gz`](/uploads/1a3fd8e4cce07af9709eb87ca9d2421d/trace.log.gz)
* Build dir: [build_dir.tar.gz](/uploads/104e516554028d6f168ca6c7e362e853/build_dir.tar.gz)
System info:
* Devuan GNU/Linux Excalibur (like Debian Trixie but without systemd)
* CMake 3.28.1 binary distribution
* X86_64 machine
* CUDA 12.2 installed under /usr/local/cudahttps://gitlab.kitware.com/cmake/cmake/-/issues/25449macOS: CMake uses a mix of tools provided by LLVM and Apple while compile wit...2023-11-29T10:41:03-05:00Kuntal MajumdermacOS: CMake uses a mix of tools provided by LLVM and Apple while compile with vanilla LLVMWhile compiling blender on macOS (m1 pro) with llvm-17 installed via homebrew, it complained that the static library could not be recognised.
Here is the warning during compilation which hints about using a wrong format for the static li...While compiling blender on macOS (m1 pro) with llvm-17 installed via homebrew, it complained that the static library could not be recognised.
Here is the warning during compilation which hints about using a wrong format for the static library,
```
ld: warning: ld: warning: ignoring file lib/libbf_dna.a, building for macOS-arm64 but attempting to link with file built for unknown-unsupported file format ( 0x21 0x3C 0x61 0x72 0x63 0x68 0x3E 0x0A 0x2F 0x20 0x20 0x20 0x20 0x20 0x20 0x20 )
```
After a bit of digging, I found out, while CMake used the 'llvm-ranlib' for CMAKE_RANLIB, for CMAKE_AR it was using '/usr/bin/ar' and not 'llvm-ar'. Which after [those](https://github.com/blender/blender/blob/01a2bd03695f217616acc2581fe8746f5cd226d7/build_files/cmake/platform/platform_apple.cmake#L431) particular flags, produce an archive which can't be read by LLVM.
On further looking into CMake, I ran into the commit which disable loading of llvm-ar on apple platforms, which cited issues with the Apple linker. But according to [this](https://discourse.llvm.org/t/how-stable-is-ld64-lld/69628/8) comment, ld64.lld should be a drop in replacement for the Apple linker.https://gitlab.kitware.com/cmake/cmake/-/issues/25277VS: custom LLVM location and version for ClangCL toolset2023-09-27T09:30:24-04:00yuryburaVS: custom LLVM location and version for ClangCL toolsetHow to let CMake know to use custom LLVM location and version for ClangCL toolset?
MS provides the following solution:
https://learn.microsoft.com/en-us/cpp/build/clang-support-msbuild?view=msvc-170#custom_llvm_location
But this is no ...How to let CMake know to use custom LLVM location and version for ClangCL toolset?
MS provides the following solution:
https://learn.microsoft.com/en-us/cpp/build/clang-support-msbuild?view=msvc-170#custom_llvm_location
But this is no good because during CMake generation the LLVM path will be incorrect (default for VS).https://gitlab.kitware.com/cmake/cmake/-/issues/25180[clang-scan-deps] [C++] [modules] Calculate resouce_directoty in case the use...2023-10-29T22:42:18-04:00Chuanqi Xu[clang-scan-deps] [C++] [modules] Calculate resouce_directoty in case the users pass compiler executable by symlink<!--
This issue tracker is for CMake upstream development:
* If you are having trouble building a specific third-party project
that uses CMake, ask for help in that project's forums first.
* If you have a coding or usage question, pl...<!--
This issue tracker is for CMake upstream development:
* If you are having trouble building a specific third-party project
that uses CMake, ask for help in that project's forums first.
* If you have a coding or usage question, please ask for help
on the CMake discourse forums: https://discourse.cmake.org/
-->
By default, the clang-scan-deps have problems to find headers from the resource dir like (`stddef.h`) if the provided compiler exectuable is a symlink instead of a real compiler. (See https://github.com/llvm/llvm-project/issues/61006 for history).
Then we updated the corresponding solution in https://clang.llvm.org/docs/StandardCPlusPlusModules.html#possible-issues-failed-to-find-system-headers but it doesn't work automatically. The solution requires the build systems to update the ways the invoke `clang-scan-deps`.
If we don't fix the issue, the user may have a bad experience since in many distributions the compiler `clang++` is a symlink.https://gitlab.kitware.com/cmake/cmake/-/issues/24970Clang: Support the new --gcc-install-dir option2023-06-12T05:48:29-04:00nolangeClang: Support the new --gcc-install-dir optionClang 16 comes with a nice new option [`--gcc-install-dir`](https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-gcc-install-dir). Long story short, this is the first time I can just rather easily use clang with an ...Clang 16 comes with a nice new option [`--gcc-install-dir`](https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-gcc-install-dir). Long story short, this is the first time I can just rather easily use clang with an gcc installation (without manually adding multiple options for include/lib/tools paths).
The older `--gcc-toolchain` switch [got deprecated](https://discourse.llvm.org/t/add-gcc-install-dir-deprecate-gcc-toolchain-and-remove-gcc-install-prefix/65091) at the same time.
The state of CMake is that it supports the deprecated switch via [`CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN`](https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_COMPILER_EXTERNAL_TOOLCHAIN.html).
of course some `CMAKE_<LANG>_COMPILER_EXTERNAL_INSTALL_DIR` variable would be a start, but I am not sure this would be the most elegant.
`gcc` will output the correct path to be used with `-print-search-dirs`, so "chaining" a gcc toolchain would be the most practical:
``` cmake
include(GCC_TOOLCHAIN_PATH)
execute_process(COMMAND ${CMAKE_C_COMPILER} -print-search-dirs
OUTPUT_VARIABLE gcc_install_dir
RESULT_VARIABLE _result)
if (NOT _result EQUAL "0")
message(FATAL_ERROR "Failed fetching install path from gcc ${_result}")
endif()
string(REGEX MATCH "^install:[ \t]*([^\r\n]*)" gcc_install_dir "${gcc_install_dir}" )
set(gcc_install_dir "${CMAKE_MATCH_1}")
set(CMAKE_C_COMPILER "/usr/bin/clang")
set(CMAKE_CXX_COMPILER "/usr/bin/clang++")
set(CMAKE_EXE_LINKER_FLAGS_INIT "$CMAKE_EXE_LINKER_FLAGS_INIT --gcc-install-dir=${gcc_install_dir}")
set(CMAKE_MODULE_LINKER_FLAGS_INIT "$CMAKE_MODULE_LINKER_FLAGS_INIT --gcc-install-dir=${gcc_install_dir}")
set(CMAKE_SHARED_LINKER_FLAGS_INIT "$CMAKE_SHARED_LINKER_FLAGS_INIT --gcc-install-dir=${gcc_install_dir}")
set(CMAKE_C_FLAGS_INIT "${CMAKE_C_FLAGS_INIT} --gcc-install-dir=${gcc_install_dir}")
set(CMAKE_CXX_FLAGS_INIT "${CMAKE_CXX_FLAGS_INIT} --gcc-install-dir=${gcc_install_dir}")
unset(gcc_install_dir)
```
Perhaps some module providing this functionality, would be just 2 lines then:
``` cmake
include(GCC_TOOLCHAIN_PATH)
include(ClangUseGccToolchain)
```https://gitlab.kitware.com/cmake/cmake/-/issues/24943CUDA: Clang fails due to GNU extensions flag -std=gnu++172023-05-26T14:11:54-04:00Burlen LoringCUDA: Clang fails due to GNU extensions flag -std=gnu++17When using `clang++` as the `CMAKE_CUDA_COMPILER` and `CMAKE_CUDA_STANDARD 17` CMake enables GNU language extensions via `-std=gnu++17` and as a result CMake fails with
```
-- Check for working CUDA compiler: /home/bloring/work/llvm/llvm...When using `clang++` as the `CMAKE_CUDA_COMPILER` and `CMAKE_CUDA_STANDARD 17` CMake enables GNU language extensions via `-std=gnu++17` and as a result CMake fails with
```
-- Check for working CUDA compiler: /home/bloring/work/llvm/llvm-install/bin/clang++ - broken
CMake Error at /usr/share/cmake/Modules/CMakeTestCUDACompiler.cmake:100 (message):
The CUDA compiler
"/home/bloring/work/llvm/llvm-install/bin/clang++"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /work/SENSEI/HAMR/bin_cpu/CMakeFiles/CMakeScratch/TryCompile-hL0tKr
Run Build Command(s):/usr/bin/cmake -E env VERBOSE=1 /bin/gmake -f Makefile cmTC_027ff/fast && /bin/gmake -f CMakeFiles/cmTC_027ff.dir/build.make CMakeFiles/cmTC_027ff.dir/build
gmake[1]: Entering directory '/work/SENSEI/HAMR/bin_cpu/CMakeFiles/CMakeScratch/TryCompile-hL0tKr'
Building CUDA object CMakeFiles/cmTC_027ff.dir/main.cu.o
/home/bloring/work/llvm/llvm-install/bin/clang++ -std=gnu++17 --cuda-gpu-arch=sm_52 --cuda-path=/usr/local/cuda-12.0 -fPIE -MD -MT CMakeFiles/cmTC_027ff.dir/main.cu.o -MF CMakeFiles/cmTC_027ff.dir/main.cu.o.d -x cuda -c /work/SENSEI/HAMR/bin_cpu/CMakeFiles/CMakeScratch/TryCompile-hL0tKr/main.cu -o CMakeFiles/cmTC_027ff.dir/main.cu.o
clang++: warning: CUDA version is newer than the latest partially supported version 11.8 [-Wunknown-cuda-version]
In file included from <built-in>:1:
In file included from /home/bloring/work/llvm/llvm-install/lib/clang/17/include/__clang_cuda_runtime_wrapper.h:41:
In file included from /home/bloring/work/llvm/llvm-install/lib/clang/17/include/cuda_wrappers/cmath:27:
In file included from /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/cmath:47:
/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/std_abs.h:103:7: error: __float128 is not supported on this target
abs(__float128 __x)
^
/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/std_abs.h:102:3: error: __float128 is not supported on this target
__float128
^
/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/std_abs.h:103:18: note: '__x' defined here
abs(__float128 __x)
^
/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/std_abs.h:103:18: note: '__x' defined here
/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/std_abs.h:103:18: note: '__x' defined here
In file included from <built-in>:1:
In file included from /home/bloring/work/llvm/llvm-install/lib/clang/17/include/__clang_cuda_runtime_wrapper.h:41:
In file included from /home/bloring/work/llvm/llvm-install/lib/clang/17/include/cuda_wrappers/cmath:27:
In file included from /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/cmath:1935:
In file included from /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/specfun.h:45:
In file included from /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_algobase.h:64:
In file included from /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_pair.h:60:
/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/type_traits:436:39: error: __float128 is not supported on this target
struct __is_floating_point_helper<__float128>
^
In file included from <built-in>:1:
In file included from /home/bloring/work/llvm/llvm-install/lib/clang/17/include/__clang_cuda_runtime_wrapper.h:41:
In file included from /home/bloring/work/llvm/llvm-install/lib/clang/17/include/cuda_wrappers/cmath:27:
In file included from /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/cmath:1935:
In file included from /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/specfun.h:45:
/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_algobase.h:1048:21: error: __float128 is not supported on this target
__size_to_integer(__float128 __n) { return (long long)__n; }
^
4 errors generated when compiling for sm_52.
gmake[1]: *** [CMakeFiles/cmTC_027ff.dir/build.make:79: CMakeFiles/cmTC_027ff.dir/main.cu.o] Error 1
gmake[1]: Leaving directory '/work/SENSEI/HAMR/bin_cpu/CMakeFiles/CMakeScratch/TryCompile-hL0tKr'
gmake: *** [Makefile:127: cmTC_027ff/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:77 (enable_language)
-- Configuring incomplete, errors occurred!
```
Adding `set(CMAKE_CUDA_EXTENSIONS OFF)` to my CMake lists works around this issue.
I see 2 issues with the current CMake behavior, 1) applying the GNU extensions with Clang is not safe thing to do as the above error illustrates the Clang CUDA compiler doesn't fully support the GNU extensions. 2) more generally when I set `CMAKE_<LANG>_STANDARD XX` I am not expecting compiler specific extensions but rather the base standard. the default for compiler specific extensions to the language standard should be off, one needs to ask to get them not the other way.
cmake version 3.26.2
clang version 17.0.0https://gitlab.kitware.com/cmake/cmake/-/issues/24243clang-cl: Drive linking via compiler front-end2023-06-12T11:03:53-04:00Alexander Neumannclang-cl: Drive linking via compiler front-endI would like to use clang-cl as `CMAKE_LINKER` to not have to manually link the adresse/ubsan libs. After changing the default Windows-MSVC platform file to have
```
set(CMAKE_${lang}_LINK_EXECUTABLE
"${_CMAKE_VS_LINK_EXE}<CMAKE...I would like to use clang-cl as `CMAKE_LINKER` to not have to manually link the adresse/ubsan libs. After changing the default Windows-MSVC platform file to have
```
set(CMAKE_${lang}_LINK_EXECUTABLE
"${_CMAKE_VS_LINK_EXE}<CMAKE_${lang}_COMPILER> ${CMAKE_CL_NOLOGO} <FLAGS> <CMAKE_${lang}_LINK_FLAGS> <OBJECTS> /link ${CMAKE_START_TEMP_FILE} /out:<TARGET> /implib:<TARGET_IMPLIB> /pdb:<TARGET_PDB> /version:<TARGET_VERSION_MAJOR>.<TARGET_VERSION_MINOR>${_PLATFORM_LINK_FLAGS} <LINK_FLAGS> <LINK_LIBRARIES>${CMAKE_END_TEMP_FILE}")
```
I got it to pass the compiler detection (`try_compile`) but the build itself fails even though I adjusted:
```
set(CMAKE_${lang}_CREATE_SHARED_LIBRARY
"${_CMAKE_VS_LINK_DLL}<CMAKE_${lang}_COMPILER> ${CMAKE_CL_NOLOGO} <FLAGS> <CMAKE_${lang}_LINK_FLAGS> <OBJECTS> /link ${CMAKE_START_TEMP_FILE} /out:<TARGET> /implib:<TARGET_IMPLIB> /pdb:<TARGET_PDB> /dll /version:<TARGET_VERSION_MAJOR>.<TARGET_VERSION_MINOR>${_PLATFORM_LINK_FLAGS} <LINK_FLAGS> <LINK_LIBRARIES> ${CMAKE_END_TEMP_FILE}")
```
It fails due to missing linkage to the sanitizer libs. From the build log I have to assume that the placeholders `<FLAGS> <CMAKE_${lang}_LINK_FLAGS>` are not getting expanded and added to the build (e.g. `-- C:\PROGRA~1\LLVM\bin\clang-cl.exe /nologo <should_have_flags_here_but_here_is_empty_space> CMakeFiles\zlib.dir\adler32.c.obj`)
Since I basically copied the changes from the IntelLLVM Platform I am wondering how that is supposed to work there ;)
(could also be related to #23773)https://gitlab.kitware.com/cmake/cmake/-/issues/24025VS: Use ClangCL toolset with coverage flag2023-09-27T09:51:55-04:00gatkinsoVS: Use ClangCL toolset with coverage flagWindows 10
Visual Studio 17 2022 Community Edition (bug also appears in Visual Studio 2019 Professional)
It appears that cmake generates an invalid MSVC solution/project file(s) when using the integrated LLVM
toolkit. Resultant coverag...Windows 10
Visual Studio 17 2022 Community Edition (bug also appears in Visual Studio 2019 Professional)
It appears that cmake generates an invalid MSVC solution/project file(s) when using the integrated LLVM
toolkit. Resultant coverage files have no file name only a suffix, resulting in errors generating coverage data.
While searching for workaround for issue in https://gitlab.kitware.com/cmake/cmake/-/issues/24021
I ran the following:
```
PS C:\Users\me\source\scratch\build> cmake -T ClangCL -D COVERAGE:BOOL=ON ..
-- Building for: Visual Studio 17 2022
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19044.
-- The C compiler identification is Clang 14.0.5 with MSVC-like command-line
-- The CXX compiler identification is Clang 14.0.5 with MSVC-like command-line
-- Detecting C compiler ABI info
-- Check for working C compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/Llvm/x64/bin/clang-cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/Llvm/x64/bin/clang-cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/me/source/scratch/build
PS C:\Users\me\source\scratch\build> cmake --build . --config Debug
(builds)
```
Running the generated executable results in
```
PS C:\Users\me\source\scratch\build> .\Debug\test1.exe
it is smaller
profiling: C:\Users\me\source\scratch\build\test1.dir\Debug\.gcda: cannot merge previous GCDA file: mismatched number of counters (2)
profiling: C:\Users\me\source\scratch\build\test1.dir\Debug\.gcda: cannot merge previous GCDA file: corrupt arc tag (0x00000000)
profiling: C:\Users\me\source\scratch\build\test1.dir\Debug\.gcda: cannot merge previous GCDA file: corrupt arc tag (0x00000000)
profiling: C:\Users\me\source\scratch\build\test1.dir\Debug\.gcda: cannot merge previous GCDA file: corrupt arc tag (0x00000000)
profiling: C:\Users\me\source\scratch\build\test1.dir\Debug\.gcda: cannot merge previous GCDA file: corrupt arc tag (0x00000000)
profiling: C:\Users\me\source\scratch\build\test1.dir\Debug\.gcda: cannot merge previous GCDA file: corrupt arc tag (0x00000000)
profiling: C:\Users\me\source\scratch\build\test1.dir\Debug\.gcda: cannot merge previous GCDA file: corrupt arc tag (0x00000000)
profiling: C:\Users\me\source\scratch\build\test1.dir\Debug\.gcda: cannot merge previous run count: corrupt object tag (0x00000000)
```
I note the following coverage files are generated:
```
PS C:\Users\me\source\scratch\build> dir C:\Users\me\source\scratch\build\test1.dir\Debug
Directory: C:\Users\me\source\scratch\build\test1.dir\Debug
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 10/4/2022 9:23 AM test1.tlog
-a---- 10/4/2022 9:24 AM 76 .gcda << there should be a test1.gcda and a main.gcda
-a---- 10/3/2022 4:00 PM 3268 .gcno << there should be a test1.gcno and a main.gcno
-a---- 10/3/2022 4:00 PM 7224 main.obj
-a---- 10/4/2022 9:23 AM 428 test1.exe.recipe
-a---- 10/3/2022 4:00 PM 34668 test1.obj
```
CMakeLists.txt
```
cmake_minimum_required (VERSION 3.20)
project (test1)
set (CMAKE_CXX_STANDARD 14)
option(COVERAGE "Generate Coverage Data" OFF)
add_executable(test1 main.cpp test1.cpp)
if(COVERAGE)
set(MY_DEBUG_OPTIONS "--coverage")
target_compile_options(test1 PUBLIC "${MY_DEBUG_OPTIONS}")
target_link_libraries(test1 "clang_rt.profile-x86_64.lib")
endif(COVERAGE)
```
test1.h
```
#pragma once
bool iffy(int i);
```
test1.cpp
```
#include <iostream>
#include "test1.h"
bool iffy(int i)
{
auto ret = true;
if( i > 100 ) {
std::cout << "it is larger" << std::endl;
}
else {
std::cout << "it is smaller" << std::endl;
ret = false;
}
return ret;
}
```
main.cpp
```
#include "test1.h"
int main()
{
iffy(1);
return 0;
}
```
Possibly related to:
https://bugs.llvm.org/show_bug.cgi?id=40877
https://gitlab.kitware.com/cmake/cmake/-/issues/24021https://gitlab.kitware.com/cmake/cmake/-/issues/24021clang-cl.exe compiler test fails with --coverage flag2023-09-27T10:01:47-04:00gatkinsoclang-cl.exe compiler test fails with --coverage flagWindows 10
Visual Studio 17 2022 Community Edition (bug also appears in Visual Studio 2019 Professional)
```
C:\Users\me\source\scratch\build>cmake -T ClangCL -D CMAKE_CXX_FLAGS="--coverage" ..
-- Building for: Visual Studio 17 2022
-- ...Windows 10
Visual Studio 17 2022 Community Edition (bug also appears in Visual Studio 2019 Professional)
```
C:\Users\me\source\scratch\build>cmake -T ClangCL -D CMAKE_CXX_FLAGS="--coverage" ..
-- Building for: Visual Studio 17 2022
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19044.
-- The C compiler identification is Clang 14.0.5 with MSVC-like command-line
-- The CXX compiler identification is Clang 14.0.5 with MSVC-like command-line
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/Llvm/x64/bin/clang-cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/Llvm/x64/bin/clang-cl.exe
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/Llvm/x64/bin/clang-cl.exe - broken
CMake Error at C:/Program Files/CMake/share/cmake-3.23/Modules/CMakeTestCXXCompiler.cmake:62 (message):
The C++ compiler
"C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/Llvm/x64/bin/clang-cl.exe"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: C:/Users/me/source/scratch/build/CMakeFiles/CMakeTmp
Run Build Command(s):C:/Program Files/Microsoft Visual Studio/2022/Community/MSBuild/Current/Bin/amd64/MSBuild.exe cmTC_3dd07.vcxproj /p:Configuration=Debug /p:Platform=x64 /p:VisualStudioVersion=17.0 /v:m && MSBuild version 17.3.1+2badb37d1 for .NET Framework
lld-link : error : undefined symbol: llvm_gcda_start_file [C:\Users\me\source\scratch\build\CMakeFiles\CMakeTmp\cmTC_3dd07.vcxproj]
>>> referenced by cmTC_3dd07.dir\Debug\testCXXCompiler.obj:(__llvm_gcov_writeout)
lld-link : error : undefined symbol: llvm_gcda_emit_function [C:\Users\me\source\scratch\build\CMakeFiles\CMakeTmp\cmTC_3dd07.vcxproj]
>>> referenced by cmTC_3dd07.dir\Debug\testCXXCompiler.obj:(__llvm_gcov_writeout)
lld-link : error : undefined symbol: llvm_gcda_emit_arcs [C:\Users\me\source\scratch\build\CMakeFiles\CMakeTmp\cmTC_3dd07.vcxproj]
>>> referenced by cmTC_3dd07.dir\Debug\testCXXCompiler.obj:(__llvm_gcov_writeout)
lld-link : error : undefined symbol: llvm_gcda_summary_info [C:\Users\me\source\scratch\build\CMakeFiles\CMakeTmp\cmTC_3dd07.vcxproj]
>>> referenced by cmTC_3dd07.dir\Debug\testCXXCompiler.obj:(__llvm_gcov_writeout)
lld-link : error : undefined symbol: llvm_gcda_end_file [C:\Users\me\source\scratch\build\CMakeFiles\CMakeTmp\cmTC_3dd07.vcxproj]
>>> referenced by cmTC_3dd07.dir\Debug\testCXXCompiler.obj:(__llvm_gcov_writeout)
lld-link : error : undefined symbol: llvm_gcov_init [C:\Users\me\source\scratch\build\CMakeFiles\CMakeTmp\cmTC_3dd07.vcxproj]
>>> referenced by cmTC_3dd07.dir\Debug\testCXXCompiler.obj:(__llvm_gcov_init)
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:2 (project)
-- Configuring incomplete, errors occurred!
See also "C:/Users/me/source/scratch/build/CMakeFiles/CMakeOutput.log".
See also "C:/Users/me/source/scratch/build/CMakeFiles/CMakeError.log".
```
CMakeLists.txt
```
cmake_minimum_required (VERSION 3.20)
project (test1)
set (CMAKE_CXX_STANDARD 11)
add_executable(test1 main.cpp)
```
main.cpp
```
#include <iostream>
int main()
{
std::cout << "hello World" << std::endl;
return 0;
}
```
Possibly related to: https://bugs.llvm.org/show_bug.cgi?id=40877https://gitlab.kitware.com/cmake/cmake/-/issues/23773Clang/Windows: vs_link_exe produces incorrect binary2022-12-12T18:07:54-05:00Michael SchmidtClang/Windows: vs_link_exe produces incorrect binaryI have the following setup:
OS: Windows 10
Arch: x86_64
Windows SDK: 10.0.19041.0 (Visual Studio 16 2019 toolchain only install)
MS Visual Studio: None
Additional LLVM Installation: 14.0.6
CMake: 3.20.3 and 3.21.1 (edit:) as ...I have the following setup:
OS: Windows 10
Arch: x86_64
Windows SDK: 10.0.19041.0 (Visual Studio 16 2019 toolchain only install)
MS Visual Studio: None
Additional LLVM Installation: 14.0.6
CMake: 3.20.3 and 3.21.1 (edit:) as well as 3.23.2 and 3.24.0-rc4
When I build a project with source coverage like the attached [sample project](/uploads/89f3959e7c4953a944cbf4d76103356b/CMakeLists.txt) with code [foo.cc](/uploads/1d5773206c6b41d8287ded8a88a2c973/foo.cc)
```
"C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Auxiliary\Build\vcvarsall.bat" x86_amd64
cmake .. -G Ninja -DCMAKE_CXX_COMPILER:FILEPATH="C:\Program Files\LLVM\bin\clang-cl.exe"
ninja
```
and run the resulting executable `foo.exe` the created profile file `default.profraw` is of format version 0x05 (second 64bit integer in the file) and cannot be processed with the installed tools of the LLVM installation which expect version 0x08 of the file format.
If I replace the linker rule command in CMakeFiles\rules.ninja
`cmd.exe /C "$PRE_LINK && "C:\Program Files\CMake\bin\cmake.exe" -E vs_link_exe --intdir=$OBJECT_DIR --rc=C:\PROGRA~1\LLVM\bin\llvm-rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100190~1.0\x86\mt.exe --manifests $MANIFESTS -- C:\PROGRA~1\LLVM\bin\lld-link.exe /nologo $in /out:$TARGET_FILE /implib:$TARGET_IMPLIB /pdb:$TARGET_PDB /version:0.0 $LINK_FLAGS $LINK_PATH $LINK_LIBRARIES && $POST_BUILD"`
with the corresponding clang-cl.exe call
` command = cmd.exe /C "$PRE_LINK && "C:\Program Files\LLVM\bin\clang-cl.exe" /nologo $in /o $TARGET_FILE /INCREMENTAL -fprofile-instr-generate -fcoverage-mapping /link /implib:$TARGET_IMPLIB /pdb:$TARGET_PDB /version:0.0 $LINK_FLAGS $LINK_PATH $LINK_LIBRARIES && $POST_BUILD"
`
the correct file format is generated.
*Suspicion:*
The following is just a guess because cmake -E vs_link_exe is not documented and does not support --trace or --debug-output options.
-E vs_link_exe somehow links against the much older `C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.29.30133\lib\x64\clang_rt.profile-x86_64.lib` and not `C:\Program Files\LLVM\lib\clang\14.0.6\lib\windows\clang_rt.profile-x86_64.lib`which would be correct for the toolchain, as `C:\PROGRA~1\LLVM\bin\clang-cl.exe` is used for compilation.https://gitlab.kitware.com/cmake/cmake/-/issues/22995CMAKE_ASM_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN set incorrectly with Clang2021-12-10T09:33:38-05:00Ryan PrichardCMAKE_ASM_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN set incorrectly with ClangThe `CMAKE_${LANG}_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN` flags are set to `--gcc-toolchain=` for current versions of Clang and `-gcc-toolchain ` for versions older than Clang 3.4.0.
Clang doesn't have an program with a GAS-like CLI syntax...The `CMAKE_${LANG}_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN` flags are set to `--gcc-toolchain=` for current versions of Clang and `-gcc-toolchain ` for versions older than Clang 3.4.0.
Clang doesn't have an program with a GAS-like CLI syntax and instead reuses the C/C++ compiler driver to assemble files.
When CMake uses Clang to assemble, it sets `CMAKE_ASM_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN` to `-gcc-toolchain ` regardless of the Clang version. This is a problem because new versions of Clang removed support for `-gcc-toolchain ` in favor of `--gcc-toolchain=`. https://llvm.org/D108494
`CMAKE_ASM_COMPILER_VERSION` is left blank rather than set to match the C/C++ variables.
A test case:
CMakeLists.txt
```
cmake_minimum_required(VERSION 3.21.0)
project(test C CXX ASM)
message(STATUS "CMAKE_ASM_COMPILER_VERSION = ${CMAKE_ASM_COMPILER_VERSION}")
message(STATUS "CMAKE_C_COMPILER_VERSION = ${CMAKE_C_COMPILER_VERSION}")
message(STATUS "CMAKE_CXX_COMPILER_VERSION = ${CMAKE_CXX_COMPILER_VERSION}")
message(STATUS "CMAKE_ASM_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN = ${CMAKE_ASM_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN}")
message(STATUS "CMAKE_C_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN = ${CMAKE_C_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN}")
message(STATUS "CMAKE_CXX_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN = ${CMAKE_CXX_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN}")
message(STATUS "CMAKE_ASM_COMPILER_EXTERNAL_TOOLCHAIN = ${CMAKE_ASM_COMPILER_EXTERNAL_TOOLCHAIN}")
message(STATUS "CMAKE_C_COMPILER_EXTERNAL_TOOLCHAIN = ${CMAKE_C_COMPILER_EXTERNAL_TOOLCHAIN}")
message(STATUS "CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN = ${CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN}")
```
Output:
```
$ CC=clang CXX=clang++ cmake -GNinja .
-- The C compiler identification is Clang 11.1.0
-- The CXX compiler identification is Clang 11.1.0
-- The ASM compiler identification is Clang
-- Found assembler: /usr/bin/clang
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/clang - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/clang++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- CMAKE_ASM_COMPILER_VERSION =
-- CMAKE_C_COMPILER_VERSION = 11.1.0
-- CMAKE_CXX_COMPILER_VERSION = 11.1.0
-- CMAKE_ASM_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN = -gcc-toolchain
-- CMAKE_C_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN = --gcc-toolchain=
-- CMAKE_CXX_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN = --gcc-toolchain=
-- CMAKE_ASM_COMPILER_EXTERNAL_TOOLCHAIN =
-- CMAKE_C_COMPILER_EXTERNAL_TOOLCHAIN =
-- CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN =
-- Configuring done
-- Generating done
-- Build files have been written to: /x/mess/A
```
I'm using CMake from the cmake-3.21.4-1 debian package. I've also noticed it with a local build of CMake 3.22.1.
This issue currently breaks Android's "legacy toolchain file" (as opposed to its newer toolchain file). The legacy file happens to set the `CMAKE_{ASM,C,CXX}_COMPILER_EXTERNAL_TOOLCHAIN` variables, so it's hitting this general CMake+Clang issue. I don't know if this toolchain file needs to set those variables, so maybe removing that setting is an easy fix in future NDK releases.
References:
* https://github.com/android/ndk/issues/1623
* https://android.googlesource.com/platform/ndk/+/refs/tags/ndk-r24-beta1/build/cmake/android-legacy.toolchain.cmake#404
* https://gitlab.kitware.com/cmake/cmake/-/blob/v3.22.1/Modules/Compiler/Clang.cmake#L37-43https://gitlab.kitware.com/cmake/cmake/-/issues/22913Enhancement: Let users choose between full and thin LTO if applicable2021-11-14T08:32:44-05:00Robin ChristEnhancement: Let users choose between full and thin LTO if applicableIt would be nice if there was a flag to let users choose between slow, full LTO (which sometimes may be desired, because there are cases where full LTO still offers a massive performance benefit over thin LTO) and the currently standard ...It would be nice if there was a flag to let users choose between slow, full LTO (which sometimes may be desired, because there are cases where full LTO still offers a massive performance benefit over thin LTO) and the currently standard thin LTO
I believe on clang this would map to `-flto` and `-flto=thin` - I can't say on gcc, perhaps `-flto` and `-fwhopr`?
The flag could be named `CMAKE_INTERPROCEDURAL_OPTIMIZATION_PREFERRED_TYPE` or `CMAKE_IPO_PREFERRED_TYPE` and (for now) take the values `FULL` and `THIN`https://gitlab.kitware.com/cmake/cmake/-/issues/22668clang-cl: Use new value "ClangCl" for CMAKE_<LANG>_COMPILER_ID2023-11-17T07:07:17-05:00Deniz Bahadirclang-cl: Use new value "ClangCl" for CMAKE_<LANG>_COMPILER_IDWith the introduction of `clang-cl` on Windows (conditionally) setting compiler-options in CMake became more difficult.
While `clang` accepts traditional Clang/GCC options, `clang-cl` is a frontend which accepts MSVC options but no lon...With the introduction of `clang-cl` on Windows (conditionally) setting compiler-options in CMake became more difficult.
While `clang` accepts traditional Clang/GCC options, `clang-cl` is a frontend which accepts MSVC options but no longer directly accepts traditional Clang/GCC options.
Now, one not only has to check the `CMAKE_<LANG>_COMPILER_ID` variable but additionally `CMAKE_<LANG>_COMPILER_FRONTEND_VARIANT`. (See: #22666)
Even worse, CMake-code that originally worked perfectly fine on different operating systems with different compilers now fails on Windows because it can no longer differentiate between `clang` and `clang-cl`. This is particularly true when using the generator-expression `$<COMPILE_LANG_AND_ID:...>` or `$<CXX_COMPILER_ID:...>` etc. (See: #22432)
---
I therefore suggest to introduce a new value for `CMAKE_<LANG>_COMPILER_ID` called "`ClangCl`" (similar to "`AppleClang`") which shall be used when `clang-cl` is used, to simply differentiate between `clang` and `clang-cl`.
Of course, that should also work with the associated generator-expressions.https://gitlab.kitware.com/cmake/cmake/-/issues/22667Clang: Detection of frontent-variant versus --driver-mode2021-09-22T10:46:24-04:00Deniz BahadirClang: Detection of frontent-variant versus --driver-modeThe detection of Clang's frontent-variant, the logic that calculates `CMAKE_<LANG>_COMPILER_FRONTENT_VARIANT`, is not working reliable in all situations.
On Windows it seems to work when using just `clang` (respective `clang++`) or `cla...The detection of Clang's frontent-variant, the logic that calculates `CMAKE_<LANG>_COMPILER_FRONTENT_VARIANT`, is not working reliable in all situations.
On Windows it seems to work when using just `clang` (respective `clang++`) or `clang-cl` for `CMAKE_C_COMPILER` and `CMAKE_CXX_COMPILER`.
But when also using Clang's `--driver-mode` option the detection fails (or succeeds out of sheer luck).
---
For example when using the following `CMakeLists.txt` file:
```cmake
cmake_minimum_required(VERSION 3.19...3.21)
project( DetectCompiler
VERSION 1.0.0
LANGUAGES C CXX
)
message(STATUS "CMAKE_C_COMPILER_ID = ${CMAKE_C_COMPILER_ID}")
message(STATUS "CMAKE_C_SIMULATE_ID = ${CMAKE_C_SIMULATE_ID}")
message(STATUS "CMAKE_C_COMPILER FRONTEND_VARIANT = ${CMAKE_C_COMPILER_FRONTEND_VARIANT}")
message(STATUS "CMAKE_CXX_COMPILER_ID = ${CMAKE_CXX_COMPILER_ID}")
message(STATUS "CMAKE_CXX_SIMULATE_ID = ${CMAKE_CXX_SIMULATE_ID}")
message(STATUS "CMAKE_CXX_COMPILER FRONTEND_VARIANT = ${CMAKE_CXX_COMPILER_FRONTEND_VARIANT}")
```
It fails for `clang --driver-mode=cl` / `clang++ --driver-mode=cl`:
```
cmake -G "Ninja" -DCMAKE_C_COMPILER=clang;--driver-mode=cl -DCMAKE_CXX_COMPILER=clang++;--driver-mode=cl ../source
-- The C compiler identification is Clang 12.0.0 with GNU-like command-line
-- The CXX compiler identification is Clang 12.0.0 with GNU-like command-line
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/VC/Tools/Llvm/x64/bin/clang.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/VC/Tools/Llvm/x64/bin/clang.exe - broken
CMake Error at C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.20/Modules/CMakeTestCCompiler.cmake:66 (message):
The C compiler
"C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/VC/Tools/Llvm/x64/bin/clang.exe"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: C:/Users/dbahadir/cmake-tests/build/CMakeFiles/CMakeTmp
Run Build Command(s):C:/PROGRA~2/MICROS~2/2019/PROFES~1/Common7/IDE/COMMON~1/MICROS~1/CMake/Ninja/ninja.exe cmTC_d60bd && [1/2] Building C object CMakeFiles/cmTC_d60bd.dir/testCCompiler.c.obj
FAILED: CMakeFiles/cmTC_d60bd.dir/testCCompiler.c.obj
C:\PROGRA~2\MICROS~2\2019\PROFES~1\VC\Tools\Llvm\x64\bin\clang.exe --driver-mode=cl -g -Xclang -gcodeview -O0 -D_DEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrtd -MD -MT CMakeFiles/cmTC_d60bd.dir/testCCompiler.c.obj -MF CMakeFiles\cmTC_d60bd.dir\testCCompiler.c.obj.d -o CMakeFiles/cmTC_d60bd.dir/testCCompiler.c.obj -c testCCompiler.c
clang: warning: unknown argument ignored in clang-cl: '-g' [-Wunknown-argument]
clang: warning: unknown argument ignored in clang-cl: '-MF' [-Wunknown-argument]
clang: error: no such file or directory: 'CMakeFiles/cmTC_d60bd.dir/testCCompiler.c.obj'
clang: error: no such file or directory: 'CMakeFiles\cmTC_d60bd.dir\testCCompiler.c.obj.d'
ninja: build stopped: subcommand failed.
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:3 (project)
-- Configuring incomplete, errors occurred!
See also "C:/Users/dbahadir/cmake-tests/build/CMakeFiles/CMakeOutput.log".
See also "C:/Users/dbahadir/cmake-tests/build/CMakeFiles/CMakeError.log".
```
---
For completeness, it succeeds (out of sheer luck) for `clang --driver-mode=gcc` / `clang++ --driver-mode=g++`:
```
cmake -G "Ninja" -DCMAKE_C_COMPILER=clang;--driver-mode=gcc -DCMAKE_CXX_COMPILER=clang++;--driver-mode=g++ ../compiler-detection-tests/
-- The C compiler identification is Clang 12.0.0 with GNU-like command-line
-- The CXX compiler identification is Clang 12.0.0 with GNU-like command-line
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/VC/Tools/Llvm/x64/bin/clang.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/VC/Tools/Llvm/x64/bin/clang++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - failed
-- CMAKE_C_COMPILER_ID = Clang
-- CMAKE_C_SIMULATE_ID = MSVC
-- CMAKE_C_COMPILER FRONTEND_VARIANT = GNU
-- CMAKE_CXX_COMPILER_ID = Clang
-- CMAKE_CXX_SIMULATE_ID = MSVC
-- CMAKE_CXX_COMPILER FRONTEND_VARIANT = GNU
-- Configuring done
-- Generating done
```https://gitlab.kitware.com/cmake/cmake/-/issues/22465ClangCL: Add support for system includes2021-07-24T19:42:42-04:00Gregor JasnyClangCL: Add support for system includesHello,
I'm testing ClangCL (from VS2022 preview 2) and noticed that it does not support system includes. I was able to hack-in support by adding the following two lines to my `CMakeLists.txt`:
```cmake
set(CMAKE_INCLUDE_SYSTEM_FLAG_C "...Hello,
I'm testing ClangCL (from VS2022 preview 2) and noticed that it does not support system includes. I was able to hack-in support by adding the following two lines to my `CMakeLists.txt`:
```cmake
set(CMAKE_INCLUDE_SYSTEM_FLAG_C "-Xclang -isystem -Xclang ")
set(CMAKE_INCLUDE_SYSTEM_FLAG_CXX "-Xclang -isystem -Xclang ")
```
Would you please consider adding similar functionality to the proper CMake Platform modules?
Thanks,
Gregorhttps://gitlab.kitware.com/cmake/cmake/-/issues/22458Clang: `MinSizeRel` should use `-Oz` instead of `-Os`2021-08-19T19:45:24-04:00Dan AlbertClang: `MinSizeRel` should use `-Oz` instead of `-Os`https://clang.llvm.org/docs/CommandGuide/clang.html#cmdoption-o0
Based on https://github.com/android/ndk/issues/1536#issuecomment-883214329 it sounds like `MinSizeRel` uses `-Os` for Clang when it should be using `-Oz` for actually mini...https://clang.llvm.org/docs/CommandGuide/clang.html#cmdoption-o0
Based on https://github.com/android/ndk/issues/1536#issuecomment-883214329 it sounds like `MinSizeRel` uses `-Os` for Clang when it should be using `-Oz` for actually minimal sized builds.https://gitlab.kitware.com/cmake/cmake/-/issues/22236clang-cl 7.0.0 invalid option '/notify_update'2021-05-25T09:41:16-04:00emptyVoidclang-cl 7.0.0 invalid option '/notify_update'Here's the output:
```
[cmake] Not searching for unused variables given on the command line.
[cmake] -- The C compiler identification is Clang 7.0.0 with MSVC-like command-line
[cmake] -- The CXX compiler identification is Clang 7.0.0 wi...Here's the output:
```
[cmake] Not searching for unused variables given on the command line.
[cmake] -- The C compiler identification is Clang 7.0.0 with MSVC-like command-line
[cmake] -- The CXX compiler identification is Clang 7.0.0 with MSVC-like command-line
[cmake] -- Detecting C compiler ABI info
[cmake] -- Detecting C compiler ABI info - failed
[cmake] -- Check for working C compiler: C:/Program Files (x86)/something/something/clang-cl.exe
[cmake] -- Check for working C compiler: C:/Program Files (x86)/something/something/clang-cl.exe - broken
[cmake] CMake Error at C:/Program Files/CMake/share/cmake-3.20/Modules/CMakeTestCCompiler.cmake:66 (message):
[cmake] The C compiler
[cmake]
[cmake] "C:/Program Files (x86)/something/something/clang-cl.exe"
[cmake]
[cmake] is not able to compile a simple test program.
[cmake]
[cmake] It fails with the following output:
[cmake]
[cmake] Change Dir: D:/Projects/test/build/CMakeFiles/CMakeTmp
[cmake]
[cmake] Run Build Command(s):C:/PROGRA~2/something/Ninja/ninja.exe cmTC_8c4ed && [1/2] Building C object CMakeFiles\cmTC_8c4ed.dir\testCCompiler.c.obj
[cmake] [2/2] Linking C executable cmTC_8c4ed.exe
[cmake] FAILED: cmTC_8c4ed.exe
[cmake] cmd.exe /C "cd . && "C:\Program Files\CMake\bin\cmake.exe" -E vs_link_exe --intdir=CMakeFiles\cmTC_8c4ed.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100190~1.0\x86\rc.exe --mt=C:\PROGRA~2\something\LLVM\bin\llvm-mt.exe --manifests -- C:\PROGRA~2\MICROS~2\2017\BUILDT~1\VC\Tools\MSVC\1416~1.270\bin\Hostx86\x86\link.exe /nologo CMakeFiles\cmTC_8c4ed.dir\testCCompiler.c.obj /out:cmTC_8c4ed.exe /implib:cmTC_8c4ed.lib /pdb:cmTC_8c4ed.pdb /version:0.0 /machine:X86 /debug /INCREMENTAL /subsystem:console kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cd ."
[cmake] MT: command "C:\PROGRA~2\something\LLVM\bin\llvm-mt.exe /nologo /manifest CMakeFiles\cmTC_8c4ed.dir/intermediate.manifest /out:CMakeFiles\cmTC_8c4ed.dir/embed.manifest /notify_update" failed (exit code 0x1) with the following output:
[cmake] llvm-mt: error: invalid option '/notify_update'
[cmake] ninja: build stopped: subcommand failed.
```https://gitlab.kitware.com/cmake/cmake/-/issues/21914IPO support check fails if CUDA is specified before CXX in enabled languages ...2021-04-25T11:02:51-04:00Pasquale ColaianniIPO support check fails if CUDA is specified before CXX in enabled languages (on Windows, with Clang)[test_ipo_windows_clang_cuda_cxx.zip](/uploads/fe037376eb21c8aa6cb000d5f5f14ac9/test_ipo_windows_clang_cuda_cxx.zip)
- Platform: Windows
- Compiler: clang++ or clang-cl
- Generator: Ninja
In a project with CUDA enabled, specifying CUDA...[test_ipo_windows_clang_cuda_cxx.zip](/uploads/fe037376eb21c8aa6cb000d5f5f14ac9/test_ipo_windows_clang_cuda_cxx.zip)
- Platform: Windows
- Compiler: clang++ or clang-cl
- Generator: Ninja
In a project with CUDA enabled, specifying CUDA before CXX breaks the cache generation.
The attachment serves as an example project.
```cmake
cmake_minimum_required(VERSION 3.18)
# Platform: Windows
# Command: cmake -G Ninja -D CMAKE_CXX_COMPILER="clang++" <src path>
# It fails also with clang-cl
# It does not fail with MSVC
# project(TestProgram LANGUAGES CXX CUDA) # this works
project(TestProgram LANGUAGES CUDA CXX) # this does not
include(CheckIPOSupported)
check_ipo_supported(RESULT result OUTPUT output LANGUAGES CXX)
if(result)
set(CMAKE_INTERPROCEDURAL_OPTIMIZATION TRUE)
message(STATUS "Interprocedural Optimization is ON for CXX")
else()
message(SEND_ERROR "IPO is not supported: ${output}")
endif()
add_library(lib STATIC lib.cpp)
add_executable(test_program main.cpp)
target_link_libraries(test_program PRIVATE lib)
```
<details><summary>_CMakeError.log_</summary>
```
CXX compiler IPO check failed with the following output:
Change Dir: D:/test_ipo_windows_clang_cuda_cxx/build/CMakeFiles/_CMakeLTOTest-CXX/bin
Run Build Command(s):D:/PROGRA~1/Ninja/ninja.exe && [1/4] Building CXX object CMakeFiles\foo.dir\foo.cpp.obj
[2/4] Building CXX object CMakeFiles\boo.dir\main.cpp.obj
[3/4] Linking CXX static library foo.lib
FAILED: foo.lib
cmd.exe /C "cd . && D:\PROGRA~1\MICROS~2\2019\BUILDT~1\VC\Tools\MSVC\1428~1.293\bin\Hostx64\x64\lib.exe /machine:x64 /out:foo.lib CMakeFiles\foo.dir\foo.cpp.obj && cd ."
Microsoft (R) Library Manager Version 14.28.29336.0
Copyright (C) Microsoft Corporation. All rights reserved.
CMakeFiles\foo.dir\foo.cpp.obj : fatal error LNK1107: invalid or corrupt file: cannot read at 0xBEC
ninja: build stopped: subcommand failed.
```
</details>