about summary refs log tree commit diff
path: root/compiler/rustc_target
AgeCommit message (Collapse)AuthorLines
2025-02-07compiler: remove rustc_target::abi entirelyJubilee Young-78/+119
2025-02-07rustc_target: Add the fp16 target feature for AArch32Kajetan Puchalski-0/+1
2025-02-07i686-unknown-hurd-gnu: bump baseline CPU to Pentium 4Ralf Jung-1/+1
2025-02-07Replace i686-unknown-redox target with i586-unknown-redoxJeremy Soller-3/+3
2025-02-07Rollup merge of #136565 - workingjubilee:fixup-abi-in-target, r=compiler-errorsMatthias Krüger-125/+143
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.
2025-02-07Rollup merge of #136191 - klensy:const_a, r=compiler-errorsMatthias Krüger-10/+10
compiler: replace few consts arrays with statics to remove const dupes Locally on `x86_64-pc-windows-msvc` -100kb for `rustc_driver.dll`
2025-02-06compiler: make rustc_target have less weird reexportsJubilee Young-125/+143
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.
2025-02-05Rollup merge of #133932 - bjorn3:fix_ptx_kernel_abi, r=wesleywiserJubilee-14/+30
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
2025-02-05Rollup merge of #136154 - taiki-e:ppc-secure-plt, r=nikic许杰友 Jieyou Xu (Joe)-1/+7
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
2025-02-04nvptx64: update default alignment to match LLVM 21Augie Fackler-1/+1
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
2025-02-04Rollup merge of #134814 - sayantn:keylocker, r=oli-obkMatthias Krüger-0/+2
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 -->
2025-02-03Auto merge of #136146 - RalfJung:x86-abi, r=workingjubileebors-24/+103
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`.
2025-02-03add rustc_abi to control ABI decisions LLVM does not have flags for, and use ↵Ralf Jung-24/+103
it for x86 softfloat
2025-01-31Rollup merge of #136194 - taiki-e:bpf-clobber-abi, r=amanieuMatthias Krüger-0/+13
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
2025-01-31Add amdgpu targetFlakebi-0/+53
Add target and compile the amdgpu llvm backend.
2025-01-30Auto merge of #135030 - Flakebi:require-cpu, r=workingjubileebors-0/+6
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
2025-01-29Auto merge of #136227 - fmease:rollup-ewpvznh, r=fmeasebors-0/+5
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
2025-01-29show supported register classesFolkert de Vries-3/+3
in inline assembly, show the supported register classes when an invalid one is found
2025-01-29Rollup merge of #136170 - taiki-e:atomics-32, r=workingjubileeLeón Orell Valerian Liehr-0/+5
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
2025-01-29Rollup merge of #136147 - RalfJung:required-target-features-check-not-add, ↵León Orell Valerian Liehr-13/+11
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``
2025-01-29Support clobber_abi in BPF inline assemblyTaiki Endo-0/+13
2025-01-28replaces few consts with statics to reduce readonly sectionklensy-10/+10
2025-01-28Auto merge of #134290 - tgross35:windows-i128-callconv, r=bjorn3,wesleywiserbors-7/+13
Windows x86: Change i128 to return via the vector ABI Clang and GCC both return `i128` in xmm0 on windows-msvc and windows-gnu. Currently, Rust returns the type on the stack. Add a calling convention adjustment so we also return scalar `i128`s using the vector ABI, which makes our `i128` compatible with C. In the future, Clang may change to return `i128` on the stack for its `-msvc` targets (more at [1]). If this happens, the change here will need to be adjusted to only affect MinGW. Link: https://github.com/rust-lang/rust/issues/134288 (does not fix) [1] try-job: x86_64-msvc try-job: x86_64-msvc-ext1 try-job: x86_64-mingw-1 try-job: x86_64-mingw-2
2025-01-28Reject unsound toggling of Arm atomics-32 target featureTaiki Endo-0/+5
2025-01-28update commentsRalf Jung-13/+11
2025-01-28Use +secure-plt for powerpc-unknown-linux-gnu{,spe}Taiki Endo-1/+7
2025-01-27Windows x86: Change `i128` to return via the vector ABITrevor Gross-7/+13
Clang and GCC both return `i128` in xmm0 on windows-msvc and windows-gnu. Currently, Rust returns the type on the stack. Add a calling convention adjustment so we also return scalar `i128`s using the vector ABI, which makes our `i128` compatible with C. In the future, Clang may change to return `i128` on the stack for its `-msvc` targets (more at [1]). If this happens, the change here will need to be adjusted to only affect MinGW. Link: https://github.com/rust-lang/rust/issues/134288
2025-01-27Mark all NuttX targets as tier 3 target and support the standard libraryHuang Qi-37/+34
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
2025-01-26Restore previous ABI for f_single_u8_argbjorn3-1/+10
2025-01-26Avoid using make_direct_deprecated() in extern "ptx-kernel"bjorn3-16/+23
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().
2025-01-26Auto merge of #136087 - jhpratt:rollup-tam1mzn, r=jhprattbors-77/+190
Rollup of 7 pull requests Successful merges: - #133631 (Support QNX 7.1 with `io-sock`+libstd and QNX 8.0 (`no_std` only)) - #134358 (compiler: Set `target_abi = "ilp32e"` on all riscv32e targets) - #135812 (Fix GDB `OsString` provider on Windows ) - #135842 (TRPL: more backward-compatible Edition changes) - #135946 (Remove extra whitespace from rustdoc breadcrumbs for copypasting) - #135953 (ci.py: check the return code in `run-local`) - #136019 (Add an `unchecked_div` alias to the `Div<NonZero<_>>` impls) r? `@ghost` `@rustbot` modify labels: rollup
2025-01-26Rollup merge of #134358 - workingjubilee:configure-my-riscv-abi, r=fmeaseJacob Pratt-3/+9
compiler: Set `target_abi = "ilp32e"` on all riscv32e targets This allows compile-time configuration based on this. In the near future we should do this across all RISCV targets, probably, but this cfg is essential for building software usable on these targets, and they are tier 3 so it seems less of a concern to tweak their definition thusly.
2025-01-25Rollup merge of #135785 - folkertdev:s390x-vector-passmode-direct, r=bjorn3Jacob Pratt-3/+11
use `PassMode::Direct` for vector types on `s390x` closes https://github.com/rust-lang/rust/issues/135744 tracking issue: https://github.com/rust-lang/rust/issues/130869 Previously, all vector types were type erased to `Ni8`, now we pass non-wrapped vector types directly. That skips emitting a bunch of casting logic in rustc, that LLVM then has to clean up. The initial LLVM IR is also a bit more readable. This calling convention is tested extensively in `tests/assembly/s390x-vector-abi.rs`, showing that this change has no impact on the ABI in practice. r? ````@taiki-e````
2025-01-24add nto80 x86-64 and aarch64 targetAkhilTThomas-0/+24
Signed-off-by: Florian Bartels <Florian.Bartels@elektrobit.com>
2025-01-24Move common code to mod nto_qnxFlorian Bartels-118/+145
Signed-off-by: Florian Bartels <Florian.Bartels@elektrobit.com>
2025-01-24Add support for QNX 7.1 with io-sock on x64Florian Bartels-0/+28
Signed-off-by: Florian Bartels <Florian.Bartels@elektrobit.com>
2025-01-24Add new target for supporting Neutrino QNX 6.1 with `io-socket` network ↵Florian Bartels-0/+28
stack on aarch64 Signed-off-by: Florian Bartels <Florian.Bartels@elektrobit.com>
2025-01-24Auto merge of #135978 - matthiaskrgr:rollup-ni16gqr, r=matthiaskrgrbors-0/+203
Rollup of 8 pull requests Successful merges: - #133605 (Add extensive set of drop order tests) - #135489 (remove pointless allowed_through_unstable_modules on TryFromSliceError) - #135757 (Add NuttX support for AArch64 and ARMv7-A targets) - #135799 (rustdoc-json: Rename `Path::name` to `path`, and give it the path again.) - #135865 (For E0223, suggest associated functions that are similar to the path, even if the base type has multiple inherent impl blocks.) - #135890 (Implement `VecDeque::pop_front_if` & `VecDeque::pop_back_if`) - #135914 (Remove usages of `QueryNormalizer` in the compiler) - #135936 (fix reify-intrinsic test) r? `@ghost` `@rustbot` modify labels: rollup
2025-01-24Rollup merge of #135757 - no1wudi:master, r=compiler-errorsMatthias Krüger-0/+203
Add NuttX support for AArch64 and ARMv7-A targets This patch adds tier 3 support for AArch64 and ARMv7-A targets in NuttX, including: - AArch64 target: aarch64-unknown-nuttx - ARMv7-A target: armv7a-nuttx-eabi, armv7a-nuttx-eabihf - Thumbv7-A target: thumbv7a-nuttx-eabi, thumbv7a-nuttx-eabihf
2025-01-24Rollup merge of #135905 - workingjubilee:softly-sanitize-aarch64-floats, ↵Matthias Krüger-1/+3
r=rcvalle Enable kernel sanitizers for aarch64-unknown-none-softfloat We want kernels to be able to use this bare metal target, so let's enable the sanitizers that kernels want to use. cc ```@rcvalle``` ```@ojeda``` ```@maurer```
2025-01-23Rollup merge of #135790 - wesleywiser:update_windows_gnu_debuginfokind, r=lqdMatthias Krüger-2/+2
Update windows-gnu targets to set `DebuginfoKind::DWARF` These targets have always used DWARF debuginfo and not CodeView/PDB debuginfo like the MSVC Windows targets. However, their target definitions claim to use `DebuginfoKind::PDB` probably to ensure that we do not try to allow the use of split-DWARF debuginfo. This does not appear to be necessary since the targets set their supported split debug info to `Off`. I've looked at all of the uses of these properties and this patch does not appear to cause any functional changes in compiler behavior. I also added UI tests to attempt to validate there is no change in the behavior of these options on stable compilers. cc ````@mati865```` since you mentioned this in #135739 cc ````@davidtwco```` for split-dwarf
2025-01-22Enable kernel sanitizers for aarch64-unknown-none-softfloatJubilee Young-1/+3
We want kernels to be able to use this bare metal target, so let's enable the sanitizers that kernels want to use.
2025-01-22Rollup merge of #134396 - mustartt:byval-pointer-natural-alignment, ↵Matthias Krüger-1/+3
r=wesleywiser AIX: use align 8 for byval parameter On AIX, byval pointer arguments are aligned to 8 bytes based on the 64bit register size. For example, the C callee https://godbolt.org/z/5f4vnG6bh will expect the following argument. ``` ptr nocapture noundef readonly byval(%struct.TwoU64s) align 8 %0 ``` This case is captured by `run-make/extern-fn-explicit-align`
2025-01-20Set `DebuginfoKind::Dwarf` for `*-windows-gnu` and `*-windows-gnullvm`Wesley Wiser-2/+2
These targets have always generated DWARF debuginfo and not CodeView/PDB debuginfo like the MSVC Windows targets. Correct their target definitions to reflect this. The newly added tests for the various combinations of `*-windows-gnu*` targets and `-Csplit-debuginfo` show that this does not change any stable behavior.
2025-01-20on s390x, use `PassMode::Direct` for vector typesFolkert de Vries-3/+11
2025-01-20Add NuttX support for AArch64 and ARMv7-A targetsHuang Qi-0/+203
This patch adds tier 3 support for AArch64 and ARMv7-A targets in NuttX, including: - AArch64 target: aarch64-unknown-nuttx - ARMv7-A target: armv7a-nuttx-eabi, armv7a-nuttx-eabihf - Thumbv7-A target: thumbv7a-nuttx-eabi, thumbv7a-nuttx-eabihf Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
2025-01-17Auto merge of #135534 - folkertdev:fix-wasm-i128-f128, r=tgross35bors-0/+12
use indirect return for `i128` and `f128` on wasm32 fixes #135532 Based on https://github.com/WebAssembly/tool-conventions/blob/main/BasicCABI.md we now use an indirect return for `i128`, `u128` and `f128`. That is what LLVM ended up doing anyway. r? `@bjorn3`
2025-01-17Auto merge of #135047 - Flakebi:amdgpu-kernel-cc, r=workingjubileebors-0/+5
Add gpu-kernel calling convention The amdgpu-kernel calling convention was reverted in commit f6b21e90d1ec01081bc2619efb68af6788a63d65 (#120495 and https://github.com/rust-lang/rust-analyzer/pull/16463) due to inactivity in the amdgpu target. Introduce a `gpu-kernel` calling convention that translates to `ptx_kernel` or `amdgpu_kernel`, depending on the target that rust compiles for. Tracking issue: #135467 amdgpu target tracking issue: #135024
2025-01-16use indirect return for `i128` and `f128` on wasm32Folkert de Vries-0/+12
2025-01-16Target option to require explicit cpuFlakebi-0/+6
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.