Skip to content

compiler-builtins subtree update - #162816

Merged
rust-bors[bot] merged 18 commits into
rust-lang:mainfrom
tgross35:update-builtins
Sep 15, 2026
Merged

rust-bors[bot] merged 18 commits into
rust-lang:mainfrom
tgross35:update-builtins

Conversation

@tgross35

Copy link
Copy Markdown
Member

Subtree update of compiler-builtins to rust-lang/compiler-builtins@9e64861.

Created using https://github.com/rust-lang/josh-sync.

r? @ghost

tgross35 and others added 18 commits September 1, 2026 14:38
Note that target features on ARM are not yet stable (tracked by [1]) so
this only actually gets used on nightly.

[1]: rust-lang#150246

[ add commit body - Trevor ]
In LLVM 23, calls to `wcslen` are sometimes generated by a loop optimization
pass: llvm/llvm-project#132572. This causes some Rust
targets (including but not limited to the UEFI targets) to fail with a linker
error if a loop is transformed into a `wcslen` call. Provide a simple
implementation of `wcslen` in compiler-builtins to fix this.

Fixes rust-lang#160827
`f16` and `f128` have abi issues, so continue to use `extern "Rust"` for
now
Introduce a constant for the result of perfoming a quietening operation
on our default sNaN. Additionally check in the C file used to retrieve
these values.
This is slightly more robust against potential issues from overriding
the builtin symbol.
Provide reasoning for skips, and enable thumb since this seems to work.
Also, change wasm32-unknown-unknown to be a proper build-only target.

The mentioned failures on MinGW are cases like:

    thread 'musl_edge_case_expf' (1728) panicked at libm-test\tests\compare_built_musl.rs:26:50:
    called `Result::unwrap()` on an `Err` value:
      input:    (0.0,)
      as hex:   (+0x0p+0,)
      as bits:  (0x00000000,)
      expected: 0.0                 +0x0p+0   0x00000000
      actual:   1.0                 +0x1.000000p+0   0x3f800000

    thread 'musl_edge_case_ceil' (1964) panicked at libm-test\tests\compare_built_musl.rs:26:50:
    called `Result::unwrap()` on an `Err` value:
      input:    (1.0000000000000002,)
      as hex:   (+0x1.0000000000001p+0,)
      as bits:  (0x3ff0000000000001,)
      expected: 1.0                 +0x1.0000000000000p+0   0x3ff0000000000000
      actual:   2.0                 +0x1.0000000000000p+1   0x4000000000000000

