-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
enable use_llvm if clang c_frontend is required #18254
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
Conversation
andrewrk
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for looking into this.
Let's discuss here but then I'll need to incorporate this change into #18160 which directly conflicts.
I don't think this is the correct fix. use_llvm only indicates whether the LLVM backend will be used for compiling .zig code. It should have no effect on the C frontend.
Eyeballing the diff from 53f74d6, it looks to me like the regression came from target_util.supportsStackProtector correctly noticing which zig backend is being used to generate code, while the logic calling that function incorrectly assumes that .zig code is being compiled, when in reality it might be only C code being compiled.
So I think the correct fix is also to introduce another "supports stack protector" function to target_util for C compilation, and this one will take the c_frontend as a parameter. Then the logic will look something like this:
if (have_zcu and !target_util.zigSupportsStackProtector(target, zig_backend)) {
// then disable it and error if explicitly requested
}
if (have_any_c_files and !target_util.cSupportsStackProtector(target, c_frontend, zig_backend)) {
// then disable it and error if explicitly requested
}have_zcu is "have a zig compilation unit" i.e. there is any .zig code being compiled. src/Module.zig will be renamed to Zcu soon.
ok! I'll update this once #18160 has landed.
yeah I wasn't so sure about the meaning of use_llvm. thanks for clarifying. |
Commit 97e2389 regressed this behavior because it made target_util.supportsStackProtector *correctly* notice which zig backend is being used to generate code, while the logic calling that function *incorrectly assumed* that .zig code is being compiled, when in reality it might be only C code being compiled. This commit adjusts the option resolution logic for stack protector so that it takes into account the zig backend only if there is a zig compilation unit. A separate piece of logic checks whether clang supports stack protector for a given target. closes #18009 closes #18114 closes #18254
Commit 97e2389 regressed this behavior because it made target_util.supportsStackProtector *correctly* notice which zig backend is being used to generate code, while the logic calling that function *incorrectly assumed* that .zig code is being compiled, when in reality it might be only C code being compiled. This commit adjusts the option resolution logic for stack protector so that it takes into account the zig backend only if there is a zig compilation unit. A separate piece of logic checks whether clang supports stack protector for a given target. closes #18009 closes #18114 closes #18254
Commit 97e2389 regressed this behavior because it made target_util.supportsStackProtector *correctly* notice which zig backend is being used to generate code, while the logic calling that function *incorrectly assumed* that .zig code is being compiled, when in reality it might be only C code being compiled. This commit adjusts the option resolution logic for stack protector so that it takes into account the zig backend only if there is a zig compilation unit. A separate piece of logic checks whether clang supports stack protector for a given target. closes #18009 closes #18114 closes #18254
Commit 97e2389 regressed this behavior because it made target_util.supportsStackProtector *correctly* notice which zig backend is being used to generate code, while the logic calling that function *incorrectly assumed* that .zig code is being compiled, when in reality it might be only C code being compiled. This commit adjusts the option resolution logic for stack protector so that it takes into account the zig backend only if there is a zig compilation unit. A separate piece of logic checks whether clang supports stack protector for a given target. closes #18009 closes #18114 closes #18254
Commit 97e2389 regressed this behavior because it made target_util.supportsStackProtector *correctly* notice which zig backend is being used to generate code, while the logic calling that function *incorrectly assumed* that .zig code is being compiled, when in reality it might be only C code being compiled. This commit adjusts the option resolution logic for stack protector so that it takes into account the zig backend only if there is a zig compilation unit. A separate piece of logic checks whether clang supports stack protector for a given target. closes #18009 closes #18114 closes #18254
Commit 97e2389 regressed this behavior because it made target_util.supportsStackProtector *correctly* notice which zig backend is being used to generate code, while the logic calling that function *incorrectly assumed* that .zig code is being compiled, when in reality it might be only C code being compiled. This commit adjusts the option resolution logic for stack protector so that it takes into account the zig backend only if there is a zig compilation unit. A separate piece of logic checks whether clang supports stack protector for a given target. closes #18009 closes #18114 closes #18254
Commit 97e2389 regressed this behavior because it made target_util.supportsStackProtector *correctly* notice which zig backend is being used to generate code, while the logic calling that function *incorrectly assumed* that .zig code is being compiled, when in reality it might be only C code being compiled. This commit adjusts the option resolution logic for stack protector so that it takes into account the zig backend only if there is a zig compilation unit. A separate piece of logic checks whether clang supports stack protector for a given target. closes #18009 closes #18114 closes #18254
Commit 97e2389 regressed this behavior because it made target_util.supportsStackProtector *correctly* notice which zig backend is being used to generate code, while the logic calling that function *incorrectly assumed* that .zig code is being compiled, when in reality it might be only C code being compiled. This commit adjusts the option resolution logic for stack protector so that it takes into account the zig backend only if there is a zig compilation unit. A separate piece of logic checks whether clang supports stack protector for a given target. closes #18009 closes #18114 closes #18254
Commit 97e2389 regressed this behavior because it made target_util.supportsStackProtector *correctly* notice which zig backend is being used to generate code, while the logic calling that function *incorrectly assumed* that .zig code is being compiled, when in reality it might be only C code being compiled. This commit adjusts the option resolution logic for stack protector so that it takes into account the zig backend only if there is a zig compilation unit. A separate piece of logic checks whether clang supports stack protector for a given target. closes #18009 closes #18114 closes #18254
fix
zig cc -fstack-protectorwas failing since 53f74d6, with
error: unable to create compilation: StackProtectorUnsupportedByTargetalso fixes
zig build-exethat no longer enabled stack-protector by default when compiling c files.closes #18009
closes #18114