Change:
<ins> # Known Issues This section informs you about known "gotchas". Keep in mind, that this section is (and always will be) incomplete. For suggestions and amendments, feel free to [contribute](../contributing.md) to this guide. ## Target Features Most target-feature problems arise, when mixing code that have the target-feature _enabled_ with code that have it _disabled_. If you want to avoid undefined behavior, it is recommended to build _all code_ (including the standard library and imported crates) with a common set of target-features. By default, compiling your code with the `-C target-feature` flag will not recompile the entire standard library and/or imported crates with matching target features. Therefore, target features are generally considered as unsafe. Using `#[target_feature]` on individual functions makes the function unsafe. Examples: | Target-Feature | Issue | Seen on | Description | Details | | -------------- | ----- | ------- | ----------- | ------- | | `+soft-float` <br> and <br> `-sse` | Segfaults and ABI mismatches | `x86` and `x86-64` | The `x86` and `x86_64` architecture uses SSE registers (aka `xmm`) for floating point operations. Using software emulated floats ("soft-floats") disables usage of `xmm` registers, but parts of Rust's core libraries (e.g. `std::f32` or `std::f64`) are compiled without soft-floats and expect parameters to be passed in `xmm` registers. This leads to ABI mismatches. <br><br>  Attempting to compile with disabled SSE causes the same error, too. | [#63466](https://github.com/rust-lang/rust/issues/63466) | </ins>

Discussion:
When discussing in the compiler team triage meeting, it became clear that target-features ought to be considered generally unsafe. We should document this fact in the and in the . Ideally, we'd also start listing out known gotchas. For example, in noted that: and had a . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Compiler triage meeting: Marking as P-medium
claim
The reference section about mentions this: The link to the section of the reference mentions this as well: So maybe the could point people to the reference?
That is one way in which targetfeature is unsafe, but it's not the one which was the subject of so just pointing at the reference as it is is insufficient. Plus, it's also more about than (where the compiler will hit you in the face with ). So the rustc book is a better place for it than the reference IMO.
I think that for users to better properly understand the UB involved, it might be more educational to say that stamps on all functions, but with the subtle difference that it doesn't make them , so no unsafe-check happens when this triggers UB. The reference does not document all current perils of using . In particular, it does not document that these can change the function call ABI, and that rustc neither checks that nor handles it correctly - we just currently assume people don't do that. Independently of whether we document that in the rustc book as well or not, that bit should also probably be documented in the reference, because it is easy to trigger this. On stable Rust, I think one can indeed only trigger this via and the reference should say so, but on nightly one can definitely trigger this with bare within a single Rust crate.