Our libm's results are correct, for some reason musl is off (something
about the fp environment on x86, or a different FLT_EVAL_MODE?)
This updates the rust-version file to 32d94cc.
This is a rather old config, added in c924aed0b9ac ("Fix Armv8-M
Baseline compilation"). `thumb_1` is somewhat misleading, since targets
with `thumb2` also support basic `thumb` instructions. Rename it to be
more clear about what this is actually checking.

The config is not currently used but may be in the future.
We still match on target name because we can't always rely on config
from the unstable `arm_target_feature`. However, we can still assert
that things match up when running in the compiler-builtins CI.

This is disabled for now because it fails on three thumb targets:

* thumbv4t-none-eabi
* thumbv5te-none-eabi
* thumbv6-none-eabi

This will be resolved in a future commit.

Checking for the verbose build is a good indicator that we are in our
CI, rather than any other that might set the `CI` env.
Previously CI would only run tests for ARM mode, Thumb mode targets were
compile-only.  This ensures Thumb2 is covered. Thumb1 is still not
covered, but that's less easy since there's no Linux Thumb1 target.

This commit fixes some places that assume "thumb" means "bare metal".
They now check for `target_os = "none"` instead.
@rustbot rustbot added A-compiler-builtins Area: compiler-builtins (https://github.com/rust-lang/compiler-builtins) S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Sep 15, 2026
@tgross35

Copy link
Copy Markdown
Member Author

@bors try jobs=test-various,test-armhf-gnu,dist-arm-linux-gnueabi,dist-armhf-linux,dist-armv7-linux

@rust-bors

This comment has been minimized.

rust-bors Bot pushed a commit that referenced this pull request Sep 15, 2026
compiler-builtins subtree update


try-job: test-various
try-job: test-armhf-gnu
try-job: dist-arm-linux-gnueabi
try-job: dist-armhf-linux
try-job: dist-armv7-linux
@tgross35

Copy link
Copy Markdown
Member Author

@bors r+ rollup=never p=1

@rust-bors

rust-bors Bot commented Sep 15, 2026

Copy link
Copy Markdown
Contributor

📌 Commit 8864022 has been approved by tgross35

It is now in the queue for this repository.

@rust-bors rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 15, 2026
@rust-bors

rust-bors Bot commented Sep 15, 2026

Copy link
Copy Markdown
Contributor

☀️ Try build successful (CI)
Build commit: 79e7068 (79e7068281d285556f3145941ae62245c7ad8d3f)
Base parent: 5392d2f (5392d2f545c6836dc79f209bcc14ac7179dbc4f2)

@rust-bors

This comment has been minimized.

@tgross35

Copy link
Copy Markdown
Member Author

@rustbot label +beta-nominated

Looking to backport a7f33f3 and 192ea4f to fix #162259. Since the LLVM update (on beta) that issue shows up on arm targets that we don't build C versions of intrinsics for, which at least includes some no-std thumb targets.

Two other trivial commits are needed to avoid a conflict, I've prepared this in #162820.

@rustbot rustbot added the beta-nominated Nominated for backporting to the compiler in the beta channel. label Sep 15, 2026
@rust-bors rust-bors Bot added merged-by-bors This PR was explicitly merged by bors. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Sep 15, 2026
@rust-bors

rust-bors Bot commented Sep 15, 2026

Copy link
Copy Markdown
Contributor

☀️ Test successful - CI
Approved by: tgross35
Duration: 3h 13m 7s
Pushing 215a8af to main...

@rust-bors
rust-bors Bot merged commit 215a8af into rust-lang:main Sep 15, 2026
15 checks passed
@rustbot rustbot added this to the 1.100.0 milestone Sep 15, 2026
@github-actions

Copy link
Copy Markdown
Contributor
What is this? This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 0da8aed (parent) -> 215a8af (this PR)

Test differences

Show 4 test diffs

4 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 215a8af4bb4c106cccf6d6535f84eaae91818265 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

  1. dist-x86_64-llvm-mingw: 1h 19m -> 2h 11m (+65.3%)
  2. test-x86_64-gnu-gcc-core-tests: 17m 39s -> 9m 19s (-47.2%)
  3. dist-ohos-x86_64: 57m 17s -> 1h 23m (+46.3%)
  4. test-x86_64-gnu-distcheck: 1h 38m -> 2h 20m (+42.7%)
  5. test-x86_64-gnu: 1h 52m -> 2h 39m (+42.2%)
  6. dist-loongarch64-linux: 1h 28m -> 2h 4m (+41.0%)
  7. dist-i686-linux: 1h 21m -> 1h 53m (+39.2%)
  8. test-x86_64-gnu-next-trait-solver-polonius: 42m 15s -> 56m 29s (+33.7%)
  9. dist-arm-linux-musl: 1h 26m -> 1h 54m (+32.6%)
  10. test-x86_64-gnu-stdlib-semver-check: 16m 39s -> 11m 18s (-32.1%)
How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

@tgross35
tgross35 deleted the update-builtins branch September 15, 2026 22:38
@rust-timer

Copy link
Copy Markdown
Collaborator

Finished benchmarking commit (215a8af): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
0.3% [0.2%, 0.4%] 2
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Max RSS (memory usage)

Results (primary 0.7%, secondary -2.5%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
0.7% [0.7%, 0.7%] 1
Regressions ❌
(secondary)
8.2% [8.2%, 8.2%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-4.3% [-7.0%, -2.3%] 6
All ❌✅ (primary) 0.7% [0.7%, 0.7%] 1

Cycles

Results (primary 4.2%, secondary 0.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
4.2% [2.8%, 5.6%] 2
Regressions ❌
(secondary)
5.0% [3.0%, 8.1%] 5
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-5.7% [-7.8%, -2.0%] 4
All ❌✅ (primary) 4.2% [2.8%, 5.6%] 2

Binary size

Results (primary 0.0%, secondary 0.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

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

Bootstrap: 494.609s -> 498.703s (0.83%)
Artifact size: 406.84 MiB -> 406.94 MiB (0.03%)

@rustbot

rustbot commented Sep 17, 2026

Copy link
Copy Markdown
Collaborator

beta backport approved as per libs team on Zulip. A backport PR will be authored by the release team at the end of the current development cycle. Backport labels are handled by them.

@rustbot rustbot added the beta-accepted Accepted for backporting to the compiler in the beta channel. label Sep 17, 2026
@cuviper cuviper mentioned this pull request Sep 19, 2026
@cuviper cuviper removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Sep 19, 2026
rust-bors Bot pushed a commit that referenced this pull request Sep 19, 2026
[beta] backports

- Re-export `core::fmt::NumBuffer` in `alloc` (and `std`) #161430
- Make `VaArgSafe` dyn-incompatible #162374
- Destabilize `VaArgSafe` #162909
- attach global target features to module-level assembly #160594
- (partial) compiler-builtins subtree update - #162816

r? me
rust-bors Bot pushed a commit that referenced this pull request Sep 19, 2026
[beta] backports

- Re-export `core::fmt::NumBuffer` in `alloc` (and `std`) #161430
- Make `VaArgSafe` dyn-incompatible #162374
- Destabilize `VaArgSafe` #162909
- attach global target features to module-level assembly #160594
- (partial) compiler-builtins subtree update - #162816

r? me
rust-bors Bot pushed a commit that referenced this pull request Sep 19, 2026
[beta] backports

- Re-export `core::fmt::NumBuffer` in `alloc` (and `std`) #161430
- Make `VaArgSafe` dyn-incompatible #162374
- Destabilize `VaArgSafe` #162909
- attach global target features to module-level assembly #160594
- (partial) compiler-builtins subtree update - #162816

r? me
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-compiler-builtins Area: compiler-builtins (https://github.com/rust-lang/compiler-builtins) beta-accepted Accepted for backporting to the compiler in the beta channel. merged-by-bors This PR was explicitly merged by bors. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants