| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This commit removes the `avr-unknown-gnu-atmega328` target and replaces
it with a more generic `avr-none` variant that must be specialized with
the `-C target-cpu` flag (e.g. `-C target-cpu=atmega328p`).
|
|
x86_win64 ABI: do not use xmm0 with softfloat ABI
This adjusts https://github.com/rust-lang/rust/pull/134290 to not apply the new logic to targets marked as "softfloat". That fixes most instances of the issue brought up [here](https://github.com/rust-lang/rust/issues/116558#issuecomment-2661027437).
r? `@tgross35`
|
|
|
|
|
|
|
|
Remove SSE ABI from i586-pc-windows-msvc
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
```
see #116344.
r? RalfJung
|
|
rustc_target: import TargetMetadata
|
|
|
|
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
```
|
|
Load all builtin targets at once instead of one by one in check-cfg
This PR adds a method on `rustc_target::Target` to load all the builtin targets at once, and then uses that method when constructing the `target_*` values in check-cfg instead of load loading each target one by one by their name, which requires a lookup and was more of a hack anyway.
This may give us some performance improvements as we won't need to do the lookup for the _currently_ 287 targets we have.
|
|
nvptx64: update default alignment to match LLVM 21
This changed in llvm/llvm-project@91cb8f5d3202870602c6bef807bc4c7ae8a32790. The commit itself is mostly about some intrinsic instructions, but as an aside it also mentions something about addrspace for tensor memory, which I believe is what this string is telling us.
`@rustbot` label: +llvm-main
|
|
This should give us some performance improvements as we won't need to
do the lookup for the _currently_ 287 targets we have.
|
|
|
|
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
|
|
This changed in llvm/llvm-project@91cb8f5d3202870602c6bef807bc4c7ae8a32790.
The commit itself is mostly about some intrinsic instructions, but as an
aside it also mentions something about addrspace for tensor memory,
which I believe is what this string is telling us.
@rustbot label: +llvm-main
|
