| Age | Commit message (Collapse) | Author | Lines |
|---|
|
As an i586 target, it should not have SSE. This caused the following
warning to be emitted:
```
warning: target feature `sse2` must be enabled to ensure that the ABI of the current target can be implemented correctly
|
= note: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #116344 <https://github.com/rust-lang/rust/issues/116344>
warning: 1 warning emitted
```
(cherry picked from commit 1c66d5bed9e6444923c04937f5a28bfcec427ec0)
|
|
|
|
r=chenyukang,workingjubilee
Add cygwin target.
This PR simply adds cygwin target together with msys2 target, based on ````@ookiineko```` 's (the account has been deleted) [work](https://github.com/ookiineko-cygport/rust) on cygwin target. My full work is here: https://github.com/rust-lang/rust/compare/master...Berrysoft:rust:dev/cygwin
I have succeeded in building a new rustc for cygwin target, and eventually distributed a new version of [fish-shell](https://github.com/Berrysoft/fish-shell/releases) (rewritten by Rust) for MSYS2.
I will open a new PR to fix std if this PR is accepted.
|
|
workingjubilee:merge-gpus-to-get-the-arcradeongeforce, r=bjorn3
compiler: internally merge `PtxKernel` into `GpuKernel`
r? ``@bjorn3`` for review
|
|
workingjubilee:stabilize-externabi-hashing-forever, r=compiler-errors
compiler: give `ExternAbi` truly stable `Hash` and `Ord`
Currently, `ExternAbi` has a bunch of code to handle the reality that, as an enum, adding more variants to it will risk it hashing differently. It forces all of those variants to be added in a fixed order, except this means that the order of the variants doesn't correspond to any logical order except "historical accident". This is all to avoid having to rebless two tests. Perhaps there were more, once upon a time? But then we invented normalization in our test suite to handle exactly this sort of issue in a more general way.
There are two options here:
- Get rid of all the logical overhead and shrug, embracing blessing a couple of tests sometimes
- Change `ExternAbi` to have an ordering and hash that doesn't depend on the number of variants
As `ExternAbi` is essentially a strongly-typed string, and thus no two strings can be identical, this implements the second of the two by hand-implementing `Ord` and `Hash` to make the hashing and comparison based on the string! This will diff the current hashes, but they will diff no more after this.
|
|
Replace i686-unknown-redox target with i586-unknown-redox
This change is related to https://github.com/rust-lang/rust/issues/136495
|
|
i686-linux-android: increase CPU baseline to Pentium 4 (without an actual change
As per ``@maurer's`` [comment](https://github.com/rust-lang/rust/issues/136495#issuecomment-2648743078), this shouldn't actually change anything since we anyway add a bunch of extensions that bump things up way beyond Pentium 4. But Pentium 4 is consistent with the other i686 targets and I don't know enough about the exact sequence of CPU generations to be confident with more than this. ;)
|
|
The last public reexport of rustc_abi in rustc_target is finally gone.
|
|
change)
|
|
r=compiler-errors
compiler: die immediately instead of handling unknown target codegen
We cannot produce anything useful if asked to compile unknown targets. We should handle the error immediately at the point of discovery instead of propagating it upward, and preferably in the simplest way: Die.
This allows cleaning up our "error-handling" spread across 5 crates.
|
|
r=SparrowLii,jieyouxu
show supported register classes in error message
a simple diagnostic change that shows the supported register classes when an invalid one is found.
This information can be hard to find (especially for unstable targets), and this message now gives at least something to try or search for. I've followed the pattern for invalid clobber ABIs.
`@rustbot` label +A-inline-assembly
|
|
Rollup of 11 pull requests
Successful merges:
- #136606 (Fix long lines which rustfmt fails to format)
- #136663 (Stabilize `NonZero::count_ones`)
- #136672 (library: doc: core::alloc::Allocator: trivial typo fix)
- #136704 (Improve examples for file locking)
- #136721 (cg_llvm: Reduce visibility of some items outside the `llvm` module)
- #136813 (rustc_target: Add the fp16 target feature for AArch32)
- #136830 (fix i686-unknown-hurd-gnu x87 footnote)
- #136832 (Fix platform support table for i686-unknown-uefi)
- #136835 (Stop using span hack for contracts feature gating)
- #136837 (Overhaul how contracts are lowered on fn-like bodies)
- #136839 (fix ensure_monomorphic_enough)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
rustc_target: Add the fp16 target feature for AArch32
As in the commit description. The feature is already available in rustc for AArch64.
|
|
r=compiler-errors
compiler: gate `extern "{abi}"` in ast_lowering
I don't believe low-level crates like `rustc_abi` should have to know or care about higher-level concerns like whether the ABI string is stable for users. These implementation details can be made less open to public inspection. This way the code that governs stability is near the code that enforces stability, and compiled together.
It also abstracts away certain error messages instead of constantly repeating them.
A few error messages are simply deleted outright, instead of made uniform, because they are either too dated to be useful or redundant with other diagnostic improvements we could make. These can be pursued in followups: my first concern was making sure there wasn't unnecessary diagnostics-related code in `rustc_abi`, which is not well-positioned to understand what kind of errors are going to be generated based on how it is used.
r? ``@ghost``
|
|
We cannot produce anything useful if asked to compile unknown targets.
We should handle the error immediately at the point of discovery instead
of propagating it upward, and preferably in the simplest way: Die.
This allows cleaning up our "error-handling" spread across 5 crates.
|
|
|
|
Disable DWARF in linker options for i686-unknown-uefi
This fixes an lld warning:
> warning: linker stderr: rust-lld: section name .debug_frame is longer than 8 characters and will use a non-standard string table
See https://reviews.llvm.org/D69594 for details of where the warning was added.
This warning only occurs with the i686 UEFI target, not x86_64 or aarch64. The x86_64 target uses an LLVM target of
`x86_64-unknown-windows` and aarch64 uses `aarch64-unknown-windows`, but i686 uses `i686-unknown-windows-gnu` (note the `-gnu`). See comments in `i686_unknown_uefi.rs` for details of why.
The `.debug_frame` section should not actually be needed; UEFI targets provide a separate PDB file for debugging. Disable DWARF (and by extension the `.debug_frame` section) by passing `/DEBUG:NODWARF` to lld.
Tested with:
```
export RUSTC_LOG=rustc_codegen_ssa::back::link=info
cargo +stage1 build --release --target i686-unknown-uefi
```
This issue was originally raised here: https://github.com/rust-lang/rust/pull/119286#issuecomment-2612746162. See also https://github.com/rust-lang/rust/issues/136096. It was suggested to file an LLVM bug, but I don't think LLVM is actually doing anything wrong as such.
CC `@dvdhrm` `@jyn514` let me know if you have any feedback on this approach
|
|
|
|
|
|
Co-authored-by: Ookiineko <chiisaineko@protonmail.com>
Co-authored-by: nora <48135649+Noratrieb@users.noreply.github.com>
Co-authored-by: Jubilee <workingjubilee@gmail.com>
|
|
It is speculated that these two can be conceptually merged, and it can
start by ripping out rustc's notion of the PtxKernel call convention.
Leave the ExternAbi for now, but the nvptx target now should see it as
just a different way to spell Conv::GpuKernel.
|
|
Add amdgpu target
Add amdgpu target to rustc and enable the LLVM target.
Fix compiling `core` with the amdgpu:
The amdgpu backend makes heavy use of different address spaces. This
leads to situations, where a pointer in one addrspace needs to be casted
to a pointer in a different addrspace. `bitcast` is invalid for this
case, `addrspacecast` needs to be used.
Fix compilation failures that created bitcasts for such cases by
creating pointer casts (which creates an `addrspacecast` under the hood)
instead.
MCP: https://github.com/rust-lang/compiler-team/issues/823
Tracking issue: #135024
Kinda related to the original amdgpu tracking issue #51575 (though that one has been closed for a while).
|
|
|
|
By moving this stability check into AST lowering, we effectively make
it impossible to accidentally miss, as it must happen to generate HIR.
Also, we put the ABI-stability code next to code that actually uses it!
This allows code that wants to reason about backend ABI implementations
to stop worrying about high-level concerns like syntax stability,
while still leaving it as the authority on what ABIs actually exist.
It also makes it easy to refactor things to have more consistent errors.
For now, we only apply this to generalize the existing messages a bit.
|
|
This fixes an lld warning:
> warning: linker stderr: rust-lld: section name .debug_frame is longer
> than 8 characters and will use a non-standard string table
See https://reviews.llvm.org/D69594 for details of where the warning was
added.
This warning only occurs with the i686 UEFI target, not x86_64 or
aarch64. The x86_64 target uses an LLVM target of
`x86_64-unknown-windows` and aarch64 uses `aarch64-unknown-windows`, but
i686 uses `i686-unknown-windows-gnu` (note the `-gnu`). See comments in
`i686_unknown_uefi.rs` for details of why.
The `.debug_frame` section should not actually be needed; UEFI targets
provide a separate PDB file for debugging. Disable DWARF (and by
extension the `.debug_frame` section) by passing `/DEBUG:NODWARF` to lld.
Tested with:
export RUSTC_LOG=rustc_codegen_ssa::back::link=info
cargo +stage1 build --release --target i686-unknown-uefi
|
|
Update bootstrap compiler and rustfmt
The rustfmt version we previously used formats things differently from what the latest nightly rustfmt does. This causes issues for subtrees that get formatted both in-tree and in their own repo. Updating the rustfmt used in-tree solves those issues. Also bumped the bootstrap compiler as the stage0 update command always updates both at the same
time.
|
|
r=compiler-errors
compiler: mostly-finish `rustc_abi` updates
This almost-finishes all the updates in the compiler to use `rustc_abi` and removes some of the reexports of `rustc_abi` items in `rustc_target` that were previously available.
r? ```@compiler-errors```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
compiler: Clean up weird `rustc_abi` reexports
Just general cleanup in `rustc_target` and `rustc_abi`. I was originally going to make a PR with a larger change that also fixed the last few crates and in doing so removed some clutter from `rustc_abi`, but wound up slightly stuck on it, then figured out how to fix it, and then got distracted by other things... so now I'm trying to figure out what I had figured out earlier.
|
|
compiler: replace few consts arrays with statics to remove const dupes
Locally on `x86_64-pc-windows-msvc` -100kb for `rustc_driver.dll`
|
|
rustc_target has had a lot of weird reexports for various reasons, but
now we're at a point where we can actually start reducing their number.
We remove weird shadowing-dependent behavior and import directly from
rustc_abi instead of doing weird renaming imports.
This is only incremental progress and does not entirely fix the crate.
|
|
Avoid using make_direct_deprecated() in extern "ptx-kernel"
This method will be removed in the future as it produces a broken ABI that depends on cg_llvm implementation details. After this PR wasm32-unknown-unknown is the only remaining user of make_direct_deprecated().
Fixes https://github.com/rust-lang/rust/issues/117271
Blocks https://github.com/rust-lang/rust/issues/38788
|
|
Use +secure-plt for powerpc-unknown-linux-gnu{,spe}
Fixes #136131
See that issue for details.
I'm not sure about the policy about baseline on these platforms (there is no [platform support doc](https://doc.rust-lang.org/nightly/rustc/platform-support.html) for them), but it seems that the Debian/Ubuntu's cross-compiler (powerpc-linux-gnu-gcc) already uses --enable-secureplt at least as of Debian 9 (stretch) and Ubuntu 14.04.
```
$ cat /etc/os-release | grep VERSION_ID
VERSION_ID="9"
$ powerpc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=powerpc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/powerpc-linux-gnu/6/lto-wrapper
Target: powerpc-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-powerpc-cross/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-powerpc-cross --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-powerpc-cross --with-arch-directory=ppc --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libgcj --enable-objc-gc=auto --enable-secureplt --disable-softfloat --with-cpu=default32 --disable-softfloat --enable-targets=powerpc-linux,powerpc64-linux --enable-multiarch --with-long-double-128 --enable-multilib --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=powerpc-linux-gnu --program-prefix=powerpc-linux-gnu- --includedir=/usr/powerpc-linux-gnu/include
Thread model: posix
gcc version 6.3.0 20170516 (Debian 6.3.0-18)
```
```
$ cat /etc/os-release | grep VERSION_ID
VERSION_ID="14.04"
$ cat /etc/debian_version
jessie/sid
$ powerpc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=powerpc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/powerpc-linux-gnu/4.8/lto-wrapper
Target: powerpc-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.4-2ubuntu1~14.04.1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/powerpc-linux-gnu/include/c++/4.8.4 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --disable-libitm --disable-libsanitizer --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-powerpc-cross/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-powerpc-cross --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-powerpc-cross --with-arch-directory=ppc --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libgcj --enable-objc-gc --enable-secureplt --disable-softfloat --with-cpu=default32 --disable-softfloat --enable-targets=powerpc-linux,powerpc64-linux --enable-multiarch --disable-werror --with-long-double-128 --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=powerpc-linux-gnu --program-prefix=powerpc-linux-gnu- --includedir=/usr/powerpc-linux-gnu/include
Thread model: posix
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.1)
```
cc ```@glaubitz``` (who added powerpc-unknown-linux-gnuspe in https://github.com/rust-lang/rust/pull/48484)
r? tgross35
```@rustbot``` label +O-PowerPC +O-linux-gnu
try-job: dist-powerpc-linux
try-job: dist-powerpc64-linux
try-job: dist-powerpc64le-linux
try-job: dist-various-1
try-job: dist-various-2
try-job: aarch64-gnu
|
|
Add `kl` and `widekl` target features, and the feature gate
This is an effort towards #134813. This PR adds the target-features and the feature gate to `rustc`
<!--
```@rustbot``` label O-x86_64 O-x86_32 A-target-feature
r? compiler
-->
|
|
Explicitly choose x86 softfloat/hardfloat ABI
Part of https://github.com/rust-lang/rust/pull/135408:
Instead of choosing this based on the target features listed in the target spec, make that choice explicit.
All built-in targets are being updated here; custom (JSON-defined) x86 (32bit and 64bit) softfloat targets need to explicitly set `rustc-abi` to `x86-softfloat`.
|
|
it for x86 softfloat
|
|
Support clobber_abi in BPF inline assembly
This supports [`clobber_abi`](https://doc.rust-lang.org/nightly/reference/inline-assembly.html#abi-clobbers) which is one of the requirements of stabilization mentioned in the tracking Issue for `asm_experimental_arch` (#93335).
Refs: [Section 1.1 "Registers and calling convention" in BPF ABI Recommended Conventions and Guidelines v1.0](https://github.com/torvalds/linux/blob/v6.13/Documentation/bpf/standardization/abi.rst#11registers-and-calling-convention)
> R0 - R5 are scratch registers and BPF programs needs to spill/fill them if necessary across calls.
cc `@alessandrod` `@dave-tucker` `@tamird` `@vadorovsky` (target maintainers mentioned in platform support document which will be added by https://github.com/rust-lang/rust/pull/135107)
r? `@Amanieu`
`@rustbot` label +O-eBPF +A-inline-assembly
|
|
Add target and compile the amdgpu llvm backend.
|
|
Target option to require explicit cpu
Some targets have many different CPUs and no generic CPU that can be used as a default. For these targets, the user needs to explicitly specify a CPU through `-C target-cpu=`.
Add an option for targets and an error message if no CPU is set.
This affects the proposed amdgpu and avr targets.
amdgpu tracking issue: #135024
AVR MCP: https://github.com/rust-lang/compiler-team/issues/800
|
|
Rollup of 9 pull requests
Successful merges:
- #136121 (Deduplicate operand creation between scalars, non-scalars and string patterns)
- #136134 (Fix SIMD codegen tests on LLVM 20)
- #136153 (Locate asan-odr-win with other sanitizer tests)
- #136161 (rustdoc: add nobuild typescript checking to our JS)
- #136166 (interpret: is_alloc_live: check global allocs last)
- #136168 (GCI: Don't try to eval / collect mono items inside overly generic free const items)
- #136170 (Reject unsound toggling of Arm atomics-32 target feature)
- #136176 (Render pattern types nicely in mir dumps)
- #136186 (uefi: process: Fix args)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
in inline assembly, show the supported register classes when an invalid one is found
|
|
Reject unsound toggling of Arm atomics-32 target feature
This target feature has the same semantics as RISC-V `forced-atomics` target feature that already marked as Forbidden (https://github.com/llvm/llvm-project/commit/f5ed0cb217a9988f97b55f2ccb053bca7b41cc0c) and toggling it can cause ABI incompatibility.
https://github.com/rust-lang/rust/blob/2f348cb7ce4063fa4eb40038e6ada3c5214717bd/compiler/rustc_target/src/target_features.rs#L479-L483
[Comment on feature definition in LLVM](https://github.com/llvm/llvm-project/blob/7109f521975e9cc2e8ba4f52ac2a8e1140bd49b5/llvm/lib/Target/ARM/ARMFeatures.td#L572-L574) also says:
> Code built with this feature is not ABI-compatible with code built without this feature, if atomic variables are exposed across the ABI boundary.
r? `@workingjubilee` or `@RalfJung`
`@rustbot` label +O-Arm
|
|
r=workingjubilee
ABI-required target features: warn when they are missing in base CPU
Part of https://github.com/rust-lang/rust/pull/135408:
instead of adding ABI-required features to the target we build for LLVM, check that they are already there. Crucially we check this after applying `-Ctarget-cpu` and `-Ctarget-feature`, by reading `sess.unstable_target_features`. This means we can tweak the ABI target feature check without changing the behavior for any existing user; they will get warnings but the target features behave as before.
The test changes here show that we are un-doing the "add all required target features" part. Without the full #135408, there is no way to take a way an ABI-required target feature with `-Ctarget-cpu`, so we cannot yet test that part.
Cc ``@workingjubilee``
|
|
|
|
|
