Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

LLVM ERROR about f128 on AIX and SPARC32 when building core without optimization #133035

Closed
taiki-e opened this issue Nov 14, 2024 · 3 comments · Fixed by #133050
Closed

LLVM ERROR about f128 on AIX and SPARC32 when building core without optimization #133035

taiki-e opened this issue Nov 14, 2024 · 3 comments · Fixed by #133050
Labels
C-bug Category: This is a bug. F-f16_and_f128 `#![feature(f16)]`, `#![feature(f128)]` O-aix OS: Big Blue's Advanced Interactive eXecutive.. O-SPARC Target: SPARC processors regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Comments

@taiki-e
Copy link
Member

taiki-e commented Nov 14, 2024 •
edited
Loading

Code

I tried this code:

#![no_std]
// empty

With cargo build -Z build-std=core --target powerpc64-ibm-aix:

rustc-LLVM ERROR: f128 is unimplemented on AIX.
error: could not compile `core` (lib)

With cargo build -Z build-std=core --target sparc-unknown-none-elf:

rustc-LLVM ERROR: SPARCv8 does not handle f128 in calls; pass indirectly
error: could not compile `core` (lib)

I expected to see this happen: no error

I suspect the same problem exists with the other targets listed here: https://github.com/rust-lang/compiler-builtins/blob/a09218f1c4d23ffbd97d68f0fefb5feed2469dc5/configure.rs#L82-L91

Workaround: Passing --release flag resolves error.

Version it worked on

It most recently worked on: nightly-2024-11-13

Version with regression

nightly-2024-11-14

rustc --version --verbose:

rustc 1.84.0-nightly (8adb4b30f 2024-11-13)
binary: rustc
commit-hash: 8adb4b30f40e6fbd21dc1ba26c3301c7eeb6de3c
commit-date: 2024-11-13
host: aarch64-apple-darwin
release: 1.84.0-nightly
LLVM version: 19.1.3

@rustbot label +regression-from-stable-to-nightly -regression-untriaged
@taiki-e taiki-e added C-bug Category: This is a bug. regression-untriaged Untriaged performance or correctness regression. labels Nov 14, 2024
@rustbot rustbot added I-prioritize Issue: Indicates that prioritization has been requested for this issue. needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Nov 14, 2024
@taiki-e
Copy link
Member Author

taiki-e commented Nov 14, 2024

Considering this comment, I suspect it is a regression introduced by #132662.
cc @tgross35 @RalfJung

@taiki-e
Copy link
Member Author

taiki-e commented Nov 14, 2024

I suspect it is a regression introduced by #132662.

I confirmed that reverting this PR's change fixes the problem locally.

@taiki-e taiki-e mentioned this issue Nov 14, 2024
Closed
@jieyouxu jieyouxu added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. O-SPARC Target: SPARC processors T-libs Relevant to the library team, which will review and decide on the PR/issue. O-aix OS: Big Blue's Advanced Interactive eXecutive.. F-f16_and_f128 `#![feature(f16)]`, `#![feature(f128)]` and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 14, 2024
@rustbot rustbot added regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. and removed regression-untriaged Untriaged performance or correctness regression. labels Nov 14, 2024
This was referenced Nov 14, 2024
Merged
Merged
@workingjubilee
Copy link
Member

-Zbuild-std without optimizations often fails. We should not really consider it even an experimentally supported use-case until we fix that.

tgross35 added a commit to tgross35/rust that referenced this issue Nov 14, 2024
@tgross35
Always inline functions signatures containing f16 or f128
781ea18 
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: rust-lang#133035
Closes: rust-lang#133037
workingjubilee added a commit to workingjubilee/rustc that referenced this issue Nov 15, 2024
@workingjubilee
Rollup merge of rust-lang#133050 - tgross35:inline-f16-f128, r=saethlin
cea081e 
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: rust-lang#133035
Closes: rust-lang#133037
@bors bors closed this as completed in 5d81891 Nov 15, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Nov 15, 2024
@rust-timer
Unrolled build for rust-lang#133050
4740301 
Rollup merge of rust-lang#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: rust-lang#133035
Closes: rust-lang#133037
@apiraino apiraino removed the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Nov 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C-bug Category: This is a bug. F-f16_and_f128 `#![feature(f16)]`, `#![feature(f128)]` O-aix OS: Big Blue's Advanced Interactive eXecutive.. O-SPARC Target: SPARC processors regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
6 participants
@apiraino @jieyouxu @taiki-e @workingjubilee @rustbot and others