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.

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

Automatic Rustup #4127

Merged
merged 5 commits into from
Jan 8, 2025
Merged

Automatic Rustup #4127

merged 5 commits into from
Jan 8, 2025

Conversation

github-actions[bot]
Copy link

@github-actions github-actions bot commented Jan 8, 2025

Please close and re-open this PR to trigger CI, then enable auto-merge.

bors added 3 commits January 5, 2025 07:01
Target: Add mips mti baremetal support

Do the same thing as gcc, which use the vendor `mti` to mark the toolchain as MIPS32r2 default.

We support both big endian and little endian flavor:
  mips-mti-none-elf
  mipsel-mti-none-elf
…ingjubilee

Add a notion of "some ABIs require certain target features"

I think I finally found the right shape for the data and checks that I recently added in rust-lang/rust#133099, rust-lang/rust#133417, rust-lang/rust#134337: we have a notion of "this ABI requires the following list of target features, and it is incompatible with the following list of target features". Both `-Ctarget-feature` and `#[target_feature]` are updated to ensure we follow the rules of the ABI.  This removes all the "toggleability" stuff introduced before, though we do keep the notion of a fully "forbidden" target feature -- this is needed to deal with target features that are actual ABI switches, and hence are needed to even compute the list of required target features.

We always explicitly (un)set all required and in-conflict features, just to avoid potential trouble caused by the default features of whatever the base CPU is. We do this *before* applying `-Ctarget-feature` to maintain backward compatibility; this poses a slight risk of missing some implicit feature dependencies in LLVM but has the advantage of not breaking users that deliberately toggle ABI-relevant target features. They get a warning but the feature does get toggled the way they requested.

For now, our logic supports x86, ARM, and RISC-V (just like the previous logic did). Unsurprisingly, RISC-V is the nicest. ;)

As a side-effect this also (unstably) allows *enabling* `x87` when that is harmless. I used the opportunity to mark SSE2 as required on x86-64, to better match the actual logic in LLVM and because all x86-64 chips do have SSE2. This infrastructure also prepares us for requiring SSE on x86-32 when we want to use that for our ABI (and for float semantics sanity), see rust-lang/rust#133611, but no such change is happening in this PR.

r? `@workingjubilee`
add m68k-unknown-none-elf target

r? `@workingjubilee`

The existing `m68k-unknown-linux-gnu` target builds `std` by default, requires atomics, and has a base cpu with an fpu. A smaller/more embedded target is desirable both to have a baseline target for the ISA, as well to make debugging easier for working on the llvm backend. Currently this target is using the `M68010` as the minimum CPU due, but as missing features are merged into the `M68k` llvm backend I am hoping to lower this further.

I have been able to build very small crates using a toolchain built against this target (together with a later version of `object`) using the configuration described in the target platform-support documentation, although getting anything of substantial complexity to build quickly hits errors in the llvm backend
@rustbot rustbot closed this Jan 8, 2025
@rustbot rustbot reopened this Jan 8, 2025
@RalfJung RalfJung force-pushed the rustup-2025-01-08 branch 3 times, most recently from 88689cf to 77d5ee3 Compare January 8, 2025 07:54
@RalfJung RalfJung enabled auto-merge January 8, 2025 08:24
@RalfJung RalfJung added this pull request to the merge queue Jan 8, 2025
Merged via the queue into master with commit 3736728 Jan 8, 2025
7 checks passed
@RalfJung RalfJung deleted the rustup-2025-01-08 branch January 8, 2025 09:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants