Warn if feature settings may break compilation

[workingjubilee]

Currently, if a user instructs the compiler to adjust the features for compilation, or uses #[target_feature] to set unusual feature settings for a function, or introduces a custom target, this can trigger miscompilations if the settings are improperly "aligned" with each other (to do correct parameter passing and so on). This mostly impacts x86, due to its particular architectural extensions, but it could affect other platforms.

Some examples we definitely want to warn on:

• [ ] Enabling soft floats and not disabling SSE/SSE2 and the x87 FPU. This came up with https://github.com/rust-lang/rust/issues/61721
• [ ] "-sse" but not "-sse2" for x86-64. I don't know how this even makes sense, honestly, but it also came up with https://github.com/rust-lang/rust/issues/61721
• [ ] Enabling SSE or SSE2 for single functions on x86-without-SSE2 platforms and calling into it and returning the float. See https://github.com/rust-lang/rust/issues/64609 for more.

Some of these issues are currently caught by LLVM, but Rust programmers often find underlying LLVM errors surfacing to be mysterious and cryptic, and in this case we can definitely detect them and warn about them ourselves.

In addition, due to the desire for binary floating point conformance per https://github.com/rust-lang/rust/issues/10087, we probably want to emit a warning for any build configuration such that, despite having an FPU we consider to be conformant and desirable, disables the ability to use such a floating point unit, such that it could introduce non-conformant floating point code. However, that can be extended into a future issue when all the known-100%-bad bases are covered.

[workingjubilee]

This requires digging deep into the target_feature code and likely refactoring it. Much of it lives in https://github.com/rust-lang/rust/tree/master/compiler/rustc_codegen_llvm, most particularly this file, which handles things like the interface to LLVM's target features: https://github.com/rust-lang/rust/blob/master/compiler/rustc_codegen_llvm/src/llvm_util.rs Especially this: https://github.com/rust-lang/rust/blob/0fb1c371d4a14f9ce7a721d8aea683a6e6774f6c/compiler/rustc_codegen_llvm/src/llvm_util.rs#L324-L332 And this related function may also need to be reviewed, as it handles function-level setting of codegen features, like with #[target_feature]: https://github.com/rust-lang/rust/blob/0fb1c371d4a14f9ce7a721d8aea683a6e6774f6c/compiler/rustc_codegen_llvm/src/attributes.rs#L227-L229

And at least some of this logic should probably be, as part of this, hoisted into https://github.com/rust-lang/rust/tree/master/compiler/rustc_codegen_ssa. Accordingly, while it is a scoped piece of work, it is not a trivial task either.

[Wardenfar]

Hello @workingjubilee,

I'm trying to understand the issue and i have some questions.

• For the first sub-task : i need to detect imcompatible global features or at function level ? and i have not found a way to detect x87 FPU.

• To report an error : should i use sess.err(...) ?

  Thanks

[bstrie]

@Wardenfar You may want to try asking on the #t-compiler Zulip channel: https://rust-lang.zulipchat.com/#streams/131828/t-compiler

[workingjubilee]

My apologies for taking so long to answer. Yes, I am more reachable on Zulip.

1. • Q: Should we detect incompatible features at the global feature level?
   • A: Yes, definitely.
2. • Q: Should we detect incompatible features at the function feature level?
   • A: Ideally also yes.
3. • Q. How is the x87 FPU denoted?
   • A. The x87 FPU feature uses the string "+x87" to enable and "-x87" to disable
4. • Q. How to report an error?
   • A. Yes, sess.err or any of the other typical error emitters should be fine, including builders like struct_span_err.

[workingjubilee]

this is turning out to be way more complex than I thought it would possibly be, see:

• https://github.com/rust-lang/rust/issues/131799