When should cfg(target_feature = "backchain")
(s390x target feature) be enabled?
#142412
Labels
C-bug
Category: This is a bug.
needs-triage
This issue may need triage. Remove it if it has been sufficiently triaged.
O-SystemZ
Target: SystemZ processors (s390x)
Uh oh!
There was an error while loading. Please reload this page.
#127506 added support for the "backchain" target feature, but doing so required adding some hacks to the compiler. Usually, we compute
cfg(target_feature)
by asking the codegen backend, but apparently that is not possible here. Those hacks already were partially fixed in #129940, but looking at them again I think the logic is still wrong: the logic hererust/compiler/rustc_codegen_llvm/src/llvm_util.rs
Lines 353 to 356 in c24e1c3
will conclude that the target feature is always enabled in the base target! So if someone adds a s390x target where
backchain
is disabled by default, we'll falsely claim that it is enabled. And right now, without a-Ctarget-feature
argument, we'll say the feature is enabled. I have no clue if that makes sense, but it's definitely not future-proof. (Or even worse, if a different architecture also starts using this feature name, we'll conclude the feature is enabled.)I think
RUSTC_SPECIAL_FEATURES
needs to be removed and redeveloped from scratch, the current design makes little sense. (It is also extremely easy to be confused with the very differentRUSTC_SPECIFIC_FEATURES
hack.)Is this hack even still needed? There were some comments indicating that this hack exists to deal with LLVM 18 and older, which we do not support any more.
Cc @liushuyu @uweigand @cuviper
The text was updated successfully, but these errors were encountered: