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 LLVM ERROR: Do not know how to split this operator's operand! #61721
• "-sse" but not "-sse2" for x86-64. I don't know how this even makes sense, honestly, but it also came up with LLVM ERROR: Do not know how to split this operator's operand! #61721
• Enabling SSE or SSE2 for single functions on x86-without-SSE2 platforms and calling into it and returning the float. See -C target-feature/-C target-cpu are unsound #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 #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.