about summary refs log tree commit diff
path: root/compiler/rustc_codegen_ssa/src
diff options
context:
space:
mode:
authorJubilee <workingjubilee@gmail.com>2024-11-14 17:55:27 -0800
committerGitHub <noreply@github.com>2024-11-14 17:55:27 -0800
commitcea081e98030654dd38cf5ad0d6699bb678f3cc4 (patch)
tree550830f6804920f8813b04bcc2294a0cd739fe07 /compiler/rustc_codegen_ssa/src
parent60f39116314794e91ff44a1112eaf53163269fb3 (diff)
parent5d818914af2760972943db448d2a08de27900c96 (diff)
downloadrust-cea081e98030654dd38cf5ad0d6699bb678f3cc4.tar.gz
rust-cea081e98030654dd38cf5ad0d6699bb678f3cc4.zip
Rollup merge of #133050 - tgross35:inline-f16-f128, r=saethlin
Always inline functions signatures containing `f16` or `f128`

There are a handful of tier 2 and tier 3 targets that cause a LLVM crash or linker error when generating code that contains `f16` or `f128`. The cranelift backend also does not support these types. To work around this, every function in `std` or `core` that contains these types must be marked `#[inline]` in order to avoid sending any code to the backend unless specifically requested.

However, this is inconvenient and easy to forget. Introduce a check for these types in the frontend that automatically inlines any function signatures that take or return `f16` or `f128`.

Note that this is not a perfect fix because it does not account for the types being passed by reference or as members of aggregate types, but this is sufficient for what is currently needed in the standard library.

Fixes: https://github.com/rust-lang/rust/issues/133035
Closes: https://github.com/rust-lang/rust/pull/133037
Diffstat (limited to 'compiler/rustc_codegen_ssa/src')
0 files changed, 0 insertions, 0 deletions