about summary refs log tree commit diff
path: root/src/librustc_target
AgeCommit message (Collapse)AuthorLines
2019-11-22Add StableHashingContextLike to HashStable_Generic derive.Camille GILLOT-0/+5
2019-11-22Auto merge of #66460 - cjgillot:hashstable_generic, r=Zoxcbors-11/+24
Add a proc-macro to derive HashStable in librustc dependencies A second proc-macro is added to derive HashStable for crates librustc depends on. This proc-macro HashStable_Generic (to bikeshed) allows to decouple code and some librustc's boilerplate. Not everything is migrated, because `Span` and `TokenKind` require to be placed inside librustc. Types using them stay there too. Split out of #66279 r? @Zoxc
2019-11-19[RISCV] Disable Atomics on all Non-A RISC-V targetsSam Elliott-3/+2
2019-11-17Derive HashStable_Generic for ABI types.Camille GILLOT-52/+8
2019-11-17Derive HashStable for PanicStrategy.Camille GILLOT-1/+3
2019-11-17Derive HashStable in librustc_target.Camille GILLOT-8/+59
2019-11-17HashStable_Generic for librustc_target.Camille GILLOT-1/+5
2019-11-12Rollup merge of #66257 - mati865:long-section-names-no-more, r=alexcrichtonYuki Okushi-27/+0
Drop long-section-names linker workaround for windows-gnu If we can trust objdump Rust doesn't emit sections loaded at runtime longer than 8 characters on windows-gnu (but still does on linux-gnu), debug sections are not affected by that limit. I've ran tests and built few crates using exactly the same mingw-w64 version as Rusts CI just fine using **x86_64** toolchain. The motivation for this change is making LLD work (it doesn't support `--enable-long-section-names`) with this target without hacks. Bit of history: The behaviour of LD changed in Binutils 2.20 released on 2009-10-16 and `--enable-long-section-names` was added to return to the old non conformant behaviour. Looking at the comment I can only guess there was a bug fixed in newer versions. This workaround was added in https://github.com/rust-lang/rust/pull/13315 half a decade ago.
2019-11-10Undo an assert causing an ICE until we fix the problem properlyOliver Scherer-5/+1
2019-11-09Drop long-section-names linker workaround for windows-gnuMateusz MikuĊ‚a-27/+0
2019-11-09Rollup merge of #66050 - smaeul:patch/powerpc-abi-2, r=eddybMazdak Farrokhzad-32/+11
Fix C aggregate-passing ABI on powerpc The existing code (which looks like it was copied from MIPS) passes aggregates by value in registers. This is wrong. According to the SVR4 powerpc psABI, all aggregates are passed indirectly. See #64259 for more discussion, which addresses the ABI for the special case of ZSTs (empty structs).
2019-11-07rustc_target: inline abi::FloatTy into abi::Primitive.Eduard-Mihai Burtescu-18/+12
2019-11-07syntax: use distinct FloatTy from rustc_target.Mazdak Farrokhzad-39/+1
We also sever syntax's dependency on rustc_target as a result. This should slightly improve pipe-lining. Moreover, some cleanup is done in related code.
2019-11-06Rollup merge of #66103 - smaeul:patch/thumb-musl, r=nagisaMazdak Farrokhzad-0/+38
Add target thumbv7neon-unknown-linux-musleabihf This is a copy of thumbv7neon-unknown-linux-gnueabihf with musl changes merged from armv7-unknown-linux-musleabihf. This appears to have been missed when adding the other ARMv7-A thumb targets.
2019-11-05Fix C aggregate-passing ABI on powerpcSamuel Holland-32/+11
The existing code (which looks like it was copied from MIPS) passes aggregates by value in registers. This is wrong. According to the SVR4 powerpc psABI, all aggregates are passed indirectly. See #64259 for more discussion, which addresses the ABI for the special case of ZSTs (empty structs).
2019-11-05Rollup merge of #65953 - keystone-enclave:llvm_abiname, r=alexcrichtonPietro Albini-1/+7
Allow specifying LLVM's MCTargetOptions::ABIName in target specification files This addresses #65024, as it allows RISC-V target specification files to set `"llvm-abiname": "lp64d"`. Other languages (read: C) usually expose this codegen parameter under a compiler argument like `-mabi=<XYZ>`.
2019-11-04Add target thumbv7neon-unknown-linux-musleabihfSamuel Holland-0/+38
This is a copy of thumbv7neon-unknown-linux-gnueabihf with musl changes merged from armv7-unknown-linux-musleabihf.
2019-11-03rustc_target: rename {Fn,Arg}Type to {Fn,Arg}Abi.Eduard-Mihai Burtescu-185/+185
2019-10-29Allow specifying key "llvm-abiname" in target specificationGui Andrade-1/+7
This addresses #65024, as it allows RISC-V target specification files to set "llvm-abiname": "lp64d". In general, it is useful for the programmer to be able to set this codegen parameter, which other languages usually expose under a compiler argument like "-mabi=<XYZ>".
2019-10-29Rollup merge of #65832 - tlively:emscripten-exception-handling, r=alexcrichtonTyler Mandry-9/+2
Re-enable Emscripten's exception handling support Passes LLVM codegen and Emscripten link-time flags for exception handling if and only if the panic strategy is `unwind`. Sets the default panic strategy for Emscripten targets to `unwind`. Re-enables tests that depend on unwinding support for Emscripten, including `should_panic` tests. r? @alexcrichton
2019-10-29Rollup merge of #65809 - roblabla:eficall-abi, r=nagisaMazdak Farrokhzad-0/+9
Add new EFIAPI ABI Fixes #54527 Adds a new ABI, "efiapi", which reflects the calling convention as specified by [the current spec UEFI spec](https://uefi.org/sites/default/files/resources/UEFI%20Spec%202_7_A%20Sept%206.pdf#G6.999903). When compiling for x86_64, we should select the `win64` ABI, while on all other architectures (Itanium, x86, ARM and ARM64 and RISC-V), we should select the `C` ABI. Currently, this is done by just turning it into the C ABI everywhere except on x86_64, where it's turned into the win64 ABI. Should we prevent this ABI from being used on unsupported architectures, and if so, how would this be done?
2019-10-29Rollup merge of #65294 - varkor:lint-inline-prototype, r=matthewjasperMazdak Farrokhzad-1/+1
Lint ignored `#[inline]` on function prototypes Fixes https://github.com/rust-lang/rust/issues/51280. - Adds a `unused_attribute` lint for `#[inline]` on function prototypes. - As a consequence, foreign items, impl items and trait items now have their attributes checked, which could cause some code to no longer compile (it was previously erroneously ignored).
2019-10-25Update bitflagsvarkor-1/+1
2019-10-25Re-enable Emscripten's exception handling supportThomas Lively-9/+2
Passes LLVM codegen and Emscripten link-time flags for exception handling if and only if the panic strategy is `unwind`. Sets the default panic strategy for Emscripten targets to `unwind`. Re-enables tests that depend on unwinding support for Emscripten, including `should_panic` tests.
2019-10-25Fix inverted check in EFIAPIroblabla-1/+1
2019-10-25Add new EFIAPI ABIroblabla-0/+9
Adds a new ABI for the EFIAPI calls. This ABI should reflect the latest version of the UEFI specification at the time of commit (UEFI spec 2.8, URL below). The specification says that for x86_64, we should follow the win64 ABI, while on all other supported platforms (ia32, itanium, arm, arm64 and risc-v), we should follow the C ABI. To simplify the implementation, we will simply follow the C ABI on all platforms except x86_64, even those technically unsupported by the UEFI specification. https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf
2019-10-22Merge branch 'master' into rusty-hermitStefan Lankes-4/+2
2019-10-21Remove many unnecessary trait derivations.Nicholas Nethercote-4/+2
2019-10-20Merge branch 'master' into rusty-hermitStefan Lankes-1/+15
2019-10-17Don't add `argc` and `argv` arguments to `main` on WASI.Dan Gohman-0/+10
Add a target setting to allow targets to specify whether the generated `main` function should be passed `argc` and `argv` arguments. Set it to false on wasm32-wasi, since WASI's `args::args()` calls into the WASI APIs itself. This will allow the WASI toolchain to avoid linking and running command-line argument initialization code when the arguments aren't actually needed.
2019-10-16Upgrade Emscripten targets to use upstream LLVM backendThomas Lively-164/+105
- Compatible with Emscripten 1.38.46-upstream or later upstream. - Refactors the Emscripten target spec to share code with other wasm targets. - Replaces the old incorrect wasm32 C call ABI with the correct one, preserving the old one as wasm32_bindgen_compat for wasm-bindgen compatibility. - Updates the varargs ABI used by Emscripten and deletes the old one. - Removes the obsolete wasm32-experimental-emscripten target. - Uses EMCC_CFLAGS on CI to avoid the timeout problems with #63649.
2019-10-10Check that we don't access nonexisting union fieldsOliver Scherer-1/+5
2019-10-06redesign of the interface to the unikernel HermitCoreStefan Lankes-16/+16
- the old interface between HermitCore and the Rust Standard Library based on a small C library (newlib) - remove this interface and call directly the unikernel - remove the dependency to the HermitCore linker - use rust-lld as linker
2019-10-04Add C ABI for wasm-bindgen compatThomas Lively-0/+30
2019-10-04Fix ABI, run and fix more tests, re-enable CI for PRsThomas Lively-10/+30
2019-10-04Upgrade Emscripten targets to use upstream LLVM backendThomas Lively-164/+55
- Refactors the Emscripten target spec to share code with other wasm targets. - Replaces the incorrect wasm32 C call ABI with the old asmjs version, which is correct for both wasm32 and JS. - Updates the varargs ABI used by Emscripten and deletes the old one. - Removes the obsolete wasm32-experimental-emscripten target. - Temporarily makes Emscripten targets use panic=abort by default because supporting unwinding will require an LLVM patch.
2019-09-29remove indexed_vec re-export from rustc_data_structurescsmoe-3/+3
2019-09-29Rollup merge of #64589 - andre-richter:aarch64_bare_metal, r=AmanieuMazdak Farrokhzad-2/+40
Differentiate AArch64 bare-metal targets between hf and non-hf. CC @parched, kindly request you to review. ~~Note: This change breaks code that uses the target `aarch64-unknown-none` for the sake of clearer naming as discussed in the links posted below. A search on github reveals that code using `aarch64-unknown-none` is almost exclusively forked from our embedded WG's OS tutorials repo at https://github.com/rust-embedded/rust-raspi3-OS-tutorials, for which the target was originally created.~~ ~~I will adapt this repo to the new target name asap once this PR would go upstream. The minor annoyance for the forks to break temporarily should be acceptable for the sake of introducing a better differentiation now before it is too late. Also, the break would only happen upon updating the toolchain, giving the user a good hint at what has happened.~~ ---------- Patch commit message: Following up on [1] and [2], this PR adds differntiation for aarch64 bare-metal targets between versions with and without floating point enabled. This streamlines the target naming with other existing ARM targets and provides the user clear indication if he is getting float or non-float for his bare-metal target. [1] https://github.com/rust-lang/rust/pull/60135#issuecomment-485851356 [2] https://github.com/rust-embedded/wg/issues/230 Closes: rust-embedded/wg#230
2019-09-28rustc: rely on c_variadic == true instead of CVarArgs in HIR/Ty fn signatures.Eduard-Mihai Burtescu-12/+4
2019-09-23Differentiate AArch64 bare-metal targets between hf and non-hf.Andre Richter-2/+40
Following up on [1] and [2], this PR adds differntiation for aarch64 bare-metal targets between versions with and without hardware floating point enabled. This streamlines the target naming with other existing ARM targets and provides the user clear indication if he is getting float or non-float for his bare-metal target. [1] https://github.com/rust-lang/rust/pull/60135#issuecomment-485851356 [2] https://github.com/rust-embedded/wg/issues/230 Closes: rust-embedded/wg#230
2019-09-13Auto merge of #64254 - aleksijuvani:fix-macos-sysroot, r=alexcrichtonbors-4/+44
Fix sysroot on macOS when cross-compiling and SDKROOT is set Fixes rust-lang/cargo#7283 Closes rust-lang/cargo#7284 r? @alexcrichton
2019-09-12Ignore linker env vars set for macOS on iOS targetsAleksi Juvani-3/+20
2019-09-12Remove env vars instead of setting them to an empty stringAleksi Juvani-9/+14
2019-09-11Auto merge of #64334 - jyao1:i686-master, r=joshtriplettbors-0/+99
Add i686-unknown-uefi target This adds a new rustc target-configuration called 'i686-unknown_uefi'. This is similar to existing x86_64-unknown_uefi target. The i686-unknown-uefi target can be used to build Intel Architecture 32bit UEFI application. The ABI defined in UEFI environment (aka IA32) is similar to cdecl. We choose i686-unknown-uefi-gnu instead of i686-unknown-uefi to avoid the intrinsics generated by LLVM. The detail of root-cause and solution analysis is added as comment in the code. For x86_64-unknown-uefi, we cannot use -gnu, because the ABI between MSVC and GNU is totally different, and UEFI chooses ABI similar to MSVC. For i686-unknown-uefi, the UEFI chooses cdecl ABI, which is same as MSVC and GNU. According to LLVM code, the only differences between MSVC and GNU are fmodf(f32), longjmp() and TLS, which have no impact to UEFI. As such, using i686-unknown-uefi-gnu is the simplest way to pass the build. Adding the undefined symbols, such as _aulldiv() to rust compiler-builtins is out of scope. But it may be considered later. The scope of this patch is limited to support target-configuration. No standard library support is added in this patch. Such work can be done in future enhancement. Cc: Josh Triplett <josh.triplett@intel.com> Reviewed-by: Josh Triplett <josh.triplett@intel.com>
2019-09-10Set environment variables for linker instead of sysrootAleksi Juvani-81/+64
2019-09-10Add i686-unknown-uefi targetJiewen Yao-0/+99
This adds a new rustc target-configuration called 'i686-unknown_uefi'. This is similar to existing x86_64-unknown_uefi target. The i686-unknown-uefi target can be used to build Intel Architecture 32bit UEFI application. The ABI defined in UEFI environment (aka IA32) is similar to cdecl. We choose i686-unknown-uefi-gnu instead of i686-unknown-uefi to avoid the intrinsics generated by LLVM. The detail of root-cause and solution analysis is added as comment in the code. For x86_64-unknown-uefi, we cannot use -gnu, because the ABI between MSVC and GNU is totally different, and UEFI chooses ABI similar to MSVC. For i686-unknown-uefi, the UEFI chooses cdecl ABI, which is same as MSVC and GNU. According to LLVM code, the only differences between MSVC and GNU are fmodf(f32), longjmp() and TLS, which have no impact to UEFI. As such, using i686-unknown-uefi-gnu is the simplest way to pass the build. Adding the undefined symbols, such as _aulldiv() to rust compiler-builtins is out of scope. But it may be considered later. The scope of this patch is limited to support target-configuration. No standard library support is added in this patch. Such work can be done in future enhancement. Cc: Josh Triplett <josh.triplett@intel.com> Reviewed-by: Josh Triplett <josh.triplett@intel.com>
2019-09-08Fix cross-compilation to macOSAleksi Juvani-50/+62
2019-09-07Fix nitsAleksi Juvani-10/+10
2019-09-07Fix sysroot on macOS when cross-compiling and SDKROOT is setAleksi Juvani-44/+67
Fixes rust-lang/cargo#7283 Closes rust-lang/cargo#7284 r? @alexcrichton
2019-09-05rustc: Allow the cdylib crate type with wasm32-wasiAlex Crichton-0/+4
The wasm32-wasi target respects configuration around `crt-static` in general, but is defaulted to being static. This interacted badly with code which validated the `cdylib` crate type for `wasm32-wasi`, erroneously saying that the `cdylib` crate type wasn't supported on `wasm32-wasi` by default. This commit sets the appropriate flag in `wasm32_wasi`'s target specification to indicate that the `cdylib` crate type is supported regardless of `crt-static` Closes #64187
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-13 18:21:47 +0000