about summary refs log tree commit diff
path: root/src/librustc_target/spec
AgeCommit message (Collapse)AuthorLines
2019-07-29Rollup merge of #62809 - alexcrichton:wasm-llvm-9, r=nikicMazdak Farrokhzad-0/+8
rustc: Update wasm32 support for LLVM 9 This commit brings in a number of minor updates for rustc's support for the wasm target which has changed in the LLVM 9 update. Notable updates include: * The compiler now no longer manually inserts the `producers` section, instead relying on LLVM to do so. LLVM uses the `llvm.ident` metadata for the `processed-by` directive (which is now emitted on the wasm target in this PR) and it uses debuginfo to figure out what `language` to put in the `producers` section. * Threaded WebAssembly code now requires different flags to be passed with LLD. In LLD we now pass: * `--shared-memory` - required since objects are compiled with atomics. This also means that the generated memory will be marked as `shared`. * `--max-memory=1GB` - required with the `--shared-memory` argument since shared memories in WebAssembly must have a maximum size. The 1GB number is intended to be a conservative estimate for rustc, but it should be overridable with `-C link-arg` if necessary. * `--passive-segments` - this has become the default for multithreaded memory, but when compiling a threaded module all data segments need to be marked as passive to ensure they don't re-initialize memory for each thread. This will also cause LLD to emit a synthetic function to initialize memory which users will have to arrange to call. * The `__heap_base` and `__data_end` globals are explicitly exported since they're now hidden by default due to the `--export` flags we pass to LLD.
2019-07-26Rollup merge of #62904 - nikic:arm-d32, r=alexcrichtonMazdak Farrokhzad-4/+4
Disable d32 on armv6 hf targets We already do this on armv7 targets. It seems that this now gets enabled by default if '+vfp2` is specified, so disable it explicitly. Hopefully fixes #62841. r? @alexcrichton
2019-07-26Rollup merge of #62801 - bjorn3:remove_lower_128bit_ops, r=alexcrichtonMazdak Farrokhzad-5/+0
Remove support for -Zlower-128bit-ops It is broken and unused cc https://github.com/rust-lang/rust/issues/58969 blocked https://github.com/rust-lang-nursery/compiler-builtins/pull/302 (removes definitions of the lang items removed in this PR) r? @alexcrichton
2019-07-25Add UWP mingw targetsHugo Beauzée-Luyssen-0/+116
2019-07-25std: Use native `#[thread_local]` TLS on wasmAlex Crichton-0/+8
This commit moves `thread_local!` on WebAssembly targets to using the `#[thread_local]` attribute in LLVM. This was recently implemented upstream and is [in the process of being documented][dox]. This change only takes affect if modules are compiled with `+atomics` which is currently unstable and a pretty esoteric method of compiling wasm artifacts. This "new power" of the wasm toolchain means that the old `wasm-bindgen-threads` feature of the standard library can be removed since it should now be possible to create a fully functioning threaded wasm module without intrusively dealing with libstd symbols or intrinsics. Yay! [dox]: https://github.com/WebAssembly/tool-conventions/pull/116
2019-07-25Rollup merge of #62903 - swolchok:ios-sdkroot, r=alexcrichtonMazdak Farrokhzad-0/+14
Support SDKROOT env var on iOS Following what clang does (https://github.com/llvm/llvm-project/blob/296a80102a9b72c3eda80558fb78a3ed8849b341/clang/lib/Driver/ToolChains/Darwin.cpp#L1661-L1678), allow allow SDKROOT to tell us where the Apple SDK lives so we don't have to invoke xcrun. Replaces #62551.
2019-07-25Rollup merge of #62901 - petrochenkov:serde, r=CentrilMazdak Farrokhzad-3/+3
cleanup: Remove `extern crate serialize as rustc_serialize`s
2019-07-25Rollup merge of #62814 - androm3da:hexagon_19jul_2019, r=alexcrichtonMazdak Farrokhzad-0/+37
add support for hexagon-unknown-linux-musl
2019-07-25Rollup merge of #62784 - Disasm:riscv32i, r=estebankMazdak Farrokhzad-0/+33
Add riscv32i-unknown-none-elf target This target is likely to be useful for constrained FPGA soft-cores, such as picorv32 and HeavyX.
2019-07-24Add commentScott Wolchok-0/+6
2019-07-24Auto merge of #62908 - ↵bors-1/+1
fakenine:normalize_use_of_backticks_compiler_messages_p17, r=alexreg normalize use of backticks for compiler messages in remaining modules https://github.com/rust-lang/rust/issues/60532
2019-07-23normalize use of backticks for compiler messages in remaining modulesSamy Kacimi-1/+1
https://github.com/rust-lang/rust/issues/60532
2019-07-23fix checkScott Wolchok-1/+2
2019-07-23Disable d32 on armv6 hf targetsNikita Popov-4/+4
2019-07-23cleanup: Remove `extern crate serialize as rustc_serialize`sVadim Petrochenkov-3/+3
2019-07-22add support for hexagon-unknown-linux-muslBrian Cain-0/+37
2019-07-20Revert "Disable stack probing for gnux32."CrLF0710-2/+1
This reverts commit 42d652ecd6709b756d95fc42615b166aacd2ea07.
2019-07-19Remove support for -Zlower-128bit-opsbjorn3-5/+0
It is broken and unused
2019-07-18Add riscv32i-unknown-none-elf targetVadim Kaushan-0/+33
2019-07-17update data_layout and featuresBaoshan Pang-6/+4
2019-07-16Support SDKROOT env var on iOSScott Wolchok-0/+7
Following what clang does (https://github.com/llvm/llvm-project/blob/296a80102a9b72c3eda80558fb78a3ed8849b341/clang/lib/Driver/ToolChains/Darwin.cpp#L1661-L1678), allow allow SDKROOT to tell us where the Apple SDK lives so we don't have to invoke xcrun.
2019-07-16Auto merge of #61946 - BaoshanPang:vxworks, r=alexcrichtonbors-1/+398
port rust for vxWorks The supporting for vxWorks has been enabled in this branch. Although there are still a lots of work to do, I would like to upstream the code and fix the problems later. Please let me know if there is anything I have to do before upstream the code. r? @alexcrichton Thanks, Baoshan
2019-07-16Add supporting for vxWorksBaoshan Pang-1/+398
r? @alexcrichton
2019-07-15SGX target: don't pretend to be GNU/Linux to LLVMJethro Beekman-1/+1
2019-07-10Rollup merge of #62474 - nikic:update-llvm, r=alexcrichtonMazdak Farrokhzad-44/+44
Prepare for LLVM 9 update Main changes: * In preparation for opaque pointer types, the `byval` attribute now takes a type. As such, the argument type needs to be threaded through to the function/callsite attribute application logic. * On ARM the `+fp-only-sp` and `+d16` features have become `-fp64` and `-d32`. I've switched the target definitions to use the new names, but also added bidirectional emulation so either can be used on any LLVM version for backwards compatibility. * The datalayout can now specify function pointer alignment. In particular on ARM `Fi8` is specified, which means that function pointer alignment is independent of function alignment. I've added this to our datalayouts to match LLVM (which is something we check) and strip the fnptr alignment for older LLVM versions. * The fmul/fadd reductions now always respect the accumulator (including for unordered reductions), so we should pass the identity instead of undef. Open issues: * https://reviews.llvm.org/D62106 causes linker errors with ld.bdf due to https://sourceware.org/bugzilla/show_bug.cgi?id=24784. To avoid this I've enabled `RelaxELFRelocations`, which results in a GOTPCRELX relocation for `__tls_get_addr` and avoids the issue. However, this is likely not acceptable because relax relocations are not supported by older linker versions. We may need an LLVM option to keep using PLT for `__tls_get_addr` despite `RtLibUseGOT`. The corresponding llvm-project PR is https://github.com/rust-lang/llvm-project/pull/19. r? @ghost
2019-07-10Rollup merge of #62283 - fintelia:patch-5, r=Mark-SimulacrumMazdak Farrokhzad-2/+2
Target::arch can take more than listed options A list of options in a comment like this is almost guaranteed to become out of date: right now it is missing "riscv32" and "riscv64" and perhaps other architectures as well.
2019-07-09Add function pointer alignment to ARM/Thumb data layoutNikita Popov-32/+32
2019-07-09Use new feature names in target feature listsNikita Popov-12/+12
2019-07-07Auto merge of #62281 - Disasm:riscv-pic, r=nagisabors-0/+2
Add support for pc-relative addressing on 64-bit RISC-V These changes allow Rust to generate position-independent code on `riscv64` targets with code model `medium`. Closes: https://github.com/rust-lang/rust/issues/59802 See also: https://github.com/rust-embedded/riscv-rt/issues/25, https://github.com/rust-embedded/wg/issues/218
2019-07-03Rollup merge of #62021 - crlf0710:msvc_link_output_improve, r=alexcrichtonMark Rousskov-0/+4
MSVC link output improve Resolves #35785. However i haven't come up with a idea to add test case for this :( r? @retep998
2019-07-01Target::arch can take more than listed optionsJonathan Behrens-2/+2
A list of options in a comment like this is almost guaranteed to become out of date. This list is missing "riscv32" and "riscv64" and perhaps other architectures as well.
2019-07-01Use code model 'medium' for 64-bit RISC-V targetsVadim Kaushan-0/+2
2019-06-27Added comment description.CrLF0710-0/+3
2019-06-26Fix clippy::redundant_field_namesIgor Matuszewski-1/+1
2019-06-24Just switch to English linker output using environment variable when using msvc.CrLF0710-0/+1
2019-06-23Fix meta-variable binding errors in macrosJulien Cretin-3/+3
The errors are either: - The meta-variable used in the right-hand side is not bound (or defined) in the left-hand side. - The meta-variable used in the right-hand side does not repeat with the same kleene operator as its binder in the left-hand side. Either it does not repeat enough, or it uses a different operator somewhere. This change should have no semantic impact.
2019-06-15Auto merge of #59752 - Zoxc:dylib-fix, r=alexcrichtonbors-0/+14
Limit dylib symbols This makes `windows-gnu` match the behavior of `windows-msvc`. It probably doesn't make sense to export these symbols on other platforms either.
2019-06-13Rollup merge of #61761 - lzutao:target-tuple-solaris, r=varkorMazdak Farrokhzad-8/+10
Add an alias for x86_64-sun-solaris target tuple Closes #40531 r? @varkor
2019-06-12Add a limit_rdylib_exports option and disable it for SolarisJohn Kåre Alsaker-0/+14
2019-06-12Add an alias for x86_64-sun-solaris target tupleLzu Tao-8/+10
2019-06-08Include frame pointer for bare metal RISC-V targetsJonathan Behrens-0/+4
2019-06-05Don't use GNU noexec stack notecoypoop-3/+0
NetBSD ignores this note and marks the stack no-exec unconditionally
2019-05-15Auto merge of #60775 - hellow554:no_bitrig, r=joshtriplettbors-42/+0
Remove bitrig support from rust Resolves #60743 using `find` and `rg` I delete every occurence of "bitrig" in the sources, expect for the llvm submodule (is this correct?). There's also this file https://github.com/rust-lang/rls/blob/5b8e99bb61958ca8abcb7c5eda70521726be1065/rls-analysis/test_data/rust-analysis/libstd-af9bacceee784405.json which contains a bitrig string in it. What to do with that?
2019-05-13default to $ARCH-apple-macosx10.7.0 LLVM triple for darwin targetsNathan Froyd-12/+5
Over in #60378, we made `rustc` switch LLVM target triples dynamically based on the `MACOSX_DEPLOYMENT_TARGET` environment variable. This change was made to align with `clang`'s behavior, and therefore make cross-language LTO feasible on OS X. Otherwise, `rustc` would produce LLVM bitcode files with a target triple of `x86_64-apple-darwin`, `clang` would produce LLVM bitcode files with a target triple of `x86_64-apple-macosx$VERSION`, and the linker would complain. This change worked fine, except for one corner case: if you didn't have `MACOSX_DEPLOYMENT_TARGET` set, and you wanted to do LTO on just Rust code, you'd get warning messages similar to: ``` warning: Linking two modules of different target triples: ' is 'x86_64-apple-macosx10.7.0' whereas 'main.7rcbfp3g-cgu.4' is 'x86_64-apple-darwin' ``` This message occurs because libstd is compiled with `MACOSX_DEPLOYMENT_TARGET` set to 10.7. The LLVM bitcode distributed in libstd's rlibs, then, is tagged with the target triple of `x86_64-apple-macosx10.7.0`, while the bitcode `rustc` produces for "user" code is tagged with the target triple of `x86_64-apple-darwin`. It's not good to have LTO on just Rust code (probably much more common than cross-language LTO) warn by default. These warnings also break Cargo's testsuite. This change defaults to acting as though `MACOSX_DEPLOYMENT_TARGET` was set to 10.7. "user" code will then be given a target triple that is equivalent to the target triple libstd bitcode is already using. The above warning will therefore go away. `rustc` already assumes that compiling without `MACOSX_DEPLOYMENT_TARGET` means that we're compiling for a target compatible with OS X 10.7 (e.g. that things like TLS work properly). So this change is really just making things conform more closely to the status quo. (It's also worth noting that before and after this patch, compiling with `MACOSX_DEPLOYMENT_TARGET` set to, say, 10.9, works just fine: target triples with an "apple" version ignore OS versions when checking compatibility, so bitcode with a `x86_64-apple-macosx10.7.0` triple works just fine with bitcode with a `x86_64-apple-macosx10.9.0` triple.)
2019-05-13Remove bitrig support from rustMarcel Hellwig-42/+0
2019-05-09Omit the vendor component in the WASI tripleDan Gohman-18/+18
This renames wasm32-unknown-wasi to wasm32-wasi, omitting the vendor component. This follows aarch64-linux-android, x86_64-fuchsia, and others in omitting the vendor field, which has the advantage of aligning with the [multiarch tuple](https://wiki.debian.org/Multiarch/Tuples), and of being less noisy.
2019-05-08Auto merge of #60378 - froydnj:apple-target-modifications, r=michaelwoeristerbors-10/+40
conditionally modify darwin targets to macosx targets with versions We need this behavior so that Rust LLVM IR objects match the target triple for Clang LLVM IR objects. This matching then convinces the linker that yes, you really can do cross-language LTO with objects from different compilers. The newly-added tests seem to pass locally on x86_64-unknown-linux-gnu. I haven't done a full test run or tried the new compiler in an cross-language LTO setup yet.
2019-05-07choose a more specific LLVM target on OS X when necessaryNathan Froyd-10/+40
This behavior matches clang's behavior, and makes cross-language LTO possible. Fixes #60235.
2019-05-03Categorize WASI as an "OS" rather than as an "environment".Dan Gohman-2/+2
This distinction is fairly abstract, but in practice, the main advantage here is that LLVM's triple code considers WASI to be an OS, so this makes rustc agree with that.
2019-04-06Rollup merge of #59624 - jethrogb:jb/sgx-unwind-syms, r=alexcrichtonMazdak Farrokhzad-0/+9
SGX target: Use linker option to avoid code CGU assignment kludge cc @VardhanThigle @faern
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-13 02:52:38 +0000