Update compiler_builtins to 0.1.114

[nicholasbishop]

The weak-intrinsics feature was removed from compiler_builtins in rust-lang/compiler-builtins#598, so dropped the compiler-builtins-weak-intrinsics feature from alloc/std/sysroot.

In rust-lang/compiler-builtins#593, some builtins for f16/f128 were added. These don't work for all compiler backends, so add a compiler-builtins-no-f16-f128 feature and disable it for cranelift and gcc.

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

[rustbot]

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

[klensy]

There exist also #124886

[nicholasbishop]

Was this closed intentionally?

[GuillaumeGomez]

Oh wow, sorry didn't realize, no it wasn't on purpose!

[bors]

☔ The latest upstream changes (presumably #125074) made this pull request unmergeable. Please resolve the merge conflicts.

[tgross35]

Note that #124886 does the same thing

[beetrees]

A rebase should fix the CI failure now that #123816 has been merged.

[beetrees]

It appears the CI failure is being caused by the bootstrap stage0 compiler. I guess it won't succeed until #123816 reaches stage0 then.

[nicholasbishop]

Makes sense. Is the compiler-builtins-no-f16-f128 feature still needed here? I'm unclear whether that mangling error was the only problem, or if it's still correct to turn off f16/f128 for gcc/cranelift.

[tgross35]

Everything for f16/f128 needs to be turned off for the GCC and cranelift backends until they gain support (tracked at the issues at the bottom of this list #116909 (comment)). These types should stay enabled for the default LLVM backend, though.

[tgross35]

It appears the CI failure is being caused by the bootstrap stage0 compiler. I guess it won't succeed until #123816 reaches stage0 then.

I'll ask on Zulip if we might be able to backport that to unblock these updates

[tgross35]

@nicholasbishop there is another new release of builtins that should hopefully fix the android issue, 0.1.114. Could you update this?

[tgross35]

Thanks for the quick change, hopefully this one works.

@bors r+

[bors]

📌 Commit ecf2963 has been approved by tgross35

It is now in the queue for this repository.

[bors]

⌛ Testing commit ecf2963 with merge 80d8270...

[bors]

☀️ Test successful - checks-actions
Approved by: tgross35
Pushing 80d8270 to master...

[rust-timer]

Finished benchmarking commit (80d8270): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.4%	[0.4%, 0.4%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.9%	[-0.9%, -0.9%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 2.9%, secondary 3.3%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	2.9%	[2.3%, 4.0%]	5
Regressions ❌ (secondary)	3.3%	[3.3%, 3.3%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.9%	[2.3%, 4.0%]	5

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

Results (primary 0.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.0%	[0.0%, 0.0%]	4
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.0%	[0.0%, 0.0%]	4

Bootstrap: 768.947s -> 770.31s (0.18%)
Artifact size: 331.47 MiB -> 331.76 MiB (0.09%)

[TimNN]

I think something in this PR might be broken with regard to whether the f16/f128 builtins are being generated.

I have downloaded https://ci-artifacts.rust-lang.org/rustc-builds/80d8270d8488957f62fbf0df7a19dfe596be92ac/rust-std-nightly-x86_64-unknown-linux-gnu.tar.xz

And ran

llvm-nm ./rust-std-nightly-x86_64-unknown-linux-gnu/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-7586cb84705120bb.rlib | grep __extend
./rust-std-nightly-x86_64-unknown-linux-gnu/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-7586cb84705120bb.rlib:lib.rmeta: no symbols
0000000000000000 T _ZN17compiler_builtins5float6extend13__extendsfdf217hc5379a65d797e83bE
0000000000000000 W __extendsfdf2

I would have expected to see the f16 & f128 symbols there.

Running a rustc build in verbose mode, I see:

/Users/logic/Projects/rustc/llvm-head/build/bootstrap/debug/rustc /Users/logic/Projects/rustc/llvm-head/build/bootstrap/debug/rustc --crate-name compiler_builtins --edition=2021 /Users/logic/.cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.114/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=145 --crate-type lib --emit=dep-info,metadata,link --cfg 'feature="compiler-builtins"' --cfg 'feature="core"' --cfg 'feature="default"' --cfg 'feature="no-f16-f128"' --cfg 'feature="rustc-dep-of-std"' --target aarch64-apple-darwin <truncated>

Note the --cfg 'feature="no-f16-f128"' in there. This is on aarch64 which means that, AFAICT, no-f16-f128 should not trigger.

Commenting out

[target.'cfg(not(any(target_arch = "aarch64", target_arch = "x86", target_arch = "x86_64")))'.dependencies]
compiler_builtins = { version = "0.1.114", features = ["no-f16-f128"] }

Does produce a libcompiler_builtins.rlib which has the f16/f128 symbols.

[tgross35]

@TimNN thanks for reporting that, asking about it on Zulip https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Enabling.20features.20on.20specific.20targets.

[tgross35]

Actually let's move discussion to a new issue, opened #128358.

[aeubanks]

This has also exposed rust-lang/compiler-builtins#653