about summary refs log tree commit diff
path: root/compiler/rustc_target/src
AgeCommit message (Collapse)AuthorLines
2020-11-21Replace ByVal attribute with on_stack field for Indirectbjorn3-12/+19
This makes it clearer that only PassMode::Indirect allows ByVal
2020-11-21Replace ZExt and SExt flags with ArgExtension enumbjorn3-7/+33
Both flags are mutually exclusive
2020-11-15Rollup merge of #78993 - petrochenkov:specdash, r=oli-obkDylan DPC-8/+8
rustc_target: Fix dash vs underscore mismatches in option names Fixes https://github.com/rust-lang/rust/issues/78981 (regression from https://github.com/rust-lang/rust/pull/78875, the old option names used dashes)
2020-11-14Auto merge of #78959 - petrochenkov:likeuefi, r=nagisabors-12/+18
rustc_target: Mark UEFI targets as `is_like_windows`/`is_like_msvc` And document what `is_like_windows` and `is_like_msvc` actually mean in more detail. Addresses FIXMEs left from https://github.com/rust-lang/rust/pull/71030. r? `@nagisa`
2020-11-14Auto merge of #78951 - petrochenkov:unknown, r=ehussbors-20/+19
rustc_target: Change os and vendor values to "none" and "unknown" for some targets Closes https://github.com/rust-lang/rust/issues/77730 r? `@ehuss`
2020-11-12Rollup merge of #78950 - khyperia:spirv-asm, r=AmanieuMara Bos-0/+67
Add asm register information for SPIR-V As discussed in [zulip](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Defining.20asm!.20for.20new.20architecture), we at [rust-gpu](https://github.com/EmbarkStudios/rust-gpu) would like to support `asm!` for our SPIR-V backend. However, we cannot do so purely without frontend support: [this match](https://github.com/rust-lang/rust/blob/d4ea0b3e46a0303d5802b632e88ba1ba84d9d16f/compiler/rustc_target/src/asm/mod.rs#L185) fails and so `asm!` is not supported ([error reported here](https://github.com/rust-lang/rust/blob/d4ea0b3e46a0303d5802b632e88ba1ba84d9d16f/compiler/rustc_ast_lowering/src/expr.rs#L1095)). To resolve this, we need to stub out register information for SPIR-V to support getting the `asm!` content all the way to [`AsmBuilderMethods::codegen_inline_asm`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/traits/trait.AsmBuilderMethods.html#tymethod.codegen_inline_asm), at which point the rust-gpu backend can do all the parsing and codegen that is needed. This is a pretty weird PR - adding support for a backend that isn't in-tree feels pretty gross to me, but I don't see an easy way around this. ``@Amanieu`` said I should submit it anyway, so, here we are! Let me know if this needs to go through a more formal process (MCP?) and what I should do to help this along. I based this off the [wasm asm PR](https://github.com/rust-lang/rust/pull/78684), which unfortunately this PR conflicts with that one quite a bit, sorry for any merge conflict pain :( --- Some open questions: - What do we call the register class? Some context, SPIR-V is an SSA-based IR, there are "instructions" that create IDs (referred to as `<id>` in the spec), which can be referenced by other instructions. So, `reg` isn't exactly accurate, they're SSA IDs, not re-assignable registers. - What happens when a SPIR-V register gets to the LLVM backend? Right now it's a `bug!`, but should that be a `sess.fatal()`? I'm not sure if it's even possible to reach that point, maybe there's a check that prevents the `spirv` target from even reaching that codepath.
2020-11-12rustc_target: Mark UEFI targets as `is_like_windows`/`is_like_msvc`Vadim Petrochenkov-12/+18
Document what `is_like_windows` and `is_like_msvc` mean in more detail.
2020-11-12rustc_target: Fix dash vs underscore mismatches in option namesVadim Petrochenkov-8/+8
2020-11-11Rollup merge of #78930 - petrochenkov:notlikeandroid, r=Mark-SimulacrumJonas Schievink-7/+0
rustc_taret: Remove `TargetOptions::is_like_android` This option was replaced by more specific options and is no longer used by the compiler.
2020-11-11Change capitalization of Spirv to SpirVkhyperia-18/+18
This matches the capitalization of RiscV
2020-11-11rustc_target: Make sure that in-tree targets follow conventions for os and ↵Vadim Petrochenkov-0/+13
vendor values
2020-11-11rustc_target: Normalize vendor from "" to "unknown" for all targetsVadim Petrochenkov-19/+3
Majority of targets use "unknown" vendor and changing it from "unknown" to omitted doesn't make sense. From the LLVM docs (https://clang.llvm.org/docs/CrossCompilation.html#target-triple): >Most of the time it can be omitted (and Unknown) will be assumed, which sets the defaults for the specified architecture. >When a parameter is not important, it can be omitted, or you can choose unknown and the defaults will be used. If you choose a parameter that Clang doesn’t know, like blerg, it’ll ignore and assume unknown
2020-11-11rustc_target: Change os from "unknown" to "none" for bare metal targetsVadim Petrochenkov-1/+3
x86_64-fortanix-unknown-sgx and wasm32-unknown-unknown still have os == "unknown" because both have libstd
2020-11-11Add asm register information for SPIR-Vkhyperia-0/+67
2020-11-11rustc_target: Move target env "gnu" from `linux_base` to `linux_gnu_base`Vadim Petrochenkov-30/+35
2020-11-10rustc_taret: Remove `TargetOptions::is_like_android`Vadim Petrochenkov-7/+0
2020-11-10Rollup merge of #78875 - petrochenkov:cleantarg, r=Mark-SimulacrumJonas Schievink-279/+260
rustc_target: Further cleanup use of target options Follow up to https://github.com/rust-lang/rust/pull/77729. Implements items 2 and 4 from the list in https://github.com/rust-lang/rust/pull/77729#issue-500228243. The first commit collapses uses of `target.options.foo` into `target.foo`. The second commit renames some target options to avoid tautology: `target.target_endian` -> `target.endian` `target.target_c_int_width` -> `target.c_int_width` `target.target_os` -> `target.os` `target.target_env` -> `target.env` `target.target_vendor` -> `target.vendor` `target.target_family` -> `target.os_family` `target.target_mcount` -> `target.mcount` r? `@Mark-Simulacrum`
2020-11-09Add `#[cfg(panic = "...")]`David Hewitt-0/+8
2020-11-08Address review commentsVadim Petrochenkov-1/+1
2020-11-08rustc_target: Rename some target options to avoid tautologyVadim Petrochenkov-219/+195
`target.target_endian` -> `target.endian` `target.target_c_int_width` -> `target.c_int_width` `target.target_os` -> `target.os` `target.target_env` -> `target.env` `target.target_vendor` -> `target.vendor` `target.target_family` -> `target.os_family` `target.target_mcount` -> `target.mcount`
2020-11-08Collapse all uses of `target.options.foo` into `target.foo`Vadim Petrochenkov-59/+64
with an eye on merging `TargetOptions` into `Target`. `TargetOptions` as a separate structure is mostly an implementation detail of `Target` construction, all its fields logically belong to `Target` and available from `Target` through `Deref` impls.
2020-11-07Update recently added targetsVadim Petrochenkov-6/+2
2020-11-07rustc_target: Move `linker_flavor` from `Target` to `TargetOptions`Vadim Petrochenkov-244/+120
2020-11-07rustc_target: Move `target_vendor` from `Target` to `TargetOptions`Vadim Petrochenkov-163/+28
2020-11-07rustc_target: Move `target_env` from `Target` to `TargetOptions`Vadim Petrochenkov-158/+27
2020-11-07rustc_target: Move `target_os` from `Target` to `TargetOptions`Vadim Petrochenkov-169/+52
2020-11-07rustc_target: Move `target_endian` from `Target` to `TargetOptions`Vadim Petrochenkov-168/+75
2020-11-07rustc_target: Move `target_c_int_width` from `Target` to `TargetOptions`Vadim Petrochenkov-155/+20
2020-11-05Fix automatic_links warningsGuillaume Gomez-4/+4
2020-11-04Update compiler/rustc_target/src/abi/mod.rsOli Scherer-1/+1
Co-authored-by: Ralf Jung <post@ralfj.de>
2020-11-04Update compiler/rustc_target/src/abi/mod.rsOli Scherer-1/+1
Co-authored-by: Ralf Jung <post@ralfj.de>
2020-11-04`u128` truncation and sign extension are not just interpreter relatedoli-0/+29
2020-11-02indicate calling conventionStephan-1/+1
2020-11-02improve commentsStephan-2/+3
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
2020-11-02add blacklist for unsupported calling conventionsStephan-0/+9
2020-11-02add mipsel_unknown_none targetStephan-0/+33
2020-10-30Fix even more clippy warningsJoshua Nelson-48/+15
2020-10-24Rollup merge of #77716 - francesca64:revert-ios-dynamic-linking, ↵Jonas Schievink-0/+1
r=jonas-schievink Revert "Allow dynamic linking for iOS/tvOS targets." This reverts PR #73516. On macOS I compile static libs for iOS, automated using [cargo-mobile](https://github.com/BrainiumLLC/cargo-mobile), which has worked smoothly for the past 2 years. However, upon updating to Rust 1.46.0, I was no longer able to use Rust on iOS. I've bisected this to the PR referenced above. For most projects tested, apps now immediately crash with a message like this: ``` dyld: Library not loaded: /Users/francesca/Projects/example/target/aarch64-apple-ios/debug/deps/libexample.dylib Referenced from: /private/var/containers/Bundle/Application/745912AF-A928-465C-B340-872BD1C9F368/example.app/example Reason: image not found dyld: launch, loading dependent libraries DYLD_LIBRARY_PATH=/usr/lib/system/introspection DYLD_INSERT_LIBRARIES=/Developer/usr/lib/libBacktraceRecording.dylib:/Developer/usr/lib/libMainThreadChecker.dylib:/Developer/Library/PrivateFrameworks/DTDDISupport.framework/libViewDebuggerSupport.dylib:/Developer/Library/PrivateFrameworks/GPUTools.framework/libglInterpose.dylib:/usr/lib/libMTLCapture.dylib ``` This can be reproduced by using cargo-mobile to generate a winit example project, and then attempting to run it on an iOS device (`cargo mobile init && cargo apple open`). In our projects that depend on DisplayLink, the build instead fails with a linker error: ``` = note: Undefined symbols for architecture arm64: "_CACurrentMediaTime", referenced from: display_link::ios::run_callback_ios10::hda81197ff46aedbd in libapp-4f0abc1d7684103f.rlib(app-4f0abc1d7684103f.40d4iro0yz1iy487.rcgu.o) display_link::ios::run_callback_pre_ios10::h91f085da19374320 in libapp-4f0abc1d7684103f.rlib(app-4f0abc1d7684103f.40d4iro0yz1iy487.rcgu.o) ld: symbol(s) not found for architecture arm64 ``` After reverting the change to enable dynamic linking on iOS, everything works the same as it did on Rust 1.45.2 for me. In the future, would it be possible for me to be pinged when iOS-related PRs are made? I work for a company that intends on using Rust on iOS in production, so I'd gladly provide testing. cc @aspenluxxxy
2020-10-15Replace target.target with target and target.ptr_width with target.pointer_widthest31-4/+1
Preparation for a subsequent change that replaces rustc_target::config::Config with its wrapped Target. On its own, this commit breaks the build. I don't like making build-breaking commits, but in this instance I believe that it makes review easier, as the "real" changes of this PR can be seen much more easily. Result of running: find compiler/ -type f -exec sed -i -e 's/target\.target\([)\.,; ]\)/target\1/g' {} \; find compiler/ -type f -exec sed -i -e 's/target\.target$/target/g' {} \; find compiler/ -type f -exec sed -i -e 's/target.ptr_width/target.pointer_width/g' {} \; ./x.py fmt
2020-10-15Rename target_pointer_width to pointer_width and turn it into an u32est31-7/+12
Rename target_pointer_width to pointer_width because it is already member of the Target struct. The compiler supports only three valid values for target_pointer_width: 16, 32, 64. Thus it can safely be turned into an int. This means less allocations and clones as well as easier handling of the type.
2020-10-15Use integer literals for builtin target_pointer_width fieldsest31-151/+151
Also change target_pointer_width to pointer_width. Preparation for a subsequent type change of target_pointer_width to an integer together with a rename to pointer_width. On its own, this commit breaks the build. I don't like making build-breaking commits, but in this instance I believe that it makes review easier, as the "real" changes of this PR can be seen much more easily. Result of running: find compiler/rustc_target/src/spec/ -type f -exec sed -i -e 's/target_pointer_width: "\(.*\)"\..*,/pointer_width: \1,/g' {} \;
2020-10-14Rollup merge of #77765 - amshafer:master, r=petrochenkovDylan DPC-0/+21
Add LLVM flags to limit DWARF version to 2 on BSD This has been a thorn in my side for a while, I can finally generate flamegraphs of rust programs on bsd again. This fixes dtrace profiling on freebsd, I think it might help with lldb as well but I can't test that because my current rust-lldb setup is messed up. I'm limiting the dwarf version to 2 on all bsd's (netbsd/openbsd/freebsd) since it looks like this applies to all of them, but I have only tested on freebsd. Let me know if there's anything I can improve! --- Currently on FreeBSD dtrace profiling does not work and shows jumbled/incorrect symbols in the backtraces. FreeBSD does not support the latest versions of DWARF in dtrace (and lldb?) yet, and needs to be limited to DWARF2 in the same way as macos. This adds an is_like_bsd flag since it was missing. NetBSD/OpenBSD/FreeBSD all match this. This effectively copies #11864 but targets FreeBSD instead of macos.
2020-10-13Add a target option for selecting a DWARF versionAustin Shafer-0/+21
Certain platforms need to limit the DWARF version emitted (oxs, *bsd). This change adds a dwarf_version entry to the options that allows a platform to specify the dwarf version to use. By default this option is none and the default DWARF version is selected. Also adds an option for printing Option<u32> json keys
2020-10-13Auto merge of #75406 - mati865:mingw-aslr, r=Mark-Simulacrumbors-2/+12
Enable ASLR for windows-gnu Fixes https://github.com/rust-lang/rust/issues/16514 Fixes https://github.com/rust-lang/rust/issues/16593 Fixes https://github.com/rust-lang/rust/issues/17684 Passes the tests for me with x86_64 toolchain.
2020-10-10Auto merge of #77337 - lzutao:asm-mips64, r=Amanieubors-39/+44
Add asm! support for mips64 - [x] Updated `src/doc/unstable-book/src/library-features/asm.md`. - [ ] No vector type support. I don't know much about those types. cc #76839
2020-10-10Auto merge of #77580 - petrochenkov:norestarg, r=matthewjasperbors-667/+631
rustc_target: Refactor away `TargetResult` Follow-up to https://github.com/rust-lang/rust/pull/77202. Construction of a built-in target is always infallible now, so `TargetResult` is no longer necessary. The second commit contains some further cleanup based on built-in target construction being infallible.
2020-10-08Implement the instruction_set attributexd009642-0/+11
2020-10-07Revert "Allow dynamic linking for iOS/tvOS targets."Francesca Lovebloom-0/+1
This reverts commit 56e115a2627ba8bdd2e66c759457af96b2b0286a.
2020-10-05rustc_target: Further simplify loading of built-in targetsVadim Petrochenkov-38/+13
using the fact that it is infallible. JSON roundtrip check on every rustc run is also removed, it's already performed by unit tests.
2020-10-05rustc_target: Refactor away `TargetResult`Vadim Petrochenkov-630/+619
Construction of a built-in target is always infallible now, so `TargetResult` is no longer necessary.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-03-01 07:43:27 +0000