Regression on cross compiling to aarch64-unknown-linux-musl using nightly #128401
Labels
C-bug
Category: This is a bug.
F-f16_and_f128
`#![feature(f16)]`, `#![feature(f128)]`
P-high
High priority
regression-untriaged
Untriaged performance or correctness regression.
Comments
VorpalBlade
added
C-bug
rustbot
added
I-prioritize
|
cc @Emilgardis (of cross-rs fame) in case he has any insight on this regression |
|
I have hit the same issue in a similar situation. Link to pipeline failing logs: ci logs |
VorpalBlade
added a commit
to VorpalBlade/paketkoll
that referenced
this issue
Jul 30, 2024
VorpalBlade
changed the title
VorpalBlade
changed the title
|
Seems rune isn't needed based on the comment by @drdo |
|
This is probably #128358 |
|
WG-prioritization assigning priority (Zulip discussion). @rustbot label -I-prioritize +P-high |
rustbot
added
P-high
|
Yeah that's probably it. We used to build the C version of those symbols but switched to Rust versions with the compiler builtins update. Unfortunately we can't enable them on all platforms because LLVM has crashes, and the logic that would allow optional configuration is apparently not working. After that part is fixed, we will need to enable the symbols on all platforms where I think anyone who needs a quick workaround can add |
@tgross35 Is it possible to add a dependency conditionally based on if it is nightly? (In a specific range of dates even?) I cannot and will not depend on nightly, but I do test my code on nightly in CI (in order to find breakages like this early). For now I just disabled that nightly build on aarch64 musl. |
drdo
added a commit
to drdo/redu
that referenced
this issue
Jul 31, 2024
taiki-e
added a commit
to taiki-e/setup-cross-toolchain-action
that referenced
this issue
Jul 31, 2024
taiki-e
added a commit
to taiki-e/setup-cross-toolchain-action
that referenced
this issue
Jul 31, 2024
taiki-e
added a commit
to taiki-e/portable-atomic
that referenced
this issue
Jul 31, 2024
|
Same for me. Not using cross-rs though. |
|
Same for me, both using |
tgross35
added a commit
to tgross35/compiler-builtins
that referenced
this issue
Aug 2, 2024
By moving the logic for which platforms get symbols to `compiler_builtins` rather than rust-lang/rust, we can control where symbols get enabled without relying on Cargo features. Using Cargo features turned out to be a problem in [1]. This will help resolve errors like [2]. [1]: rust-lang/rust#128358 [2]: rust-lang/rust#128401
tgross35
added a commit
to tgross35/compiler-builtins
that referenced
this issue
Aug 2, 2024
By moving the logic for which platforms get symbols to `compiler_builtins` rather than rust-lang/rust, we can control where symbols get enabled without relying on Cargo features. Using Cargo features turned out to be a problem in [1]. This will help resolve errors like [2]. [1]: rust-lang/rust#128358 [2]: rust-lang/rust#128401
tgross35
added a commit
to tgross35/compiler-builtins
that referenced
this issue
Aug 2, 2024
By moving the logic for which platforms get symbols to `compiler_builtins` rather than rust-lang/rust, we can control where symbols get enabled without relying on Cargo features. Using Cargo features turned out to be a problem in [1]. This will help resolve errors like [2]. [1]: rust-lang/rust#128358 [2]: rust-lang/rust#128401
tgross35
added a commit
to tgross35/compiler-builtins
that referenced
this issue
Aug 2, 2024
By moving the logic for which platforms get symbols to `compiler_builtins` rather than rust-lang/rust, we can control where symbols get enabled without relying on Cargo features. Using Cargo features turned out to be a problem in [1]. This will help resolve errors like [2]. [1]: rust-lang/rust#128358 [2]: rust-lang/rust#128401
tgross35
added a commit
to tgross35/compiler-builtins
that referenced
this issue
Aug 2, 2024
By moving the logic for which platforms get symbols to `compiler_builtins` rather than rust-lang/rust, we can control where symbols get enabled without relying on Cargo features. Using Cargo features turned out to be a problem in [1]. This will help resolve errors like [2]. [1]: rust-lang/rust#128358 [2]: rust-lang/rust#128401
tgross35
added a commit
to tgross35/compiler-builtins
that referenced
this issue
Aug 2, 2024
By moving the logic for which platforms get symbols to `compiler_builtins` rather than rust-lang/rust, we can control where symbols get enabled without relying on Cargo features. Using Cargo features turned out to be a problem in [1]. This will help resolve errors like [2]. [1]: rust-lang/rust#128358 [2]: rust-lang/rust#128401
tgross35
added a commit
to tgross35/compiler-builtins
that referenced
this issue
Aug 2, 2024
By moving the logic for which platforms get symbols to `compiler_builtins` rather than rust-lang/rust, we can control where symbols get enabled without relying on Cargo features. Using Cargo features turned out to be a problem in [1]. This will help resolve errors like [2]. [1]: rust-lang/rust#128358 [2]: rust-lang/rust#128401
tgross35
added a commit
to tgross35/compiler-builtins
that referenced
this issue
Aug 2, 2024
By moving the logic for which platforms get symbols to `compiler_builtins` rather than rust-lang/rust, we can control where symbols get enabled without relying on Cargo features. Using Cargo features turned out to be a problem in [1]. This will help resolve errors like [2]. [1]: rust-lang/rust#128358 [2]: rust-lang/rust#128401
tgross35
added a commit
to tgross35/compiler-builtins
that referenced
this issue
Aug 3, 2024
By moving the logic for which platforms get symbols to `compiler_builtins` rather than rust-lang/rust, we can control where symbols get enabled without relying on Cargo features. Using Cargo features turned out to be a problem in [1]. This will help resolve errors like [2]. [1]: rust-lang/rust#128358 [2]: rust-lang/rust#128401
tgross35
added a commit
to tgross35/compiler-builtins
that referenced
this issue
Aug 3, 2024
By moving the logic for which platforms get symbols to `compiler_builtins` rather than rust-lang/rust, we can control where symbols get enabled without relying on Cargo features. Using Cargo features turned out to be a problem in [1]. This will help resolve errors like [2]. [1]: rust-lang/rust#128358 [2]: rust-lang/rust#128401
This comment was marked as off-topic.
This comment was marked as off-topic.
@BlackDex Not for my projects, so you should probably provide a reproducer on x86-64 GNU if possible, since that is a tier 1 platform (unlike Aarch64 on Musl). Or is this about some other x86_64 variation that is also tier 2? |
|
Woops, sorry, the x86_64 build failed too, but then i looked at the aarch64 build logs :) which still fail. |
VorpalBlade
added a commit
to VorpalBlade/chezmoi_modify_manager
that referenced
this issue
Aug 5, 2024
tgross35
added a commit
to tgross35/rust
that referenced
this issue
Aug 5, 2024
This includes [1] which means we can remove the (nonworking) configuration of `no-f16-f128`. Fixes rust-lang#128401. [1]: rust-lang/compiler-builtins#652
tgross35
added a commit
to tgross35/rust
that referenced
this issue
Aug 5, 2024
This includes [1] which means we can remove the (nonworking) configuration of `no-f16-f128`. Fixes rust-lang#128401. [1]: rust-lang/compiler-builtins#652
saethlin
removed
the
needs-triage
tgross35
added a commit
to tgross35/rust
that referenced
this issue
Aug 5, 2024
Update `compiler-builtins` to 0.1.115 This includes [1] which means we can remove the (nonworking) configuration of `no-f16-f128`. Fixes rust-lang#128401. [1]: rust-lang/compiler-builtins#652
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Aug 5, 2024
Update `compiler-builtins` to 0.1.115 This includes [1] which means we can remove the (nonworking) configuration of `no-f16-f128`. Fixes rust-lang#128401. [1]: rust-lang/compiler-builtins#652 try-job: dist-various-1
tgross35
added a commit
to tgross35/rust
that referenced
this issue
Aug 6, 2024
This includes [1] which means we can remove the (nonworking) configuration of `no-f16-f128`. Fixes rust-lang#128401. [1]: rust-lang/compiler-builtins#652
tgross35
added a commit
to tgross35/rust
that referenced
this issue
Aug 6, 2024
This includes [1] which means we can remove the (nonworking) configuration of `no-f16-f128`. Fixes rust-lang#128401. [1]: rust-lang/compiler-builtins#652
tgross35
added a commit
to tgross35/rust
that referenced
this issue
Aug 7, 2024
Update `compiler-builtins` to 0.1.117 This includes [1] which means we can remove the (nonworking) configuration of `no-f16-f128`. Fixes rust-lang#128401. [1]: rust-lang/compiler-builtins#652 try-job: dist-various-1
tgross35
added a commit
to tgross35/rust
that referenced
this issue
Aug 7, 2024
Update `compiler-builtins` to 0.1.117 This includes [1] which means we can remove the (nonworking) configuration of `no-f16-f128`. Fixes rust-lang#128401. [1]: rust-lang/compiler-builtins#652 try-job: dist-various-1
AlexTMjugador
added a commit
to shssoichiro/oxipng
that referenced
this issue
Aug 7, 2024
After testing more thoroughly on my box, it turned out that the libgcc linking workaround should indeed fix our build errors, but on CI that did not happen because the `RUSTFLAGS` environment variable is set, which takes precedence over any configuration at `.cargo/config.toml`. Therefore, let's also add the workaround to `RUSTFLAGS` on the CI workflow definition. This should be a satisfactory enough stopgap solution that does not require ourselves to be pinned to a specific nightly or drop these builds until rust-lang/rust#128401 is sorted out.
tgross35
added a commit
to tgross35/rust
that referenced
this issue
Aug 8, 2024
Update `compiler-builtins` to 0.1.117 This includes [1] which means we can remove the (nonworking) configuration of `no-f16-f128`. Fixes rust-lang#128401. [1]: rust-lang/compiler-builtins#652 try-job: dist-various-1
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Aug 8, 2024
Rollup merge of rust-lang#128691 - tgross35:update-builtins, r=Amanieu Update `compiler-builtins` to 0.1.117 This includes [1] which means we can remove the (nonworking) configuration of `no-f16-f128`. Fixes rust-lang#128401. [1]: rust-lang/compiler-builtins#652 try-job: dist-various-1
Veykril
pushed a commit
to ferrocene/ferrocene
that referenced
this issue
Aug 12, 2024
This includes [1] which means we can remove the (nonworking) configuration of `no-f16-f128`. Fixes rust-lang/rust#128401. [1]: rust-lang/compiler-builtins#652 Ferrocene-backport-of: #128691
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Code
I do not have minimised code. This was a sudden CI build failure on nightly for aarch64-unknown-linux-musl (ci logs)
Note that this is a cross compile using cross-rs.
It fails on rust version 1.82.0-nightly (612a33f 2024-07-29) but works on 1.82.0-nightly (2cbbe8b 2024-07-28). Needless to say it also works perfectly fine on stable.
As such I'm forced to conclude that the blame lies with Rustc.
Steps to reproduce:
git clone https://github.com/VorpalBlade/paketkoll cd paketkoll git checkout 48867a025c0f2192317b7e75ddaf75fce7da3f58 cross +nightly build --target aarch64-unknown-linux-muslI expected to see this happen: Compilation successful (as it is with stable for same target, or with -gnu and nightly)
Instead, this happened (full ci logs)
Version it worked on
It most recently worked on: 1.82.0-nightly (2cbbe8b 2024-07-28) (or stable 1.80.0 or beta 1.81.0, take your pick for triaging)
Version with regression
rustc --version --verbose:The text was updated successfully, but these errors were encountered: