| Age | Commit message (Collapse) | Author | Lines |
|---|
|
We want kernels to be able to use this bare metal target, so
let's enable the sanitizers that kernels want to use.
(cherry picked from commit 6b06aa619297c198e923e1d406a5bb0534260fef)
|
|
set the float ABI explicitly
|
|
|
|
|
|
Improve default target options for x86_64-unknown-linux-none
Without a standard library, we cannot unwind, so it should be panic=abort by default.
Additionally, it does not have std because while it is Linux, it cannot use libc, which std uses today for Linux.
Using PIE by default may be surprising to users, as shown in #134763, so I've documented it explicitly. I'm not sure if we want to count that as fixing the issue or not.
cc `@morr0ne,` as you added the target (and are the maintainer), and `@Noratrieb,` who reviewed that PR (:D).
|
|
Without a standard library, we cannot unwind, so it should be
panic=abort by default.
Additionally, it does not have std because while it is
Linux, it cannot use libc, which std uses today for Linux.
|
|
|
|
There were some changes to `{i686,x86_64}-pc-windows-msvc`, include them
in the backward compatibility targets as well.
|
|
Re-export more `rustc_span::symbol` things from `rustc_span`.
`rustc_span::symbol` defines some things that are re-exported from `rustc_span`, such as `Symbol` and `sym`. But it doesn't re-export some closely related things such as `Ident` and `kw`. So you can do `use rustc_span::{Symbol, sym}` but you have to do `use rustc_span::symbol::{Ident, kw}`, which is inconsistent for no good reason.
This commit re-exports `Ident`, `kw`, and `MacroRulesNormalizedIdent`, and changes many `rustc_span::symbol::` qualifiers to `rustc_span::`. This is a 300+ net line of code reduction, mostly because many files with two `use rustc_span` items can be reduced to one.
r? `@jieyouxu`
|
|
`rustc_span::symbol` defines some things that are re-exported from
`rustc_span`, such as `Symbol` and `sym`. But it doesn't re-export some
closely related things such as `Ident` and `kw`. So you can do `use
rustc_span::{Symbol, sym}` but you have to do `use
rustc_span::symbol::{Ident, kw}`, which is inconsistent for no good
reason.
This commit re-exports `Ident`, `kw`, and `MacroRulesNormalizedIdent`,
and changes many `rustc_span::symbol::` qualifiers in `compiler/` to
`rustc_span::`. This is a 200+ net line of code reduction, mostly
because many files with two `use rustc_span` items can be reduced to
one.
|
|
r=jieyouxu,Urgau,Kobzol
Promote powerpc64le-unknown-linux-musl to tier 2 with host tools
MCP: https://github.com/rust-lang/compiler-team/issues/803
I'm using crosstool-ng for building a toolchain because GCC 9 from `musl-toolchain.sh` has float ABI issues (?) and can't compile LLVM, and writing a crosstool-ng config for a target feels less hacky than yet another target specific shell script. I also defined a kernel version, since there wasn't one specified before. If a lower version is desired, just let me know. I also tried to match the rust configure args with the loongarch64 musl tier 2 target.
The resulting compiler works fine, built with `DEPLOY=1 ./src/ci/docker/run.sh dist-powerpc64le-linux` and tested on Alpine Linux in a VM and on a bare metal POWER8 machine:
```
qemu-ppc64le:/tmp/rust-nightly-powerpc64le-unknown-linux-musl$ ash install.sh
install: creating uninstall script at /usr/local/lib/rustlib/uninstall.sh
install: installing component 'rustc'
install: installing component 'rust-std-powerpc64le-unknown-linux-musl'
install: installing component 'cargo'
install: installing component 'rustfmt-preview'
install: installing component 'rls-preview'
install: installing component 'rust-analyzer-preview'
install: installing component 'llvm-tools-preview'
install: installing component 'clippy-preview'
install: installing component 'miri-preview'
install: installing component 'rust-analysis-powerpc64le-unknown-linux-musl'
install: installing component 'llvm-bitcode-linker-preview'
install: WARNING: failed to run ldconfig. this may happen when not installing as root. run with --verbose to see the error
rust installed.
qemu-ppc64le:~$ echo 'fn main() { println!("hello world"); }' > test.rs
qemu-ppc64le:~$ rustc test.rs
qemu-ppc64le:~$ ./test
hello world
qemu-ppc64le:~$ file test
test: ELF 64-bit LSB executable, 64-bit PowerPC or cisco 7500, OpenPOWER ELF V2 ABI, version 1 (SYSV), statically linked, BuildID[sha1]=596ee6abf9add487ebc54fb71c2076fb6faea013, with debug_info, not stripped
```
try-job: dist-powerpc64le-linux
|
|
|
|
reject aarch64 target feature toggling that would change the float ABI
~~Stacked on top of https://github.com/rust-lang/rust/pull/133099. Only the last two commits are new.~~
The first new commit lays the groundwork for separately controlling whether a feature may be enabled or disabled. The second commit uses that to make it illegal to *disable* the `neon` feature (which is only possible via `-Ctarget-feature`, and so the new check just adds a warning). Enabling the `neon` feature remains allowed on targets that don't disable `neon` or `fp-armv8`, which is all our built-in targets. This way, the entire PR is not a breaking change.
Fixes https://github.com/rust-lang/rust/issues/131058 for hardfloat targets (together with https://github.com/rust-lang/rust/pull/133102 which fixed it for softfloat targets).
Part of https://github.com/rust-lang/rust/issues/116344.
|
|
Co-authored-by: Jubilee <workingjubilee@gmail.com>
|
|
|
|
r=workingjubilee,jieyouxu,tgross35
Updates Solaris target information, adds Solaris maintainer
|
|
Rollup of 6 pull requests
Successful merges:
- #133221 (Add external macros specific diagnostics for check-cfg)
- #133386 (Update linux_musl base to dynamically link the crt by default)
- #134191 (Make some types and methods related to Polonius + Miri public)
- #134227 (Update wasi-sdk used to build WASI targets)
- #134279 ((Re-)return adjustment target if adjust kind is never-to-any)
- #134295 (Encode coroutine-closures in SMIR)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Update linux_musl base to dynamically link the crt by default
However, don't change the behavior of any existing targets at this time. For targets that used the old default, explicitly set `crt_static_default = true`.
This makes it easier for new targets to use the correct defaults while leaving the changing of individual targets to future PRs.
Related to https://github.com/rust-lang/compiler-team/issues/422
|
|
|
|
Fix powerpc64 big-endian FreeBSD ABI
Note that FreeBSD version bump may be reverted due to https://github.com/rust-lang/rust/pull/120869#issuecomment-2438685835. We may want to wait to merge this until that discussion is complete.
Fixes https://github.com/rust-lang/rust/pull/120869#discussion_r1813233054
> > PPC64 FreeBSD (ELFv1 and ELFv2, version 13.2)
>
> It seems odd that ELFv1 and 13.N coexist.
>
> https://www.freebsd.org/releases/13.0R/relnotes/
>
> > powerpc64 switched to ELFv2 ABI at the same time it switched to LLVM. This brings us to a parity with modern Linux distributions. This also makes the binaries from previous FreeBSD versions incompatible with 13.0-RELEASE. Kernel still supports ELFv1, so jails and chroots using older FreeBSD versions are still compatible. [e4399d169acc](https://cgit.freebsd.org/src/commit/?id=e4399d169acc)
>
> Well, it is also odd that this target claims ELFv2 support since our ABI code does not use ELFv2 on this target.
>
> https://github.com/rust-lang/rust/blob/be01dabfefd2daa4574b974f571c7852085d60cb/compiler/rustc_target/src/callconv/powerpc64.rs#L102-L111
````````@rustbot```````` label +O-PowerPC +O-freebsd
|
|
forbid toggling x87 and fpregs on hard-float targets
Part of https://github.com/rust-lang/rust/issues/116344, follow-up to https://github.com/rust-lang/rust/pull/129884:
The `x87` target feature on x86 and the `fpregs` target feature on ARM must not be disabled on a hardfloat target, as that would change the float ABI. However, *enabling* `fpregs` on ARM is [explicitly requested](https://github.com/rust-lang/rust/issues/130988) as it seems to be useful. Therefore, we need to refine the distinction of "forbidden" target features and "allowed" target features: all (un)stable target features can determine on a per-target basis whether they should be allowed to be toggled or not. `fpregs` then checks whether the current target has the `soft-float` feature, and if yes, `fpregs` is permitted -- otherwise, it is not. (Same for `x87` on x86).
Also fixes https://github.com/rust-lang/rust/issues/132351. Since `fpregs` and `x87` can be enabled on some builds and disabled on others, it would make sense that one can query it via `cfg`. Therefore, I made them behave in `cfg` like any other unstable target feature.
The first commit prepares the infrastructure, but does not change behavior. The second commit then wires up `fpregs` and `x87` with that new infrastructure.
r? `@workingjubilee`
|
|
|
|
link libunwind dynamically and allow controlling it via `crt-static` on gnullvm targets
Alternative to https://github.com/rust-lang/rust/pull/121794
```
$ cargo b -r
Finished `release` profile [optimized] target(s) in 0.38s
$ ntldd target/release/hello.exe | rg unwind
libunwind.dll => H:\msys64\clang64\bin\libunwind.dll (0x0000020c35df0000)
$ RUSTFLAGS="-C target-feature=+crt-static" cargo b -r
Finished `release` profile [optimized] target(s) in 0.23s
$ ntldd target/release/hello.exe | rg unwind
```
|
|
|
|
See llvm/llvm-project@c5ab70c508457eaece5d7ff4ab79a2f90bc67f06
@rustbot label: +llvm-main
|
|
LLVM continues to clean these up, and we continue to make this
consistent. This is similar to 9caced7badc337ced7ad89eb614621c39bd996e9,
e9853961452b56997cc127b51308879b9cd09482, and
a10e744fafa7eb3afef9a938097509bf4b225f84.
`@rustbot` label: +llvm-main
|
|
rust_for_linux: -Zreg-struct-return commandline flag for X86 (#116973)
Command line flag `-Zreg-struct-return` for X86 (32-bit) for rust-for-linux.
This flag enables the same behavior as the `abi_return_struct_as_int` target spec key.
- Tracking issue: https://github.com/rust-lang/rust/issues/116973
|
|
MCP: https://github.com/rust-lang/compiler-team/issues/803
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
|
|
|
|
|
|
|
|
|
|
Mark visionOS as supporting `std`
Cargo's -Zbuild-std has recently started checking this field, which causes it to fail to compile even though we have full support for the standard library on these targets.
[Example of failed build](https://github.com/rust-random/getrandom/actions/runs/12069033154/job/33655430622).
Affected targets: `aarch64-apple-visionos` and `aarch64-apple-visionos-sim`.
r? Noratrieb (because you've worked with `rustc` target metadata IIRC)
``@rustbot`` label O-visionos
|
|
Add `+forced-atomics` feature to esp32s2 no_std target
Similar to https://github.com/rust-lang/rust/pull/114499 but for the Xtensa backend. The ESP32-S2 doesn't have native atomic support, but can have atomic load/stores as part of the ISA with this LLVM codegen feature.
Note: The current rev of LLVM that rustc is using doesn't contain the `+forced-atomics` feature for Xtensa, but I'm pushing this now to remove the patch from our fork in `esp-rs/rust`.
r? ``@Amanieu`` because you reviewed the related RISC-V PR
|
|
ensure JSON-defined targets are consistent
We have a `check_consistency` check that ensures some invariants which (presumably) the rest of the compiler relies on. However, JSON targets can easily be written in a way that violates those invariants. So this PR applies the same consistency check to JSON targets that we already enforce for built-in targets.
I have converted many of the assertions in that function to new macros that show a nice error instead of a panic; if people are okay with the general approach here, I can do that for the rest of the checks as well.
|
|
|
|
Cargo's -Zbuild-std has recently started checking this field, which
causes it to fail to compile even though we have full support for the
standard library on these targets.
|
|
Fix handling of x18 in AArch64 inline assembly on ohos/trusty or with -Zfixed-x18
Currently AArch64 inline assembly allows using x18 on ohos/trusty or with -Zfixed-x18.
https://github.com/rust-lang/rust/blob/7db7489f9bc274cb60c4956bfa56de0185eb1b9b/compiler/rustc_target/src/asm/aarch64.rs#L74-L76
However, x18 is reserved in these environments and should not be allowed in the input/output operands of inline assemblies as it is in Android, Windows, etc..
https://github.com/rust-lang/rust/blob/7db7489f9bc274cb60c4956bfa56de0185eb1b9b/compiler/rustc_target/src/spec/targets/aarch64_unknown_linux_ohos.rs#L19
https://github.com/rust-lang/rust/blob/7db7489f9bc274cb60c4956bfa56de0185eb1b9b/compiler/rustc_target/src/spec/targets/aarch64_unknown_trusty.rs#L18
https://github.com/rust-lang/rust/blob/7db7489f9bc274cb60c4956bfa56de0185eb1b9b/compiler/rustc_codegen_llvm/src/llvm_util.rs#L764-L771
(As for ohos, +reserve-x18 is [redundant](https://github.com/llvm/llvm-project/commit/c417b7a695704d5bc3be23f34d1bfa505f5172de#diff-0ddf23e0bf2b28b2d05f842f087d1e6f694e8e06d1765e8d0f10d47fddcdff9c) since https://github.com/rust-lang/rust/commit/7a966b918870485e9b364e77f50c511f8c2cc275 that starting using llvm's ohos targets. So removed it from target-spec.)
This fix may potentially break the code for tier 2 target (aarch64-unknown-linux-ohos). (As for others, aarch64-unknown-trusty is tier 3 and -Zfixed-x18 is unstable so breaking them should be fine.)
However, in any case, it seems suspicious that the code that is broken by this was sound.
r? `@Amanieu`
`@rustbot` label O-AArch64 +A-inline-assembly
|
|
|
|
|
|
Rollup of 12 pull requests
Successful merges:
- #133042 (btree: add `{Entry,VacantEntry}::insert_entry`)
- #133070 (Lexer tweaks)
- #133136 (Support ranges in `<[T]>::get_many_mut()`)
- #133140 (Inline ExprPrecedence::order into Expr::precedence)
- #133155 (Yet more `rustc_mir_dataflow` cleanups)
- #133282 (Shorten the `MaybeUninit` `Debug` implementation)
- #133326 (Remove the `DefinitelyInitializedPlaces` analysis.)
- #133362 (No need to re-sort existential preds in relate impl)
- #133367 (Simplify array length mismatch error reporting (to not try to turn consts into target usizes))
- #133394 (Bail on more errors in dyn ty lowering)
- #133410 (target check_consistency: ensure target feature string makes some basic sense)
- #133435 (miri: disable test_downgrade_observe test on macOS)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
target check_consistency: ensure target feature string makes some basic sense
|
|
the emscripten OS no longer exists on non-wasm targets
https://github.com/rust-lang/rust/pull/117338 removed our asmjs targets, which AFAIK means that emscripten only exists on wasm targets. However at least one place in the code still checked "is wasm or is emscripten". Let's fix that.
Cc ```@workingjubilee```
|
|
-Zfixed-x18
|
|
Remove legacy bitcode for iOS
Follow #117364.
|
|
|
|
|
|
|
|
However, don't change the behavior of any existing targets at this time.
For targets that used the old default, explicitly set `crt_static_default = true`.
This makes it easier for new targets to use the correct defaults while
leaving the changing of individual targets to future PRs.
Related to https://github.com/rust-lang/compiler-team/issues/422
|
|
|
