Try to run the tests locally, according to the documentation. However, a CI failure may still
happen due to a number of reasons, for example:
Possibly due to a silent merge conflict (the changes in this pull request being
incompatible with the current code in the target branch). If so, make sure to rebase on the latest
commit of the target branch.
A sanitizer issue, which can only be found by compiling with the sanitizer and running the
affected test.
An intermittent issue.
Leave a comment here, if you need help tracking down a confusing failure.
maflcko
commented at 12:52 pm on December 16, 2024:
member
Seems fine to add this, because it is easy to remove and can increase the build compatibly in the meantime.
Also, it allows to evaluate the codegen, which could be substantially better than msvc, or detect more msvc bugs.
If there are enough benefits to clang-cl, the docs could be updated to use it and msvc could be dropped from the docs and possibly CI.
fanquake
commented at 12:54 pm on December 16, 2024:
member
Also, it allows to evaluate the codegen, which could be substantially better than msvc, or detect more msvc bugs.
Does it? My read of the docs was that clang just tries to internally work around all the MSVC bugs, so it seems like it will just continue to “hide” issues?
hebasto
commented at 1:33 pm on December 16, 2024:
member
Can’t the if(MSVC) go away and we just rely on the CMAKE_CXX_COMPILER_ID test?
hebasto
commented at 12:08 pm on December 17, 2024:
In this case, I think we do want to check MSVC, as it separates MSVC specific syntax /WX from GCC syntax -Werror.
theuni
commented at 7:46 pm on December 16, 2024:
member
At a high level.. seems to me we want to avoid doing if(MSVC) as much as possible and instead check against the compiler id, no? Except for the cases where we REALLY mean MSVC.
theuni
commented at 8:02 pm on December 16, 2024:
member
In 76659d92f1925f561736ffe0f070ed0b9fef8d23: It’d be good if commits like this could contain actual details, rather than just “Adjust diagnostic flags”; especially given this is touching non-Windows code. Also, any reason to not fix the issues in leveldb, rather than adding more suppressions?
DrahtBot removed the label
Needs rebase
on May 13, 2025
fanquake referenced this in commit
8309a9747a
on May 13, 2025
hebasto force-pushed
on May 13, 2025
hebasto force-pushed
on May 15, 2025
hebasto renamed this:
[POC] build: Use clang-cl to build on Windows natively
build: Use clang-cl to build on Windows natively
on May 15, 2025
DrahtBot added the label
Needs rebase
on May 16, 2025
hebasto force-pushed
on May 16, 2025
DrahtBot removed the label
Needs rebase
on May 16, 2025
DrahtBot added the label
Needs rebase
on May 17, 2025
hebasto force-pushed
on May 17, 2025
hebasto marked this as ready for review
on May 17, 2025
DrahtBot removed the label
Needs rebase
on May 17, 2025
hebasto force-pushed
on May 18, 2025
fanquake
commented at 9:11 am on May 21, 2025:
member
Reading the description, I’m still not really clear on the goals here. It seems like this is just adding even more ways to compile for Windows, which we have to add more CI / and more work arounds for, but doesn’t actually improve the Windows binaries we are shipping to end users in any way. This might make more sense if we were actually going to switch to shipping Windows binaries using Clang.
hebasto
commented at 3:05 pm on October 16, 2025:
member
Reading the description, I’m still not really clear on the goals here. It seems like this is just adding even more ways to compile for Windows, which we have to add more CI / and more work arounds for, but doesn’t actually improve the Windows binaries we are shipping to end users in any way.
Building Bitcoin Core from source has always been considered one of the best practices. Not supporting an effective compiler, such as clang-cl on Windows, prevents users from achieving optimal performance, which negatively affects their experience.
If adding one more CI job is an issue for the current framework, we could consider dropping MSVC support instead. And if another compiler exposes more source-level workarounds, that’s an indication the code could be made more portable.
This might make more sense if we were actually going to switch to shipping Windows binaries using Clang.
Have you seen the same from actually running Core, or it’s benchmarks, or an IBD?
I’ll refresh my benchmarks and post them shortly.
fanquake
commented at 3:36 pm on October 16, 2025:
member
01D:\a\bitcoin\bitcoin\src\script\interpreter.cpp(1531,33): warning : variable 'ext_flag' may be uninitialized when used here [-Wconditional-uninitialized][D:\a\bitcoin\bitcoin\build\src\bitcoin_consensus.vcxproj]2 D:\a\bitcoin\bitcoin\src\script\interpreter.cpp(1733,10): note: in instantiation of function template specialization 'SignatureHashSchnorr<CTransaction>' requested here
3 D:\a\bitcoin\bitcoin\src\script\interpreter.cpp(1481,21): note: initialize the variable 'ext_flag' to silence this warning
4D:\a\bitcoin\bitcoin\src\script\interpreter.cpp(1531,33): warning : variable 'ext_flag' may be uninitialized when used here [-Wconditional-uninitialized][D:\a\bitcoin\bitcoin\build\src\bitcoin_consensus.vcxproj]5 D:\a\bitcoin\bitcoin\src\script\interpreter.cpp(1733,10): note: in instantiation of function template specialization 'SignatureHashSchnorr<CMutableTransaction>' requested here
6 D:\a\bitcoin\bitcoin\src\script\interpreter.cpp(1481,21): note: initialize the variable 'ext_flag' to silence this warning
7 bitcoin_clientversion.vcxproj -> D:\a\bitcoin\bitcoin\build\lib\Release\bitcoin_clientversion.lib
0 D:\a\bitcoin\bitcoin\src\util/subprocess.h(759,10): error : private field 'parent_' is not used [-Werror,-Wunused-private-field][D:\a\bitcoin\bitcoin\build\src\bitcoin_common.vcxproj]1D:\a\bitcoin\bitcoin\src\util/subprocess.h(760,7): error : private field 'err_wr_pipe_' is not used [-Werror,-Wunused-private-field][D:\a\bitcoin\bitcoin\build\src\bitcoin_common.vcxproj]2D:\a\bitcoin\bitcoin\src\util/subprocess.h(1038,7): error : private field 'child_pid_' is not used [-Werror,-Wunused-private-field][D:\a\bitcoin\bitcoin\build\src\bitcoin_common.vcxproj]
hebasto force-pushed
on Oct 16, 2025
hebasto
commented at 5:58 pm on October 25, 2025:
member
DrahtBot added the label
Needs rebase
on Nov 4, 2025
cmake: Always link `bitcoinqt` to `shlwapi` when building for Windowsbe4d3a3fd7
cmake: Explicitly disable `__int128` when building on Windows
MSVC does not support `__int128` by design, while clang-cl offers only
limited support out of the box: `__int128` division requires the
builtins library.
For now, disable the use of `__int128` when building on Windows.
c610379f2d
cmake: Adjust diagnostic flags for clang-cl
Being compatible with cl.exe, clang-cl supports most of the same
command-line options. These options are typically guarded by the `MSVC`
CMake variable.
Options not supported by clang-cl, such as `/wdNNN`, are now guarded by
`CMAKE_CXX_COMPILER_ID STREQUAL "MSVC"`.
Additionally, `-Wno-unused-member-function` is now used when compiling
leveldb with clang-cl.
14b2d1556e
ci: Test building with clang-cla1469e6c43
hebasto force-pushed
on Nov 4, 2025
hebasto
commented at 5:52 pm on November 4, 2025:
member
Rebased to resolve the conflict with the merged bitcoin/bitcoin#30595.
DrahtBot removed the label
Needs rebase
on Nov 4, 2025
This is a metadata mirror of the GitHub repository
bitcoin/bitcoin.
This site is not affiliated with GitHub.
Content is generated from a GitHub metadata backup.
generated: 2025-11-09 18:13 UTC
This site is hosted by @0xB10C More mirrored repositories can be found on mirror.b10c.me