about summary refs log tree commit diff
path: root/compiler/rustc_target
AgeCommit message (Collapse)AuthorLines
2023-07-24compiler: Add `riscv64gc-unknown-hermit` targetSimon Schöning-0/+21
Co-authored-by: Martin Kröning <martin.kroening@eonerc.rwth-aachen.de> Signed-off-by: Martin Kröning <martin.kroening@eonerc.rwth-aachen.de>
2023-07-24compiler: Hermit targets: Use functional update syntaxMartin Kröning-15/+15
instead of mutating the base. Signed-off-by: Martin Kröning <martin.kroening@eonerc.rwth-aachen.de>
2023-07-24compiler: Hermit targets: Sort base fields by declarationMartin Kröning-6/+6
Signed-off-by: Martin Kröning <martin.kroening@eonerc.rwth-aachen.de>
2023-07-24compiler: Hermit targets: Remove pre-link args.Martin Kröning-6/+0
These pre-link args are remains from Hermit's old C version. We don't need them and we have no reason to override the defaults here. See ld [1] for details. [1]: https://sourceware.org/binutils/docs/ld/Options.html Signed-off-by: Martin Kröning <martin.kroening@eonerc.rwth-aachen.de>
2023-07-23Fix comments about GCC/Clang's enum width for arm-none targets.Chris Copeland-8/+8
GCC uses the `-fshort-enums` ABI for arm-none and the `int`-sized enum ABI for arm-linux. Clang uses the `int`-sized enum ABI for all arm targets. Both options are permitted by AAPCS. Rust is matching GCC's behavior for these targets, as interop with code code compiled by GCC is desirable in the bare-metal context. See #87917.
2023-07-23Remove redundant `c_enum_min_bits` option from the thumbv4t-none-eabi target.Chris Copeland-2/+0
This option is the same as the `thumb_base` defaults used by this target.
2023-07-23Remove "-unknown" from `llvm_target` for arm*v7r-none-eabi* targets.Chris Copeland-4/+4
2023-07-21Revert "Auto merge of #113166 - moulins:ref-niches-initial, r=oli-obk"David Tolnay-5/+1
This reverts commit 557359f92512ca88b62a602ebda291f17a953002, reversing changes made to 1e6c09a803fd543a98bfbe1624d697a55300a786.
2023-07-21Auto merge of #113922 - matthiaskrgr:rollup-90cj2vv, r=matthiaskrgrbors-21/+0
Rollup of 4 pull requests Successful merges: - #113887 (new solver: add a separate cache for coherence) - #113910 (Add FnPtr ty to SMIR) - #113913 (error/E0691: include alignment in error message) - #113914 (rustc_target: drop duplicate code) r? `@ghost` `@rustbot` modify labels: rollup
2023-07-21rustc_target: drop duplicate codeDavid Rheinsberg-21/+0
Drop duplicate helper methods on `Layout`, which are already implemented on `LayoutS`. Note that `Layout` has a `Deref` implementation to `LayoutS`, so all accessors are automatically redirected. The methods are identical and have been copied to `rustc_abi` in: commit 390a637e296ccfaac4c6abd1291b0523e8a8e00b Author: hamidreza kalbasi <hamidrezakalbasi@protonmail.com> Date: Mon Nov 7 00:36:11 2022 +0330 move things from rustc_target::abi to rustc_abi This commit left behind the original implementation. Drop it now. Signed-off-by: David Rheinsberg <david@readahead.eu>
2023-07-21Don't treat ref. fields with non-null niches as `dereferenceable_or_null`Moulins-1/+5
2023-07-18support for mips32r6 as a target_arch valuechenx97-4/+4
2023-07-18merge patternschenx97-4/+2
2023-07-18support for mips64r6 as a target_arch valuechenx97-2/+4
2023-07-18Auto merge of #113061 - Amanieu:x86_64-ohos, r=compiler-errorsbors-10/+42
Add x86_64-unknown-linux-ohos target This complements the existing `aarch64-unknown-linux-ohos` and `armv7-unknown-linux-ohos` targets. This should be covered by the existing MCP (https://github.com/rust-lang/compiler-team/issues/568), but I can also create a new MCP if that is preferred.
2023-07-17Rollup merge of #113535 - jonathanpallant:sparc-bare-metal, r=jackh726Matthias Krüger-0/+29
Add a sparc-unknown-none-elf target. # `sparc-unknown-none-elf` **Tier: 3** Rust for bare-metal 32-bit SPARC V7 and V8 systems, e.g. the Gaisler LEON3. ## Target maintainers - Jonathan Pallant, `jonathan.pallant@ferrous-systems.com`, https://ferrous-systems.com ## Requirements > Does the target support host tools, or only cross-compilation? Only cross-compilation. > Does the target support std, or alloc (either with a default allocator, or if the user supplies an allocator)? Only tested with `libcore` but I see no reason why you couldn't also support `liballoc`. > Document the expectations of binaries built for the target. Do they assume specific minimum features beyond the baseline of the CPU/environment/etc? What version of the OS or environment do they expect? Tested by linking with a standard SPARC bare-metal toolchain - specifically I used the [BCC2] toolchain from Gaisler (both GCC and clang variants, both pre-compiled for x64 Linux and compiling my own SPARC GCC from source to run on `aarch64-apple-darwin`). The target is set to use the lowest-common-denominator `SPARC V7` architecture (yes, they started at V7 - see [Wikipedia](https://en.wikipedia.org/wiki/SPARC#History)). [BCC2]: https://www.gaisler.com/index.php/downloads/compilers > Are there notable `#[target_feature(...)]` or `-C target-feature=` values that programs may wish to use? `-Ctarget-cpu=v8` adds the instructions added in V8. `-Ctarget-cpu=leon3` adds the V8 instructions and sets up scheduling to suit the Gaisler LEON3. > What calling convention does `extern "C"` use on the target? I believe this is defined by the SPARC architecture reference manuals and V7, V8 and V9 are all compatible. > What format do binaries use by default? ELF, PE, something else? ELF ## Building the target > If Rust doesn't build the target by default, how can users build it? Can users just add it to the `target` list in `config.toml`? Yes. I did: ```toml target = ["aarch64-apple-darwin", "sparc-unknown-none-elf"] ``` ## Building Rust programs > Rust does not yet ship pre-compiled artifacts for this target. To compile for this target, you will either need to build Rust with the target enabled (see "Building the target" above), or build your own copy of `core` by using `build-std` or similar. Correct. ## Testing > Does the target support running binaries, or do binaries have varying expectations that prevent having a standard way to run them? No - it's a bare metal platform. > If users can run binaries, can they do so in some common emulator, or do they need native hardware? But if you use [BCC2] as the linker, you get default memory map suitable for the LEON3, and a default BSP for the LEON3, and so you can run the binaries in the `tsim-leon3` simulator from Gaisler. ```console $ cat .cargo/config.toml | grep runner runner = "tsim-leon3 -c sim-commands.txt" $ cat sim-commands.txt run quit $ cargo +sparcrust run --targe=sparc-unknown-none-elf Compiling sparc-demo-rust v0.1.0 (/work/sparc-demo-rust) Finished dev [unoptimized + debuginfo] target(s) in 3.44s Running `tsim-leon3 -c sim-commands.txt target/sparc-unknown-none-elf/debug/sparc-demo-rust` TSIM3 LEON3 SPARC simulator, version 3.1.9 (evaluation version) Copyright (C) 2023, Frontgrade Gaisler - all rights reserved. This software may only be used with a valid license. For latest updates, go to https://www.gaisler.com/ Comments or bug-reports to support@gaisler.com This TSIM evaluation version will expire 2023-11-28 Number of CPUs: 2 system frequency: 50.000 MHz icache: 1 * 4 KiB, 16 bytes/line (4 KiB total) dcache: 1 * 4 KiB, 16 bytes/line (4 KiB total) Allocated 8192 KiB SRAM memory, in 1 bank at 0x40000000 Allocated 32 MiB SDRAM memory, in 1 bank at 0x60000000 Allocated 8192 KiB ROM memory at 0x00000000 section: .text, addr: 0x40000000, size: 104400 bytes section: .rodata, addr: 0x400197d0, size: 15616 bytes section: .data, addr: 0x4001d4d0, size: 1176 bytes read 1006 symbols Initializing and starting from 0x40000000 Hello, this is Rust! PANIC: PanicInfo { payload: Any { .. }, message: Some(I am a panic), location: Location { file: "src/main.rs", line: 33, col: 5 }, can_unwind: true } Program exited normally on CPU 0. ``` > Does the target support running the Rust testsuite? I don't think so, the testsuite requires `libstd` IIRC. ## Cross-compilation toolchains and C code > Does the target support C code? Yes. > If so, what toolchain target should users use to build compatible C code? (This may match the target triple, or it may be a toolchain for a different target triple, potentially with specific options or caveats.) I suggest [BCC2] from Gaisler. It comes in both GCC and Clang variants.
2023-07-14i686-windows: make requested alignment > 4 special case apply transitivelyErik Desjardins-4/+4
2023-07-11Add a sparc-unknown-none-elf target.Jonathan Pallant (Ferrous Systems)-0/+29
Tested with the Gaisler bcc2 toolchain (both gcc and clang) and the Leon3 simulator.
2023-07-10aarch64-linux: properly handle 128bit aligned aggregatesErik Desjardins-36/+44
2023-07-10repr(align) <= 4 should still be byvalErik Desjardins-2/+6
2023-07-10move has_repr to layout, handle repr(transparent) properlyErik Desjardins-15/+2
2023-07-10i686-windows: pass arguments with requested alignment > 4 indirectlyErik Desjardins-4/+34
2023-07-10implement vector-containing aggregate alignment for x86 darwinErik Desjardins-31/+51
2023-07-10rustc_target: Add alignment to indirectly-passed by-value types, correcting thePatrick Walton-13/+47
alignment of `byval` on x86 in the process. Commit 88e4d2c2918428d55e34cd57c11279ea839c8822 from five years ago removed support for alignment on indirectly-passed arguments because of problems with the `i686-pc-windows-msvc` target. Unfortunately, the `memcpy` optimizations I recently added to LLVM 16 depend on this to forward `memcpy`s. This commit attempts to fix the problems with `byval` parameters on that target and now correctly adds the `align` attribute. The problem is summarized in [this comment] by @eddyb. Briefly, 32-bit x86 has special alignment rules for `byval` parameters: for the most part, their alignment is forced to 4. This is not well-documented anywhere but in the Clang source. I looked at the logic in Clang `TargetInfo.cpp` and tried to replicate it here. The relevant methods in that file are `X86_32ABIInfo::getIndirectResult()` and `X86_32ABIInfo::getTypeStackAlignInBytes()`. The `align` parameter attribute for `byval` parameters in LLVM must match the platform ABI, or miscompilations will occur. Note that this doesn't use the approach suggested by eddyb, because I felt it was overkill to store the alignment in `on_stack` when special handling is really only needed for 32-bit x86. As a side effect, this should fix #80127, because it will make the `align` parameter attribute for `byval` parameters match the platform ABI on LLVM x86-64. [this comment]: https://github.com/rust-lang/rust/pull/80822#issuecomment-829985417
2023-07-05Add support for NetBSD/riscv64 aka. riscv64gc-unknown-netbsd.Havard Eidnes-0/+20
2023-07-03abi: avoid ice for non-ffi-safe fn ptrsDavid Wood-4/+6
Remove an `unwrap` that assumed FFI-safe types in foreign fn-ptr types. Signed-off-by: David Wood <david.wood@huawei.com>
2023-06-30require `-Zunstable-options` to use new link-self-contained values andRémy Rakic-0/+23
linker flavors - only the stable values for `-Clink-self-contained` can be used on stable until we have more feedback on the interface - `-Zunstable-options` is required to use unstable linker flavors
2023-06-30implement `-C linker-flavor` modern flavorsRémy Rakic-8/+73
2023-06-30add whether `LinkerFlavor` invokes the linker via a C/C++ compilerRémy Rakic-0/+19
2023-06-30add whether `LinkerFlavor` uses `lld`Rémy Rakic-0/+18
2023-06-30Auto merge of #106619 - agausmann:avr-object-file, r=nagisabors-0/+343
Fix unset e_flags in ELF files generated for AVR targets Closes #106576 ~~Sort-of blocked by gimli-rs/object#500~~ (merged) I'm not sure whether the list of AVR CPU names is okay here. Maybe it could be moved out-of-line to improve the readability of the function.
2023-06-26Add x86_64-unknown-linux-ohos targetAmanieu d'Antras-10/+42
This complements the existing `aarch64-unknown-linux-ohos` and `armv7-unknown-linux-ohos` targets.
2023-06-26Rollup merge of #111326 - he32:netbsd-aarch64-be, r=oli-obkMatthias Krüger-0/+18
Add support for NetBSD/aarch64-be (big-endian arm64).
2023-06-22switch to using a target property to control plt defaultAugie Fackler-5/+30
2023-06-21Reorder `tvos_*` functions in apple_base.rs to avoid breaking sorted orderThom Chiovoloni-10/+12
2023-06-21Fix rustc_target::spec::apple::testsThom Chiovoloni-1/+4
2023-06-21Fix the tvOS targets to use the right LLVM target and respect the deployment ↵Thom Chiovoloni-5/+19
target environment variables
2023-06-21Fix busted data_layout (mismatch vs LLVM) in x86_64 tvOS simulator targetThom Chiovoloni-1/+2
2023-06-13loongarch64-none*: Remove environment component from llvm targetWANG Rui-1/+1
2023-06-13Auto merge of #112386 - loongarch-rs:reloc-static, r=eholkbors-6/+4
loongarch64-unknown-none*: Set default relocation model to static This PR sets the default relocation model to `static` for `loongarch64-unknown-none*` targets. This change aims to streamline the development of the bare-metal project by removing the need for the executable program loader to implement relocation.
2023-06-07Auto merge of #111698 - Amanieu:force-static-lib, r=petrochenkovbors-0/+11
Force all native libraries to be statically linked when linking a static binary Previously, `#[link]` without an explicit `kind = "static"` would confuse the linker and end up producing a dynamically linked library because of the `-Bdynamic` flag. However this binary would not work correctly anyways since it was linked with startup code for a static binary. This PR solves this by forcing all native libraries to be statically linked when the output is a static binary that cannot link to dynamic libraries anyways. Fixes #108878 Fixes #102993
2023-06-07Force all native libraries to be statically linked when linking a static binaryAmanieu d'Antras-0/+11
2023-06-07loongarch64-unknown-none*: Set default relocation model to staticWANG Rui-6/+4
2023-06-07Auto merge of #111819 - nikarh:vita-improved, r=Amanieubors-7/+8
Improved std support for ps vita target Fixed a couple of things in std support for ps vita via Vita SDK newlib oss implementation: - Added missing hardware features to target spec - Compile in thumb by default (newlib is also compiled in thumb) - Fixed fs calls. Vita newlib has a not-very-posix dirent. Also vita does not expose inodes, it's stubbed as 0 in stat, and I'm stubbing it here for dirent (because vita newlibs's dirent doesn't even have that field) - Enabled signal handlers for panic unwinding - Dropped static link requirement from the platform support md. Also, rearranged sections to better stick with the template.
2023-06-06Auto merge of #112361 - matthiaskrgr:rollup-39zxrw1, r=matthiaskrgrbors-0/+50
Rollup of 8 pull requests Successful merges: - #111250 (Add Terminator conversion from MIR to SMIR, part #2) - #112310 (Add new Tier-3 targets: `loongarch64-unknown-none*`) - #112334 (Add myself to highfive rotation) - #112340 (remove `TyCtxt::has_error_field` helper method) - #112343 (Prevent emitting `missing_docs` for `pub extern crate`) - #112350 (Avoid duplicate type sanitization of local decls in borrowck) - #112356 (Fix comment for `get_region_var_origins`) - #112358 (Remove default visitor impl in region constraint generation) r? `@ghost` `@rustbot` modify labels: rollup
2023-06-06Add new Tier-3 targets: `loongarch64-unknown-none*`WANG Rui-0/+50
MCP: https://github.com/rust-lang/compiler-team/issues/628
2023-06-05Std support improvement for ps vita targetNikolay Arhipov-7/+8
2023-06-04Added custom risc32-imac for esp-espidf targetVictor Gil-0/+32
2023-06-02Auto merge of #112198 - compiler-errors:rollup-o2xe4of, r=compiler-errorsbors-5/+5
Rollup of 7 pull requests Successful merges: - #111670 (Require that const param tys implement `ConstParamTy`) - #111914 (CFI: Fix cfi with async: transform_ty: unexpected GeneratorWitness(Bi…) - #112030 (Migrate `item_trait_alias` to Askama) - #112150 (Support 128-bit atomics on all x86_64 Apple targets) - #112174 (Fix broken link) - #112190 (Improve comments on `TyCtxt` and `GlobalCtxt`.) - #112193 (Check tuple elements are `Sized` in `offset_of`) Failed merges: - #112071 (Group rfcs tests) r? `@ghost` `@rustbot` modify labels: rollup
2023-06-01Rollup merge of #112174 - cuishuang:master, r=jyn514Michael Goulet-1/+1
Fix broken link The previous link is no longer accessible. Use the latest link.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-10 12:16:58 +0000