You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As of Bazel 7.3.1, the standard clang-cl Windows toolchain supports compiling assembly code using clang-cl.exe (as it does with C and C++ code). As of 7.4.0, the clang-cl toolchain uses MASM instead of clang-cl itself to compile assembly code. This breaks our build configuration as we use gcc-style compiler flags (e.g. -Wno-macro-redefined) which are not supported by MASM.
The most straightforward way to fix this would be to revert #23406 so that clang-cl.exe is used again for assembly, contrary to what is stated there it is capable of compiling assembly code. This resolves the inconsistency of using MSVC tools for assembly and clang-cl for everything else in the clang-cl toolchain; having the tools be consistent is crucial for being able to compile the same files with the same compiler flags on both Unix and Windows using clang/clang-cl. Of course, this would break developers who depend on using MASM for some assembly files (as reported in the original issue motivating the change, #23128). Ideally, there would be some way to configure what assembler is being used without having to define a custom toolchain; and a means to not have C/C++ compiler flags apply to compiling assembly (we need -Wno-macro-redefined to avoid excessive warnings for C++ code on Windows, but don't actually need it when compiling assembly).
Which category does this issue belong to?
C++ Rules
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
We assume that Windows and the clang-cl toolchain are being used. Create an empty dummy.S file alongside a basic assembly target:
cc_library(
name = "dummy",
srcs = ["dummy.S"],
)
Then compile the target with a gcc-style compiler flag, e.g. bazel build --copt=-Wno-macro-redefined //:dummy. This works with Bazel 7.3.1, but fails with Bazel 7.4.0 with the following error. //:x64_windows-clang-cl refers to a simple platform definition for clang-cl setting the @bazel_tools//tools/cpp:clang-cl constraint. The output reflects this being executed in a CI environment for our project.
Since the action failed due to MASM not accepting gcc-style arguments like -Wno-macro-redefined, the switch to MASM in 7.4.0 is likely responsible here.
Which operating system are you running Bazel on?
Windows Server 2022
What is the output of bazel info release?
release 7.4.0
If bazel info release returns development version or (@non-git), tell us how you built Bazel.
No response
What's the output of git remote get-url origin; git rev-parse HEAD ?
N/A
If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.
I did not bisect since I only observed this on Windows CI, but believe that this is being caused by #23406 where the clang-cl toolchain starts using MASM to compile assembly instead of clang-cl which is used for other compile actions.
The PR asserts that "clang-cl is not intended to handle assembly", but we have been compiling assembly code on Windows with Bazel 7.3.1 and thus clang-cl without any issues; using MASM instead breaks compilation.
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response
The text was updated successfully, but these errors were encountered:
Description of the bug:
As of Bazel 7.3.1, the standard clang-cl Windows toolchain supports compiling assembly code using clang-cl.exe (as it does with C and C++ code). As of 7.4.0, the clang-cl toolchain uses MASM instead of clang-cl itself to compile assembly code. This breaks our build configuration as we use gcc-style compiler flags (e.g.
-Wno-macro-redefined
) which are not supported by MASM.The most straightforward way to fix this would be to revert #23406 so that clang-cl.exe is used again for assembly, contrary to what is stated there it is capable of compiling assembly code. This resolves the inconsistency of using MSVC tools for assembly and clang-cl for everything else in the clang-cl toolchain; having the tools be consistent is crucial for being able to compile the same files with the same compiler flags on both Unix and Windows using clang/clang-cl. Of course, this would break developers who depend on using MASM for some assembly files (as reported in the original issue motivating the change, #23128). Ideally, there would be some way to configure what assembler is being used without having to define a custom toolchain; and a means to not have C/C++ compiler flags apply to compiling assembly (we need
-Wno-macro-redefined
to avoid excessive warnings for C++ code on Windows, but don't actually need it when compiling assembly).Which category does this issue belong to?
C++ Rules
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
We assume that Windows and the clang-cl toolchain are being used. Create an empty
dummy.S
file alongside a basic assembly target:Then compile the target with a gcc-style compiler flag, e.g.
bazel build --copt=-Wno-macro-redefined //:dummy
. This works with Bazel 7.3.1, but fails with Bazel 7.4.0 with the following error.//:x64_windows-clang-cl
refers to a simple platform definition for clang-cl setting the@bazel_tools//tools/cpp:clang-cl
constraint. The output reflects this being executed in a CI environment for our project.The params file
dummy.obj.params
suggests that this failed with the first argument with a leading dash, which leads to the A1013 error.Since the action failed due to MASM not accepting gcc-style arguments like
-Wno-macro-redefined
, the switch to MASM in 7.4.0 is likely responsible here.Which operating system are you running Bazel on?
Windows Server 2022
What is the output of
bazel info release
?release 7.4.0
If
bazel info release
returnsdevelopment version
or(@non-git)
, tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse HEAD
?If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.
I did not bisect since I only observed this on Windows CI, but believe that this is being caused by #23406 where the clang-cl toolchain starts using MASM to compile assembly instead of clang-cl which is used for other compile actions.
The PR asserts that "clang-cl is not intended to handle assembly", but we have been compiling assembly code on Windows with Bazel 7.3.1 and thus clang-cl without any issues; using MASM instead breaks compilation.
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response
The text was updated successfully, but these errors were encountered: