-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
zig cc: parse -target
and -mcpu
/-march
/-mtune
flags according to clang
#4911
Comments
If we advertise as "drop in replacement" then I would side with parse-as-clang-does with one exception. We are permitted to add zig variants of options where it makes sense:
A compelling case was reported by Justin Whear on discord where use of |
Thanks to @mikdusan for adding my use case to this issue. I thought I'd follow up with a few specifics to reinforce his suggestion. The background is that I'm trying to compile the Intel Hyperscan library with So I created simple It appears that CMake recognizes |
Just in case anyone is trying to do something similar, I hacked around this for the time being by making my wrapper scripts do a bit of translation work: #!/bin/bash
# See https://github.com/ziglang/zig/issues/4911
args=""
for arg in "$@"
do
parg="$arg"
option=${arg%=*}
target=${arg#*=}
if [[ $option == "-march" || $option == "-mcpu" || $option == "-mtune" ]]; then
fixedTarget=${target//-/_}
parg="$option=$fixedTarget"
fi
args="$args $parg"
done
zig c++ $args |
Targets accepted by generic BTW, neither accepts the targets x86-64-v2, x86-64-v3, x86-64-v4 that appear in the target list. While targets are usually chosen quite deliberately and specifically, there is one that is sprinkled onto many makefiles and build scripts and that is |
|
Was this fixed since 0.9.1? |
I know @andrewrk is the creator of zig, but Considering this answer on stackoverflow, probably it is best to just delete the '-mtune' option to bypass this bug. |
Are there any updates on this? |
This fork provides a temporary fix for ziglang/zig#4911, by making our current Rust builds not generate targets that `zig cc` doesn't understand.
This fork provides a temporary fix for ziglang/zig#4911, by making our current Rust builds not generate targets that `zig cc` doesn't understand.
reorder args to ensure `target` is correctly overriden for compatibility with zig ziglang/zig#4911 Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
reorder args to ensure `target` is correctly overriden for compatibility with zig ziglang/zig#4911 Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
This fork provides a temporary fix for ziglang/zig#4911, by making our current Rust builds not generate targets that `zig cc` doesn't understand.
Another one interesting case related with this issue, preventing us using zig just as a drop-in replacement of clang: Works: clang++ --target=aarch64-apple-darwin -march=armv8+crc+simd 1.cc Fail: zig c++ -target aarch64-macos-none -march=armv8+crc+simd 1.cc
info: available CPUs for architecture 'aarch64':
a64fx
ampere1
ampere1a
apple_a10
apple_a11
apple_a12
apple_a13
apple_a14
apple_a15
apple_a16
apple_a7
apple_a8
apple_a9
apple_latest
apple_m1
apple_m2
apple_s4
apple_s5
carmel
cortex_a34
cortex_a35
cortex_a510
cortex_a53
cortex_a55
cortex_a57
cortex_a65
cortex_a65ae
cortex_a710
cortex_a715
cortex_a72
cortex_a73
cortex_a75
cortex_a76
cortex_a76ae
cortex_a77
cortex_a78
cortex_a78c
cortex_r82
cortex_x1
cortex_x1c
cortex_x2
cortex_x3
cyclone
emag
exynos_m1
exynos_m2
exynos_m3
exynos_m4
exynos_m5
falkor
generic
kryo
neoverse_512tvb
neoverse_e1
neoverse_n1
neoverse_n2
neoverse_v1
neoverse_v2
saphira
thunderx
thunderx2t99
thunderx3t110
thunderxt81
thunderxt83
thunderxt88
tsv110
xgene1
error: unknown CPU: 'armv8' |
Putting on my Zig MSBuild SDK hat for a moment: I find it incredibly valuable that I can use the same FWIW, I'm also personally not convinced that enough build scripts in the wild actually have hardcoded I think we should stick to our guns here and insist that Zig's |
This fork provides a temporary fix for ziglang/zig#4911, by making our current Rust builds not generate targets that `zig cc` doesn't understand.
Agreeing with @alexrp and rejecting this proposal. |
Extracted from #4784
Status quo:
Even when doing
zig cc
,-target
is parsed as Zig's-target
flag, which is different in some ways than clang's, as it contains (optional) os version info, glibc version info, and it's proposed (#4584) to have cpu feature syntax as well. Similarly,-mcpu
,-march
, and-mtune
are all treated identically, as the zig-mcpu
parameter. This is useful since the zig syntax allows specifying CPU model name and features.This proposal is to add more code to support these options to be strictly compliant with clang's syntax. This would potentially improve the "drop-in" robustness of this feature, at the expense of the extra info that zig's syntax supports. If this proposal is implemented, then
zig cc
probably would need to introduce a few of its own non-standard flags to support specifying this additional information.As an argument for not doing this, it's simpler and more powerful to leave things as status quo, and often, the reason people are using
zig cc
is for cross compiling anyway, in which case they will be putting the-target
and/or-mcpu
flags as part of theCC
environment variable or equivalent. For this use case status quo is actually preferable.The text was updated successfully, but these errors were encountered: