Commit Graph

675 Commits

Author SHA1 Message Date
Yuki Okushi
33eb3c05c5
Rollup merge of #98214 - petrochenkov:islike, r=compiler-errors
rustc_target: Remove some redundant target properties

`is_like_emscripten` is equivalent to `os == "emscripten"`, so it's removed.
`is_like_fuchsia` is equivalent to `os == "fuchsia"`, so it's removed.
`is_like_osx` also falls into the same category and is equivalent to `vendor == "apple"`, but it's commonly used so I kept it as is for now.

`is_like_(solaris,windows,wasm)` are combinations of different operating systems or architectures (see compiler/rustc_target/src/spec/tests/tests_impl.rs) so they are also kept as is.

I think `is_like_wasm` (and maybe `is_like_osx`) are sufficiently closed sets, so we can remove these fields as well and replace them with methods like `fn is_like_wasm() { arch == "wasm32" || arch == "wasm64" }`.
On other hand, `is_like_solaris` and `is_like_windows` are sufficiently open and I can imagine custom targets introducing other values for `os`.
This is kind of a gray area.
2022-06-24 16:43:45 +09:00
Hood Chatham
b96ae9b204 Set no_default_libraries: false in wasm32_emscripten target 2022-06-22 17:43:10 -07:00
Yuki Okushi
bfa6cd9c68
Rollup merge of #98225 - bjorn3:stable_target_json_hash, r=nagisa
Make debug_triple depend on target json file content rather than file path

This ensures that changes to target json files will force a recompilation. And more importantly that moving the files doesn't force a recompilation.

This should fix https://github.com/Rust-for-Linux/linux/issues/792 (cc ``@ojeda)``
2022-06-20 07:37:42 +09:00
bjorn3
b4b536d34d Preserve the path of the target spec json file for usage by rustdoc 2022-06-19 15:33:09 +00:00
Hood Chatham
3fb6d45af9 ENH Move --memory-init-file flag from EmLinker to asmjs target spec 2022-06-18 17:48:00 -07:00
bjorn3
072b7db561 Make debug_triple depend on target json file content rather than file path
This ensures that changes to target json files will force a
recompilation. And more importantly that moving the files doesn't force
a recompilation.
2022-06-18 10:19:24 +00:00
Vadim Petrochenkov
37fd2941a1 rustc_target: Remove some redundant target properties 2022-06-18 01:09:20 +03:00
Mark Drobnak
5d5039e1b8
Disable has_thread_local due to weird issues in some programs
For example, in the following issue the `thread_info` thread-local is
not correctly initialized in debug builds:
https://github.com/Meziu/ctru-rs/issues/60
2022-06-13 20:45:25 -07:00
Vladimir Michael Eatwell
dc5c61028a Add Apple WatchOS compile targets 2022-06-13 16:08:53 +01:00
Matthias Krüger
35ba4dc031
Rollup merge of #97928 - hoodmane:emscripten-no-assertions, r=tlively
Removes debug settings from wasm32_unknown_emscripten default link args

This is a debug setting. We should only make debug builds if user requests
a debug build. Currently this is inserted in release builds.

Furthermore, it would be better to insert these settings in --pre-link-args
because then it would be possible to override them if appropriate. Because
these are inserted at the end, it is necessary to patch emscripten to remove
them.

``@sbc100``
2022-06-10 22:32:30 +02:00
Hood Chatham
b32238ae6f Clean up 2022-06-09 14:07:08 -07:00
Hood Chatham
9f305d3fa5 Remove ERROR_ON_UNDEFINED_SYMBOLS according to sbc100's comments 2022-06-09 13:37:38 -07:00
Hood Chatham
db14d81098 Remove -sASSERTIONS=1 from wasm32_unknown_emscripten default link args
This is a debug setting. We should only make debug builds if user requests
a debug build. Currently this is inserted in release builds.

Furthermore, it would be better to insert these settings in --pre-link-args
because then it would be possible to override them if appropriate. Because
these are inserted at the end, it is necessary to patch emscripten to remove
them.
2022-06-09 12:54:17 -07:00
Yuki Okushi
5d81f91a3b
Rollup merge of #97843 - overdrivenpotato:psp-lto, r=michaelwoerister
Relax mipsel-sony-psp's linker script

Previously, the linker script forcefully kept all `.lib.stub` sections, unnecessarily bloating the binary. Now, the script is LTO and `--gc-sections` friendly.

`--nmagic` was also added to the linker, because page alignment is not required on the PSP. This further reduces binary size.

Accompanying changes for the `psp` crate are found in: https://github.com/overdrivenpotato/rust-psp/pull/118
2022-06-09 19:19:56 +09:00
Marko Mijalkovic
611107af5f Formatting fix 2022-06-07 16:02:11 -04:00
Marko Mijalkovic
94134695b5 Relax mipsel-sony-psp's linker script
Previously, the linker script forcefully kept all `.lib.stub` sections,
unnecessarily bloating the binary. Now, the script is LTO and
`--gc-sections` friendly.

`--nmagic` was also added to the linker, because page alignment is not
required on the PSP. This further reduces binary size.

Accompanying changes for the PSP crate are found in:
https://github.com/overdrivenpotato/rust-psp/pull/118
2022-06-07 10:24:09 -04:00
bors
91cacb3faf Auto merge of #97512 - scottmcm:add-coldcc, r=nagisa,lcnr
Add support for emitting functions with `coldcc` to LLVM

The eventual goal is to try using this for things like the internal panicking stuff, to see whether it helps.
2022-06-07 08:12:45 +00:00
bors
bb55bd449e Auto merge of #95565 - jackh726:remove-borrowck-mode, r=nikomatsakis
Remove migrate borrowck mode

Closes #58781
Closes #43234

# Stabilization proposal

This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors, then MIR borrowck (NLL) never occurs. If there *aren't* any errors, then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program, this should not break any programs. It does, however, change diagnostics significantly and allows a slightly larger set of programs to compile.

Tracking issue: #43234
RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md
Version: 1.63 (2022-06-30 => beta, 2022-08-11 => stable).

## Motivation

Over time, the Rust borrow checker has become "smarter" and thus allowed more programs to compile. There have been three different implementations: AST borrowck, MIR borrowck, and polonius (well, in progress). Additionally, there is the "lexical region resolver", which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker, but does emit some errors.

The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017, work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017, for the most part. During 2018, efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into "migrate" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition.

In early 2019, migrate mode was turned on by default in the 2015 edition as well, but with MIR borrowck errors emitted as warnings. By late 2019, these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker.

In the period since, various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver.

While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics), those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff.

## What is stabilized

As said previously, this does not fundamentally change the landscape of accepted programs. However, there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)`, but not otherwise.

There are two notable patterns that are "fixed" by this stabilization. First, the `scoped_threads` feature, which is a continutation of a pre-1.0 API, can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second, actually seen in the standard library. In the `Extend` impl for `HashMap`, there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl.

As mentioned before, there are a large number of diagnostic differences. Most of them are better, but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general "lifetime may not live long enough" error. While this may *seem* bad, the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however, on paper, they end up being roughly the same with roughly the same kinds of solutions.

## What isn't stabilized

This PR does not completely remove the lexical region resolver. In the future, it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck.

## Tests

Many test outputs get updated by this PR. However, there are number of tests specifically geared towards NLL under `src/test/ui/nll`

## History

* On 2017-07-14, [tracking issue opened](https://github.com/rust-lang/rust/issues/43234)
* On 2017-07-20, [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271)
* On 2017-08-29, [RFC opened](https://github.com/rust-lang/rfcs/pull/2094)
* On 2017-11-16, [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825)
* On 2017-12-20, [NLL feature complete](https://github.com/rust-lang/rust/pull/46862)
* On 2018-07-07, [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083)
* On 2018-07-27, [Add migrate mode](https://github.com/rust-lang/rust/pull/52681)
* On 2019-04-22, [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114)
* On 2019-08-26, [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221)
* On 2019-08-27, [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)
2022-06-07 05:04:14 +00:00
bors
9d20fd1098 Auto merge of #97684 - RalfJung:better-provenance-control, r=oli-obk
interpret: better control over whether we read data with provenance

The resolution in https://github.com/rust-lang/unsafe-code-guidelines/issues/286 seems to be that when we load data at integer type, we implicitly strip provenance. So let's implement that in Miri at least for scalar loads. This makes use of the fact that `Scalar` layouts distinguish pointer-sized integers and pointers -- so I was expecting some wild bugs where layouts set this incorrectly, but so far that does not seem to happen.

This does not entirely implement the solution to https://github.com/rust-lang/unsafe-code-guidelines/issues/286; we still do the wrong thing for integers in larger types: we will `copy_op` them and then do validation, and validation will complain about the provenance. To fix that we need mutating validation; validation needs to strip the provenance rather than complaining about it. This is a larger undertaking (but will also help resolve https://github.com/rust-lang/miri/issues/845 since we can reset padding to `Uninit`).

The reason this is useful is that we can now implement `addr` as a `transmute` from a pointer to an integer, and actually get the desired behavior of stripping provenance without exposing it!
2022-06-06 13:28:58 +00:00
Ralf Jung
47d11a8483 interpret: better control over whether we read data with provenance, and implicit provenance stripping where possible 2022-06-05 10:13:34 -04:00
bors
a2da4af33c Auto merge of #97577 - betrusted-io:add-xous-target, r=nagisa
riscv32imac-unknown-xous-elf: add target

This PR starts the process of upstreaming support for our operating system, thanks to a suggestion from `@yaahc` [on Twitter](https://twitter.com/yaahc_/status/1530558574706839567?s=20&t=Mgkn1LEYvGU6FEi5SpZRsA). We have maintained a fork of Rust and have made changes to improve support for our platform since Rust 1.51. Now we would like to upstream these changes.

Xous is a microkernel operating system designed to run on small systems. The kernel contains a wide range of userspace processes that provide common services such as console output, networking, and time access.

The kernel and its services are completely written in Rust using a custom build of libstd. This adds support for this target to upstream Rust so that we can drop support for our out-of-tree `target.json` file.

This first patch adds a Tier 3 target for Xous running on RISC-V. Future patches will add libstd support, but those patches require changes to `dlmalloc` and `compiler_builtins`.

> Tier 3 policy:
>
> A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)

I will be the target maintainer for this target on matters that pertain to the `xous` part of the triple. For matters pertaining to the `riscv32imac` part of the triple, there should be no difference from all other `riscv` targets. If there are issues, I will address issues regarding the target.

> Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.

This is a new OS, so I have taken the `riscv32imac-unknown-none-elf` target and changed the `os` section of the triple. This follows convention on targets such as `riscv32gc-unknown-linux-gnu` and `mipsel-unknown-linux-uclibc`. An argument could be made for omitting the `-elf` section of the triple, such as `riscv32imc-esp-espidf`, however I'm not certain what benefit that has.

> Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it.

I feel that the target name does not introduce any ambiguity.

> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.

The only unusual requirement for building the `compiler-builtins` crate is a standard RISC-V C compiler supported by `cc-rs`, and using this target does not require any additional software beyond what is shipped by `rustup`.

> The target must not introduce license incompatibilities.

All of the additional code will use Apache-2.0.

> Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).

Agreed, and there is no problem here.

> The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements.

The only new dependency will be the `xous` crate, which is licensed `MIT OR Apache-2.0`

> Compiling, linking, and emitting functional binaries, libraries, or other code for the target (whether hosted on the target itself or cross-compiling from another target) must not depend on proprietary (non-FOSS) libraries. Host tools built for the target itself may depend on the ordinary runtime libraries supplied by the platform and commonly used by other applications built for the target, but those libraries must not be required for code generation for the target; cross-compilation to the target must not require such libraries at all. For instance, rustc built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3.

Linking is performed by `rust-lld`

> "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are not limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users.

There are no terms. Xous is completely open. It runs on open hardware. We even provide the source to the CPU.

> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.

This paragraph makes sense, but I don't think it's directed at me.

> This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements.

This paragraph also does not appear to be directed at me.

> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.

So far we have:

 * Thread
 * Mutexex
 * Condvar
 * TcpStream
 * TcpListener
 * UdpSocket
 * DateTime
 * alloc

These will be merged as part of libstd in a future patch once I submit support for Xous in `dlmalloc` and `compiler-builtins`.

> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary.

Testing is currently done on real hardware or in a Renode emulator. I can add documentation on how to do this in a future patch, and I would need instructions on where to add said documentation.

> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.

Alright.

> Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.

Sounds good.

> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.

This shouldn't affect any other targets, so this is understood.

> In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target.

This shouldn't come up right away. `xous` is a new operating system, and most features are keyed off of `target(os = "xous")` rather than a given architecture.
2022-06-05 07:03:50 +00:00
Sean Cross
9f6e6872c2 riscv32imac-unknown-xous-elf: add target
Xous is a microkernel operating system designed to run on small systems.
The kernel contains a wide range of userspace processes that provide
common services such as console output, networking, and time access.

The kernel and its services are completely written in Rust using a
custom build of libstd. This adds support for this target to upstream
Rust so that we can drop support for our out-of-tree `target.json` file.

Add a Tier 3 target for Xous running on RISC-V.

Signed-off-by: Sean Cross <sean@xobs.io>
2022-06-04 18:47:27 +08:00
Jack Huey
410dcc9674 Fully stabilize NLL 2022-06-03 17:16:41 -04:00
bjorn3
fc1df4ff17 Use serde_json for target spec json 2022-06-03 16:46:19 +00:00
bjorn3
fc2abe6952 Remove a couple of unused Encodable and Decodable derives 2022-06-03 16:46:19 +00:00
Scott McMurray
e90be842fb Add support for emitting functions with coldcc in LLVM
The eventual goal is to try using this for things like the internal panicking stuff, to see whether it helps.
2022-05-30 00:19:23 -07:00
Vadim Petrochenkov
2984bf674f Simplify implementation of -Z gcc-ld
- The logic is now unified for all targets (wasm targets should also be supported now)
- Additional "symlink" files like `ld64` are eliminated
- lld-wrapper is used for propagating the correct lld flavor
- Cleanup "unwrap or exit" logic in lld-wrapper
2022-05-25 23:55:22 +03:00
5225225
dd9f31d000 Add flag for stricter checks on uninit/zeroed 2022-05-24 14:26:52 +01:00
Connor Horman
6354bfc152 Add ABI clobbers 2022-05-17 06:48:03 -04:00
Connor Horman
658be0d1cf Add tmm_reg clobbers 2022-05-16 20:15:06 -04:00
Mateusz Mikuła
60361f2ca3 Add LLVM based mingw-w64 targets 2022-05-13 20:14:15 +02:00
Ralf Jung
bd31ba045d make Size and Align debug-printing a bit more compact 2022-05-06 10:57:03 +02:00
Josh Triplett
0fc5c524f5 Stabilize bool::then_some 2022-05-04 13:22:08 +02:00
Alex Crichton
d51702ae84 Update data layout string for wasm64-unknown-unknown
Looks like this changed in a recent LLVM update but wasm64 isn't built
on CI so it wasn't caught until now.

Closes #96463
2022-04-27 07:29:44 -07:00
Guillaume Gomez
223f107b48
Rollup merge of #96415 - ehuss:git-io, r=bjorn3
Remove references to git.io

The git.io service is shutting down soon (see https://github.blog/changelog/2022-04-25-git-io-deprecation/). This removes the references of those short links with the actual destination.
2022-04-26 13:22:31 +02:00
Guillaume Gomez
fe49981ea0
Rollup merge of #94703 - kjetilkjeka:nvptx-kernel-args-abi2, r=nagisa
Fix codegen bug in "ptx-kernel" abi related to arg passing

I found a codegen bug in the nvptx abi related to that args are passed as ptrs ([see comment](https://github.com/rust-lang/rust/issues/38788#issuecomment-1048999928)), this is not as specified in the [ptx-interoperability doc](https://docs.nvidia.com/cuda/ptx-writers-guide-to-interoperability/) or how C/C++ does it. It will also almost always fail in practice since device/host uses different memory spaces for most hardware.

This PR fixes the bug and add tests for passing structs to ptx kernels.

I observed that all nvptx assembly tests had been marked as [ignore a long time ago](https://github.com/rust-lang/rust/pull/59752#issuecomment-501713428). I'm not sure if the new one should be marked as ignore, it passed on my computer but it might fail if ptx-linker is missing on the server? I guess this is outside scope for this PR and should be looked at in a different issue/PR.

I only fixed the nvptx64-nvidia-cuda target and not the potential code paths for the non-existing 32bit target. Even though 32bit nvptx is not a supported target there are still some code under the hood supporting codegen for 32 bit ptx. I was advised to create an MCP to find out if this code should be removed or updated.

Perhaps ``@RDambrosio016`` would have interest in taking a quick look at this.
2022-04-26 13:22:27 +02:00
Eric Huss
159b95d5bb Remove references to git.io 2022-04-25 17:05:58 -07:00
Dylan DPC
93db30aa7f
Rollup merge of #96149 - est31:remove_unused_macro_matchers, r=petrochenkov
Remove unused macro rules

Removes rules of internal macros that weren't triggered.
2022-04-26 01:21:20 +02:00
Dylan DPC
69e45d73b9
Rollup merge of #95740 - Amanieu:kreg0, r=nagisa
asm: Add a kreg0 register class on x86 which includes k0

Previously we only exposed a kreg register class which excludes the k0
register since it can't be used in many instructions. However k0 is a
valid register and we need to have a way of marking it as clobbered for
clobber_abi.

Fixes #94977
2022-04-19 22:57:39 +02:00
Kjetil Kjeka
352abbaade Fix a bug in the ptx-kernel calling convention where structs was passed indirectly
Structs being passed indirectly is suprpising and have a high chance not to work as the device and host usually do not share memory.
2022-04-19 18:03:36 +02:00
Amanieu d'Antras
b2bc46938c asm: Add a kreg0 register class on x86 which includes k0
Previously we only exposed a kreg register class which excludes the k0
register since it can't be used in many instructions. However k0 is a
valid register and we need to have a way of marking it as clobbered for
clobber_abi.

Fixes #94977
2022-04-19 17:14:23 +02:00
est31
3c1e1661e7 Remove unused macro rules 2022-04-18 23:28:06 +02:00
Matthias Krüger
7c2d57e0fa couple of clippy::complexity fixes 2022-04-13 22:51:34 +02:00
Pietro Albini
181d28bb61
trivial cfg(bootstrap) changes 2022-04-05 23:18:40 +02:00
Oli Scherer
d32ce37a17 Mark scalar layout unions so that backends that do not support partially initialized scalars can special case them. 2022-04-05 13:18:21 +00:00
Loïc BRANSTETT
1a1f5b89a4 Cleanup after some refactoring in rustc_target 2022-04-03 21:29:57 +02:00
Loïc BRANSTETT
c16a558f24 Replace LinkArgs with Cow<'static, str> 2022-04-03 21:29:57 +02:00
Loïc BRANSTETT
ce61d4044d Replace every Vec in Target(Options) with it's Cow equivalent 2022-04-03 21:29:57 +02:00
Loïc BRANSTETT
ccff48f97b Replace every String in Target(Options) with Cow<'static, str> 2022-04-03 21:29:57 +02:00
Dylan DPC
46a4754df0
Rollup merge of #95430 - ChrisDenton:disable-tls-i686-msvc, r=nagisa
Disable #[thread_local] support on i686-pc-windows-msvc

Fixes #95429
2022-04-02 03:34:22 +02:00
bors
df20355fa9 Auto merge of #95456 - RalfJung:size, r=oli-obk
allow large Size again

This basically reverts most of https://github.com/rust-lang/rust/pull/80042, and instead does the panic in `bits()` with a `#[cold]` function to make sure it does not get inlined.

https://github.com/rust-lang/rust/pull/80042 added a comment about an invariant ("The top 3 bits are ALWAYS zero") that is not actually enforced, and if it were enforced that would be a problem for https://github.com/rust-lang/rust/pull/95388. So I think we should not have that invariant, and I adjusted the code accordingly.

r? `@oli-obk` Cc `@sivadeilra`
2022-03-31 10:33:56 +00:00
Yuri Astrakhan
8d7b124c1f a few mode feedback fixes per @bjorn3 2022-03-30 17:28:19 -04:00
Yuri Astrakhan
5160f8f843 Spellchecking compiler comments
This PR cleans up the rest of the spelling mistakes in the compiler comments. This PR does not change any literal or code spelling issues.
2022-03-30 15:14:15 -04:00
Ralf Jung
2799885ed0 allow large Size again 2022-03-29 22:25:38 -04:00
Chris Denton
017a092f45
Disable #[thread_local] support on i686-pc-windows-msvc 2022-03-29 12:37:20 +01:00
Dylan DPC
2ab4ad5f26
Rollup merge of #95341 - Meziu:armv6k-3ds-target, r=nagisa
ARMv6K Horizon OS has_thread_local support

cc. ```@ian-h-chamberlain```
cc. ```@AzureMarker```

Being an ARM target, it has always had built-in support for `#[thread_local]`. This PR comes in just now because we were testing `std::thread` support with `thread_local_dtor`s. This will hopefully be the last PR for the target specification, unless anymore features will be needed as time goes on.
2022-03-27 05:36:11 +02:00
Meziu
419b6309a9
Merge pull request #16 from ian-h-chamberlain/feature/target-thread-local
Enable #[thread_local] on armv6k-nintendo-3ds
2022-03-26 20:49:19 +01:00
Ian Chamberlain
78294371c4
Enable #[thread_local] on armv6k-nintendo-3ds 2022-03-26 09:29:01 -04:00
Martin Kröning
335d196498 Remove hermitkernel targets
RustyHermit now maintains custom json targets, which are distributed with the kernel. [1]

[1]: https://github.com/hermitcore/libhermit-rs/pull/395
2022-03-25 11:52:11 +01:00
Dylan DPC
67d6cc6ef3
Rollup merge of #91608 - workingjubilee:fold-neon-fp, r=nagisa,Amanieu
Fold aarch64 feature +fp into +neon

Arm's FEAT_FP and Feat_AdvSIMD describe the same thing on AArch64:
The Neon unit, which handles both floating point and SIMD instructions.
Moreover, a configuration for AArch64 must include both or neither.
Arm says "entirely proprietary" toolchains may omit floating point:
https://developer.arm.com/documentation/102374/0101/Data-processing---floating-point
In the Programmer's Guide for Armv8-A, Arm says AArch64 can have
both FP and Neon or neither in custom implementations:
https://developer.arm.com/documentation/den0024/a/AArch64-Floating-point-and-NEON

In "Bare metal boot code for Armv8-A", enabling Neon and FP
is just disabling the same trap flag:
https://developer.arm.com/documentation/dai0527/a

In an unlikely future where "Neon and FP" become unrelated,
we can add "[+-]fp" as its own feature flag.
Until then, we can simplify programming with Rust on AArch64 by
folding both into "[+-]neon", which is valid as it supersets both.

"[+-]neon" is retained for niche uses such as firmware, kernels,
"I just hate floats", and so on.

I am... pretty sure no one is relying on this.

An argument could be made that, as we are not an "entirely proprietary" toolchain, we should not support AArch64 without floats at all. I think that's a bit excessive. However, I want to recognize the intent: programming for AArch64 should be simplified where possible. For x86-64, programmers regularly set up illegal feature configurations because it's hard to understand them, see https://github.com/rust-lang/rust/issues/89586. And per the above notes, plus the discussion in https://github.com/rust-lang/rust/issues/86941, there should be no real use cases for leaving these features split: the two should in fact always go together.

- Fixes rust-lang/rust#95002.
- Fixes rust-lang/rust#95064.
- Fixes rust-lang/rust#95122.
2022-03-23 03:05:28 +01:00
Jubilee Young
b807d5970b Fold aarch64 feature +fp into +neon
Arm's FEAT_FP and Feat_AdvSIMD describe the same thing on AArch64:
The Neon unit, which handles both floating point and SIMD instructions.
Moreover, a configuration for AArch64 must include both or neither.
Arm says "entirely proprietary" toolchains may omit floating point:
https://developer.arm.com/documentation/102374/0101/Data-processing---floating-point
In the Programmer's Guide for Armv8-A, Arm says AArch64 can have
both FP and Neon or neither in custom implementations:
https://developer.arm.com/documentation/den0024/a/AArch64-Floating-point-and-NEON

In "Bare metal boot code for Armv8-A", enabling Neon and FP
is just disabling the same trap flag:
https://developer.arm.com/documentation/dai0527/a

In an unlikely future where "Neon and FP" become unrelated,
we can add "[+-]fp" as its own feature flag.
Until then, we can simplify programming with Rust on AArch64 by
folding both into "[+-]neon", which is valid as it supersets both.

"[+-]neon" is retained for niche uses such as firmware, kernels,
"I just hate floats", and so on.
2022-03-22 15:14:33 -07:00
codehorseman
01dbfb3eb2 resolve the conflict in compiler/rustc_session/src/parse.rs
Signed-off-by: codehorseman <cricis@yeah.net>
2022-03-16 20:12:30 +08:00
ridwanabdillahi
eae68350c8 Add support for targeting riscv32im-unknown-none-elf
Update riscv32im-unknown-none-elf to Tier2 support.

Downgrade to Tier 3 platform support.
2022-03-09 13:51:29 -08:00
Nicholas Nethercote
4f008e06c3 Clarify Layout interning.
`Layout` is another type that is sometimes interned, sometimes not, and
we always use references to refer to it so we can't take any advantage
of the uniqueness properties for hashing or equality checks.

This commit renames `Layout` as `LayoutS`, and then introduces a new
`Layout` that is a newtype around an `Interned<LayoutS>`. It also
interns more layouts than before. Previously layouts within layouts
(via the `variants` field) were never interned, but now they are. Hence
the lifetime on the new `Layout` type.

Unlike other interned types, these ones are in `rustc_target` instead of
`rustc_middle`. This reflects the existing structure of the code, which
does layout-specific stuff in `rustc_target` while `TyAndLayout` is
generic over the `Ty`, allowing the type-specific stuff to occur in
`rustc_middle`.

The commit also adds a `HashStable` impl for `Interned`, which was
needed. It hashes the contents, unlike the `Hash` impl which hashes the
pointer.
2022-03-07 13:41:47 +11:00
bors
0cbef1c6a7 Auto merge of #94601 - csmoe:android-asan, r=nagisa
add address sanitizer fo android

We have been being using asan to debug the rust/cpp/c mixed android application in production for months: recompile the rust library with a patched rustc, everything just works fine. The patch is really small thanks to `@nagisa` 's refactoring in https://github.com/rust-lang/rust/pull/81866

r? `@nagisa`
2022-03-05 22:52:08 +00:00
Dylan DPC
afa85f0841
Rollup merge of #94362 - Urgau:check-cfg-values, r=petrochenkov
Add well known values to `--check-cfg` implementation

This pull-request adds well known values for the well known names via `--check-cfg=values()`.

[RFC 3013: Checking conditional compilation at compile time](https://rust-lang.github.io/rfcs/3013-conditional-compilation-checking.html#checking-conditional-compilation-at-compile-time) doesn't define this at all, but this seems a nice improvement.
The activation is done by a empty `values()` (new syntax) similar to `names()` except that `names(foo)` also activate well known names while `values(aa, "aa", "kk")` would not.

As stated this use a different activation logic because well known values for the well known names are not always sufficient.
In fact this is problematic for every `target_*` cfg because of non builtin targets, as the current implementation use those built-ins targets to create the list the well known values.

The implementation is straight forward, first we gather (if necessary) all the values (lazily or not) and then we apply them.

r? ```@petrochenkov```
2022-03-04 22:58:34 +01:00
csmoe
6d41565726 add address sanitizer fo android 2022-03-04 10:21:43 +00:00
Loïc BRANSTETT
4aa92aff05 Add well known values to --check-cfg implementation 2022-03-04 11:15:38 +01:00
Dylan DPC
79c71d1f9e
Rollup merge of #94339 - Amanieu:arm-d32, r=nagisa
ARM: Only allow using d16-d31 with asm! when supported by the target

Support can be determined by checking for the "d32" LLVM feature.

r? ```````````````@nagisa```````````````
2022-03-04 02:06:40 +01:00
bors
edda7e959d Auto merge of #94216 - psumbera:sparc64-abi-fix2, r=nagisa
more complete sparc64 ABI fix for aggregates with floating point members

Previous fix didn't handle nested structures at all.
2022-02-28 11:54:17 +00:00
Amanieu d'Antras
7cee1b4aeb ARM: Only allow using d16-d31 with asm! when supported by the target
Support can be determined by checking for the "d32" LLVM feature.
2022-02-24 22:37:53 +00:00
Scott Mabin
65614e91ad riscv32imc_esp_espidf: set max_atomic_width to 64 2022-02-23 13:11:26 +00:00
Amanieu d'Antras
fb5539b475 Add tests 2022-02-21 18:28:22 +00:00
Amanieu d'Antras
fc41d4bf35 Take CodegenFnAttrs into account when validating asm! register operands
Checking of asm! register operands now properly takes function
attributes such as #[target_feature] and #[instruction_set] into
account.
2022-02-21 18:28:22 +00:00
Amanieu d'Antras
1ceb104851 On ARM, use relocation_model to detect whether r9 should be reserved
The previous approach of checking for the reserve-r9 target feature
didn't actually work because LLVM only sets this feature very late when
initializing the per-function subtarget.
2022-02-21 18:28:22 +00:00
Amanieu d'Antras
2e8a7663b4 Simplify gating of BPF w registers behind the alu32 target feature
This is already handled by supported_types().
2022-02-21 18:28:22 +00:00
Petr Sumbera
0d200116d3 formatting fixes 2022-02-21 14:23:22 +01:00
Petr Sumbera
a29477c9ca more complete sparc64 ABI fix for aggregates with floating point members
Previous fix didn't handle nested structures at all.
2022-02-21 13:49:36 +01:00
Matthias Krüger
f2d6770f77
Rollup merge of #94146 - est31:let_else, r=cjgillot
Adopt let else in more places

Continuation of #89933, #91018, #91481, #93046, #93590, #94011.

I have extended my clippy lint to also recognize tuple passing and match statements. The diff caused by fixing it is way above 1 thousand lines. Thus, I split it up into multiple pull requests to make reviewing easier. This is the biggest of these PRs and handles the changes outside of rustdoc, rustc_typeck, rustc_const_eval, rustc_trait_selection, which were handled in PRs #94139, #94142, #94143, #94144.
2022-02-20 00:37:34 +01:00
est31
2ef8af6619 Adopt let else in more places 2022-02-19 17:27:43 +01:00
Matthias Krüger
cb35370557
Rollup merge of #93877 - Amanieu:asm_fixes, r=nagisa
asm: Allow the use of r8-r14 as clobbers on Thumb1

Previously these were entirely disallowed, except for r11 which was allowed by accident.

cc `@hudson-ayers`
2022-02-18 23:23:08 +01:00
Matthias Krüger
32c8acd769
Rollup merge of #93814 - Itus-Shield:mips64-openwrt, r=bjorn3
mips64-openwrt-linux-musl: correct soft-foat

MIPS64 targets under OpenWrt require soft-float fpu support.

Rust-lang requires soft-float defined in tuple definition and
isn't over-ridden by toolchain compile-time CFLAGS/LDFLAGS

Set explicit soft-float for tuple.

Signed-off-by: Donald Hoskins <grommish@gmail.com>
2022-02-18 23:23:06 +01:00
Matthias Krüger
0bb72a2c66
Rollup merge of #91675 - ivanloz:memtagsan, r=nagisa
Add MemTagSanitizer Support

Add support for the LLVM [MemTagSanitizer](https://llvm.org/docs/MemTagSanitizer.html).

On hardware which supports it (see caveats below), the MemTagSanitizer can catch bugs similar to AddressSanitizer and HardwareAddressSanitizer, but with lower overhead.

On a tag mismatch, a SIGSEGV is signaled with code SEGV_MTESERR / SEGV_MTEAERR.

# Usage

`-Zsanitizer=memtag -C target-feature="+mte"`

# Comments/Caveats

* MemTagSanitizer is only supported on AArch64 targets with hardware support
* Requires `-C target-feature="+mte"`
* LLVM MemTagSanitizer currently only performs stack tagging.

# TODO

* Tests
* Example
2022-02-18 23:23:03 +01:00
Amanieu d'Antras
11250b8661 asm: Allow the use of r8-r14 as clobbers on Thumb1
Previously these were entirely disallowed, except for r11 which was
allowed by accident.
2022-02-18 20:26:40 +00:00
bors
30b3f35c42 Auto merge of #93577 - nikic:llvm-14, r=nagisa
Upgrade to LLVM 14

LLVM patch state:
 * [x] a55727f334 Backported.
 * [x] c3c82dc124 Backported as 917c47b3bf.
 * [x] 6e8f9ab632 No plan to upstream.
 * [x] 319f4b2d52 Backported.
 * [x] 8b2c25d321 No plan to upstream.
 * [x] 75fef2efd4 No plan to upstream.
 * [ ] adef757547 Upstreamed as 2d2ef384b2. Needs backport.
 * [x] 4b7c1b4910 No plan to upstream.
 * [x] 3f5ab0c061 No plan to upstream.
 * [x] 514d05500e No plan to upstream.
 * [ ] 54c5869585 Under review at https://reviews.llvm.org/D119695 and https://reviews.llvm.org/D119856.

Release timeline:
 * LLVM 14.0.0 final planned for Mar 15.
 * Rust 1.60.0 planned for Apr 7.

Compile-time:
  * https://perf.rust-lang.org/compare.html?start=250384edc5d78533e993f38c60d64e42b21684b2&end=b87df8d2c7c5d9ac448c585de10927ab2ee1b864
  * A slight improvement on average, though no big changes either way.
  * There are some larger max-rss improvements.

r? `@ghost`
2022-02-17 13:08:46 +00:00
Nikita Popov
70ddd2ff1c Update data layout for wasm32 targets
New address spaces were added in https://reviews.llvm.org/D111154.
2022-02-16 21:15:31 +01:00
Nikita Popov
a380581ff8 Update data layout for 32-bit msvc targets
https://reviews.llvm.org/D115942 changed the alignment of f80.
2022-02-16 21:15:30 +01:00
Ivan Lozano
568aeda9e9 MemTagSanitizer Support
Adds support for the LLVM MemTagSanitizer.
2022-02-16 09:39:03 -05:00
Tomasz Miąsko
81f12eb7ef Inline Target::deref 2022-02-15 19:08:12 +01:00
Vadim Petrochenkov
da4a235c26 rustc_target: Remove compiler-rt linking hack on Android 2022-02-13 21:22:02 +08:00
bors
5c30d65683 Auto merge of #93670 - erikdesjardins:noundef, r=nikic
Apply noundef attribute to &T, &mut T, Box<T>, bool

This doesn't handle `char` because it's a bit awkward to distinguish it from `u32` at this point in codegen.

Note that this _does not_ change whether or not it is UB for `&`, `&mut`, or `Box` to point to undef. It only applies to the pointer itself, not the pointed-to memory.

Fixes (partially) #74378.

r? `@nikic` cc `@RalfJung`
2022-02-13 00:14:52 +00:00
bors
502d6aa47b Auto merge of #93854 - matthiaskrgr:rollup-bh2a85j, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 - #92670 (add kernel target for RustyHermit)
 - #93756 (Support custom options for LLVM build)
 - #93802 (fix oversight in the `min_const_generics` checks)
 - #93808 (Remove first headings indent)
 - #93824 (Stabilize cfg_target_has_atomic)
 - #93830 (Refactor sidebar printing code)
 - #93843 (kmc-solid: Fix wait queue manipulation errors in the `Condvar` implementation)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2022-02-10 12:31:51 +00:00
Camille GILLOT
4435dfec0f Make FnAbiError Copy. 2022-02-09 20:11:29 +01:00
Donald Hoskins
bfd16ab109 mips64-openwrt-linux-musl: correct soft-foat
MIPS64 targets under OpenWrt require soft-float fpu support.

Rust-lang requires soft-float defined in tuple definition and
isn't over-ridden by toolchain compile-time CFLAGS/LDFLAGS

Set explicit soft-float for tuple.

Signed-off-by: Donald Hoskins <grommish@gmail.com>
2022-02-09 10:24:53 -05:00
Stefan Lankes
b5c1dc09fc rename file to use the correct naming convention 2022-02-08 09:34:36 +01:00
Stefan Lankes
beb042ae8f add missing targert for library operating system RustyHermit 2022-02-08 09:34:36 +01:00
Stefan Lankes
0b269f33f4 add kernel target for RustyHermit
Currently, we are thinking to use *-unknown-none targets instead
to define for every platform our own one (see hermitcore/rusty-hermit#197).
However, the current target aarch64-unknown-none-softfloat doesn't support
dynamic relocation. Our kernel uses this feature and consequently
we define a new target aarch64-unknown-hermitkernel to support it.
2022-02-08 09:33:29 +01:00
bors
2a8dbdb1e2 Auto merge of #93561 - Amanieu:more-unwind-abi, r=nagisa
Add more *-unwind ABI variants

The following *-unwind ABIs are now supported:
- "C-unwind"
- "cdecl-unwind"
- "stdcall-unwind"
- "fastcall-unwind"
- "vectorcall-unwind"
- "thiscall-unwind"
- "aapcs-unwind"
- "win64-unwind"
- "sysv64-unwind"
- "system-unwind"

cc `@rust-lang/wg-ffi-unwind`
2022-02-08 03:20:05 +00:00
Mara Bos
bd245facd4
Rollup merge of #93680 - Mark-Simulacrum:drop-json-reader, r=bjorn3
Drop json::from_reader

Just a small cleanup -- this was essentially unused; the one use site is better suited to reading from &str regardless.
2022-02-07 14:08:36 +00:00
Matthias Krüger
4a3be6e6e2
Rollup merge of #92383 - lancethepants:armv7-unknown-linux-uclibceabi, r=nagisa
Add new target armv7-unknown-linux-uclibceabi (softfloat)

This adds the new target `armv7-unknown-linux-uclibceabi (softfloat)`. It is of course similar to `armv7-unknown-linux-uclibceabihf (hardfloat)` which was just recently added to rust except that it is `softfloat`.

My interest lies in the Broadcom BCM4707/4708/BCM4709 family, notably found in some Netgear and Asus consumer routers. The armv7 Cortex-A9 cpus found in these devices do not have an fpu or NEON support.

With this patch I've been able to bootstrap rustc, std and host tools `(extended = true)` to run on the target device for native compilation, allowing the target to be used as a development platform.

With the recent addition of `armv7-unknown-linux-uclibceabihf (hardfloat)` it looks like many of the edge cases of using the uclibc c-library are getting worked out nicely. I've been able to compile some complex projects. Some patching still needed in some crates, but getting there for sure.  I think `armv7-unknown-linux-uclibceabi` is ready to be a tier 3 target.

I use a cross-toolchain from my project to bootstrap rust.
https://github.com/lancethepants/tomatoware
The goal of this project is to create a native development environment with support for various languages.
2022-02-06 04:13:30 +01:00
Matthias Krüger
0eda3fa761
Rollup merge of #92300 - Itus-Shield:mips64-openwrt, r=nagisa
mips64-openwrt-linux-musl: Add Tier 3 target

Tier 3 tuple for Mips64 OpenWrt toolchain.

This add first-time support for OpenWrt.  Future Tier3 targets will be added as I test them.

Signed-off-by: Donald Hoskins <grommish@gmail.com>
2022-02-06 04:13:29 +01:00
Mark Rousskov
0fb2b7a2da Drop json::from_reader
Performing UTF-8 decode outside the JSON module makes more sense in almost all cases.
2022-02-05 15:07:10 -05:00
Erik Desjardins
8cb0b6ca5b Apply noundef attribute to &T, &mut T, Box<T>, bool
This doesn't handle `char` because it's a bit awkward to distinguish it
from u32 at this point in codegen.

Note that for some types (like `&Struct` and `&mut Struct`),
we already apply `dereferenceable`, which implies `noundef`,
so the IR does not change.
2022-02-05 01:09:52 -05:00
lancethepants
8c6f7fd5e1 Add new target armv7-unknown-linux-uclibceabi (softfloat) 2022-02-04 11:45:00 -07:00
Amanieu d'Antras
547b4e601e Add more *-unwind ABI variants
The following *-unwind ABIs are now supported:
- "C-unwind"
- "cdecl-unwind"
- "stdcall-unwind"
- "fastcall-unwind"
- "vectorcall-unwind"
- "thiscall-unwind"
- "aapcs-unwind"
- "win64-unwind"
- "sysv64-unwind"
- "system-unwind"
2022-02-02 22:21:24 +01:00
Matthias Krüger
788f2969f6
Rollup merge of #92021 - woodenarrow:br_single_fp_element, r=Mark-Simulacrum
Eliminate duplicate codes of is_single_fp_element

There are duplicate codes of is_single_fp_element function. Merge these codes to TyAndLayout impl block.
![image](https://user-images.githubusercontent.com/95843988/146707753-ba9ffc41-5888-4a53-80cf-f4fe3bcbac54.png)
2022-02-01 16:08:03 +01:00
Matthias Krüger
ce6c1484f8
Rollup merge of #86374 - bossmc:enable-static-pie-for-gnu, r=nagisa
Enable combining `+crt-static` and `relocation-model=pic` on `x86_64-unknown-linux-gnu`

Modern `gcc` versions support `-static-pie`, and `rustc` will already fall-back to `-static` if the local `gcc` is too old (and hence this change is optimistic rather than absolute).  This brings the `-musl` and `-gnu` targets to feature compatibility (albeit with different default settings).

Of note a `-static` or `-static-pie` binary based on glibc that uses NSS-backed functions (`gethostbyname` or `getpwuid` etc.) need to have access to the `libnss_X.so.2` libraries and any of their dynamic dependencies.

I wasn't sure about the `# only`/`# ignore` changes (I've not got a `gnux32` toolchain to test with hence not also enabling `-static-pie` there).
2022-02-01 16:08:01 +01:00
Donald Hoskins
91fcbfa237 [mips64-openwrt-musl] Tier 3 tuple for Mips64 OpenWrt
This incorporates rust-lang into the OpenWrt build system for
Mips64 targets.

Signed-off-by: Donald Hoskins <grommish@gmail.com>
2022-01-31 03:03:06 -05:00
Matthias Krüger
6749f32c33
Rollup merge of #90277 - pierwill:fix-70258-inference-terms, r=jackh726
Improve terminology around "after typeck"

Closes #70258.
2022-01-31 06:58:26 +01:00
William D. Jones
19809ed76d Add preliminary support for inline assembly for msp430. 2022-01-22 23:42:46 -05:00
Benjamin Lamowski
660d993c64 adapt L4Bender implementation
- Fix style errors.

- L4-bender does not yet support dynamic linking.

- Stack unwinding is not yet supported for x86_64-unknown-l4re-uclibc.
  For now, just abort on panics.

- Use GNU-style linker options where possible. As suggested by review:
    - Use standard GNU-style ld syntax for relro flags.
    - Use standard GNU-style optimization flags and logic.
    - Use standard GNU-style ld syntax for --subsystem.

- Don't read environment variables in L4Bender linker. Thanks to
  CARGO_ENCODED_RUSTFLAGS introduced in #9601, l4-bender's arguments can
  now be passed from the L4Re build system without resorting to custom
  parsing of environment variables.
2022-01-21 16:50:33 +01:00
Sebastian Humenda
d98428711e Add L4Bender as linker variant 2022-01-21 16:28:33 +01:00
bjorn3
042aa379a5 Pass target_features set instead of has_feature closure
This avoids unnecessary monomorphizations in codegen backends
2022-01-17 18:06:30 +01:00
bjorn3
991cbd1503 Use Symbol for target features in asm handling
This saves a couple of Symbol::intern calls
2022-01-17 18:06:27 +01:00
Matthias Krüger
391b66ccff
Rollup merge of #92581 - Meziu:armv6k-3ds-target, r=nagisa
ARMv6K Horizon - Enable default libraries

Due to the nature of the external gcc linker, default libraries are required, even for `no_std` programs.
2022-01-16 16:58:12 +01:00
Lucas Kent
08829853d3 eplace usages of vec![].into_iter with [].into_iter 2022-01-09 14:09:25 +11:00
David Wood
08ed338f56 sess/cg: re-introduce split dwarf kind
In #79570, `-Z split-dwarf-kind={none,single,split}` was replaced by `-C
split-debuginfo={off,packed,unpacked}`. `-C split-debuginfo`'s packed
and unpacked aren't exact parallels to single and split, respectively.

On Unix, `-C split-debuginfo=packed` will put debuginfo into object
files and package debuginfo into a DWARF package file (`.dwp`) and
`-C split-debuginfo=unpacked` will put debuginfo into dwarf object files
and won't package it.

In the initial implementation of Split DWARF, split mode wrote sections
which did not require relocation into a DWARF object (`.dwo`) file which
was ignored by the linker and then packaged those DWARF objects into
DWARF packages (`.dwp`). In single mode, sections which did not require
relocation were written into object files but ignored by the linker and
were not packaged. However, both split and single modes could be
packaged or not, the primary difference in behaviour was where the
debuginfo sections that did not require link-time relocation were
written (in a DWARF object or the object file).

This commit re-introduces a `-Z split-dwarf-kind` flag, which can be
used to pick between split and single modes when `-C split-debuginfo` is
used to enable Split DWARF (either packed or unpacked).

Signed-off-by: David Wood <david.wood@huawei.com>
2022-01-06 09:32:42 +00:00
Andrea Ciliberti
8423ce9f9a Enable default libraries 2022-01-05 11:40:30 +01:00
bors
41c3017c82 Auto merge of #92099 - matthiaskrgr:rollup-4gwv67m, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 - #91141 (Revert "Temporarily rename int_roundings functions to avoid conflicts")
 - #91984 (Remove `in_band_lifetimes` from `rustc_middle`)
 - #92028 (Sync portable-simd to fix libcore build for AVX-512 enabled targets)
 - #92042 (Enable `#[thread_local]` for all windows-msvc targets)
 - #92071 (Update example code for Vec::splice to change the length)
 - #92077 (rustdoc: Remove unused `collapsed` field)
 - #92081 (rustdoc: Remove unnecessary `need_backline` function)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2021-12-19 12:36:56 +00:00
bors
a41a6925ba Auto merge of #91957 - nnethercote:rm-SymbolStr, r=oli-obk
Remove `SymbolStr`

This was originally proposed in https://github.com/rust-lang/rust/pull/74554#discussion_r466203544. As well as removing the icky `SymbolStr` type, it allows the removal of a lot of `&` and `*` occurrences.

Best reviewed one commit at a time.

r? `@oli-obk`
2021-12-19 09:31:37 +00:00
Chris Denton
391332c5d9
Rename has_elf_tls to has_thread_local 2021-12-17 20:56:38 +00:00
Chris Denton
9ca26f111a
Enable #[thread_local] for all windows-msvc targets 2021-12-17 15:47:44 +00:00
lzh
d9b98f9c23 Eliminate duplicate codes of is_single_fp_element 2021-12-17 11:48:44 +08:00
Nicholas Nethercote
056d48a2c9 Remove unnecessary sigils around Symbol::as_str() calls. 2021-12-15 17:32:14 +11:00
Hans Kratz
3011154573 Revert "Set MACOSX_DEPLOYMENT_TARGET env var to default for linking if not set."
This reverts commit b376f5621b, which is
the main part of #90499, because it turns out that this causes a good
amount of breakage in crates relying on the old behavior.

Fixes #91372.
2021-12-13 21:31:48 +01:00
Amanieu d'Antras
8716f2780e asm: Allow using r9 (ARM) and x18 (AArch64) if they are not reserved by
the current target.
2021-12-10 00:51:39 +00:00
Amanieu d'Antras
908f300dd7 Remove the reg_thumb register class for asm! on ARM
Also restricts r8-r14 from being used on Thumb1 targets as per #90736.
2021-12-07 23:54:09 +00:00
bors
0b6f079e49 Auto merge of #91224 - couchand:2021-11/avr-asm, r=Amanieu
Support AVR for inline asm!

A first pass at support for the AVR platform in inline `asm!`.  Passes the initial compiler tests, have not yet done more complete verification.

In particular, the register classes could use a lot more fleshing out, this draft PR so far only includes the most basic.

cc `@Amanieu` `@dylanmckay`
2021-12-07 14:23:01 +00:00
Andrew Dona-Couch
c6e8ae1a6c Implement inline asm! for AVR platform 2021-12-06 01:02:49 -05:00
bors
87dce6e8df Auto merge of #91284 - t6:freebsd-riscv64, r=Amanieu
Add support for riscv64gc-unknown-freebsd

For https://doc.rust-lang.org/nightly/rustc/target-tier-policy.html#tier-3-target-policy:

* A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)

For all Rust targets on FreeBSD, it's [rust@FreeBSD.org](mailto:rust@FreeBSD.org).

* Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.

Done.

* Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it.

Done

* Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.

Done.

* The target must not introduce license incompatibilities.

Done.

* Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).

Fine with me.

* The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements.

Done.

* If the target supports building host tools (such as rustc or cargo), those host tools must not depend on proprietary (non-FOSS) libraries, other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance, rustc built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3.

Done.

* Targets should not require proprietary (non-FOSS) components to link a functional binary or library.

Done.

* "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are not limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users.

Fine with me.

* Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.

Ok.

* This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements.

Ok.

* Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.

std is implemented.

* The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running tests (even if they do not pass), the documentation must explain how to run tests for the target, using emulation if possible or dedicated hardware if necessary.

Building is possible the same way as other Rust on FreeBSD targets.

* Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.

Ok.

* Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.

Ok.

* Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.

Ok.

* In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target.

Ok.
2021-12-06 03:51:05 +00:00
Matthias Krüger
971f469236
Rollup merge of #91537 - sunshowers:m68k-gnu, r=joshtriplett
compiler/rustc_target: make m68k-unknown-linux-gnu use the gnu base

This makes the m68k arch match the other GNU/Linux based targets by setting the environment to gnu.
2021-12-06 00:11:50 +01:00
Rain
6aa5f6faf3 compiler/rustc_target: make m68k-unknown-linux-gnu use the gnu base
This makes the m68k arch match the other GNU/Linux based targets.
2021-12-04 15:05:36 -08:00
Mara Bos
1acb44f03c Use IntoIterator for array impl everywhere. 2021-12-04 19:40:33 +01:00
bors
a2b7b7891e Auto merge of #91003 - psumbera:sparc64-abi, r=nagisa
fix sparc64 ABI for aggregates with floating point members

Fixes #86163
2021-12-02 02:59:44 +00:00
Petr Sumbera
128ceec92d fix sparc64 ABI for aggregates with floating point members 2021-12-01 10:03:45 +01:00
Tobias Kortkamp
47474f1055
Add riscv64gc-unknown-freebsd 2021-11-27 07:24:18 +01:00
Matthias Krüger
0780889833
Rollup merge of #90499 - rusticstuff:macos-target-fixes, r=petrochenkov
Link with default MACOSX_DEPLOYMENT_TARGET if not otherwise specified.

This PR sets the MACOSX_DEPLOYMENT_TARGET environment variable during the linking stage to our default, if it is not specified. This way it matches the deployment target we pass to llvm. If not set the the linker uses Xcode or Xcode commandline tools default which varies by version.

Fixes #90342, #91082.

Drive-by fixes to make Rust behave more like clang:
* Default to 11.0 deployment target for ARM64 which is the earliest version that had support for it.
* Set the llvm target to `arm64-apple-macosx<deployment target>` instead of `aarch64-apple-macosx<deployment target>`.
2021-11-25 15:05:36 +01:00
Hans Kratz
b376f5621b Set MACOSX_DEPLOYMENT_TARGET env var to default for linking if not set. 2021-11-25 07:08:44 +01:00
Hans Kratz
8f4d88c4bf Set the default deployment target for Macos ARM64 to 11.0.
11.0 (Big Sur) is the first version which supports ARM64 so we use
that as default.
2021-11-25 07:08:37 +01:00
Hans Kratz
fa18030567 The correct LLVM target for aarch64-apple-darwin is arm64-... (as with ios) 2021-11-25 06:56:42 +01:00
Guillaume Gomez
cbe563a4d5
Rollup merge of #90044 - rusticstuff:disable_arm_outline_atomics_for_musl, r=workingjubilee
Restrict aarch64 outline atomics to glibc for now.

The introduced dependency on `getauxval` causes linking problems with musl, making compiling any binaries for `aarch64-unknown-linux-musl` impossible without workarounds such as using lld or adding liblibc.rlib again to the linker invocation, see #89626.

This is a workaround until libc>0.2.108 is merged.
2021-11-24 22:56:36 +01:00
Benjamin A. Bjørnseth
bb9dee95ed add rustc option for using LLVM stack smash protection
LLVM has built-in heuristics for adding stack canaries to functions. These
heuristics can be selected with LLVM function attributes. This patch adds a
rustc option `-Z stack-protector={none,basic,strong,all}` which controls the use
of these attributes. This gives rustc the same stack smash protection support as
clang offers through options `-fno-stack-protector`, `-fstack-protector`,
`-fstack-protector-strong`, and `-fstack-protector-all`. The protection this can
offer is demonstrated in test/ui/abi/stack-protector.rs. This fills a gap in the
current list of rustc exploit
mitigations (https://doc.rust-lang.org/rustc/exploit-mitigations.html),
originally discussed in #15179.

Stack smash protection adds runtime overhead and is therefore still off by
default, but now users have the option to trade performance for security as they
see fit. An example use case is adding Rust code in an existing C/C++ code base
compiled with stack smash protection. Without the ability to add stack smash
protection to the Rust code, the code base artifacts could be exploitable in
ways not possible if the code base remained pure C/C++.

Stack smash protection support is present in LLVM for almost all the current
tier 1/tier 2 targets: see
test/assembly/stack-protector/stack-protector-target-support.rs. The one
exception is nvptx64-nvidia-cuda. This patch follows clang's example, and adds a
warning message printed if stack smash protection is used with this target (see
test/ui/stack-protector/warn-stack-protector-unsupported.rs). Support for tier 3
targets has not been checked.

Since the heuristics are applied at the LLVM level, the heuristics are expected
to add stack smash protection to a fraction of functions comparable to C/C++.
Some experiments demonstrating how Rust code is affected by the different
heuristics can be found in
test/assembly/stack-protector/stack-protector-heuristics-effect.rs. There is
potential for better heuristics using Rust-specific safety information. For
example it might be reasonable to skip stack smash protection in functions which
transitively only use safe Rust code, or which uses only a subset of functions
the user declares safe (such as anything under `std.*`). Such alternative
heuristics could be added at a later point.

LLVM also offers a "safestack" sanitizer as an alternative way to guard against
stack smashing (see #26612). This could possibly also be included as a
stack-protection heuristic. An alternative is to add it as a sanitizer (#39699).
This is what clang does: safestack is exposed with option
`-fsanitize=safe-stack`.

The options are only supported by the LLVM backend, but as with other codegen
options it is visible in the main codegen option help menu. The heuristic names
"basic", "strong", and "all" are hopefully sufficiently generic to be usable in
other backends as well.

Reviewed-by: Nikita Popov <nikic@php.net>

Extra commits during review:

- [address-review] make the stack-protector option unstable

- [address-review] reduce detail level of stack-protector option help text

- [address-review] correct grammar in comment

- [address-review] use compiler flag to avoid merging functions in test

- [address-review] specify min LLVM version in fortanix stack-protector test

  Only for Fortanix test, since this target specifically requests the
  `--x86-experimental-lvi-inline-asm-hardening` flag.

- [address-review] specify required LLVM components in stack-protector tests

- move stack protector option enum closer to other similar option enums

- rustc_interface/tests: sort debug option list in tracking hash test

- add an explicit `none` stack-protector option

Revert "set LLVM requirements for all stack protector support test revisions"

This reverts commit a49b74f92a4e7d701d6f6cf63d207a8aff2e0f68.
2021-11-22 20:06:22 +01:00
bors
b6f580acc0 Auto merge of #90382 - alexcrichton:wasm64-libstd, r=joshtriplett
std: Get the standard library compiling for wasm64

This commit goes through and updates various `#[cfg]` as appropriate to
get the wasm64-unknown-unknown target behaving similarly to the
wasm32-unknown-unknown target. Most of this is just updating various
conditions for `target_arch = "wasm32"` to also account for `target_arch
= "wasm64"` where appropriate. This commit also lists `wasm64` as an
allow-listed architecture to not have the `restricted_std` feature
enabled, enabling experimentation with `-Z build-std` externally.

The main goal of this commit is to enable playing around with
`wasm64-unknown-unknown` externally via `-Z build-std` in a way that's
similar to the `wasm32-unknown-unknown` target. These targets are
effectively the same and only differ in their pointer size, but wasm64
is much newer and has much less ecosystem/library support so it'll still
take time to get wasm64 fully-fledged.
2021-11-18 17:19:27 +00:00
Alex Crichton
97cd27ab1d Add emscripten to the "wasm" family of targets 2021-11-16 13:10:35 -08:00
Josh Stone
a24e2eddb1 Android is not GNU 2021-11-12 09:09:08 -08:00
Hans Kratz
bd287fa508 Disable aarch64 outline atomics with musl for now.
The introduced dependency on `getauxval`causes linking
problems with musl, see #89626.
2021-11-10 20:24:33 +01:00
Alex Crichton
7dc38369c0 Disable .debug_aranges for all wasm targets
This follows from discussion on
https://bugs.llvm.org/show_bug.cgi?id=52442 where it looks like this
section doesn't make sense for wasm targets.
2021-11-10 10:47:00 -08:00
Alex Crichton
d2a3c24a95 Update more rustc/libtest things for wasm64
* Add wasm64 variants for inline assembly along the same lines as wasm32
* Update a few directives in libtest to check for `target_family`
  instead of `target_arch`
* Update some rustc codegen and typechecks specialized for wasm32 to
  also work for wasm64.
2021-11-10 08:35:42 -08:00
Alex Crichton
cfb2f98e9e Enable WebAssembly features by default on wasm64
These are all stable as-of-now in the WebAssembly specification so any
engine which implements wasm64 will surely implement these features as
well.
2021-11-10 08:35:42 -08:00
Alex Crichton
7f3ffbc8c2 std: Get the standard library compiling for wasm64
This commit goes through and updates various `#[cfg]` as appropriate to
get the wasm64-unknown-unknown target behaving similarly to the
wasm32-unknown-unknown target. Most of this is just updating various
conditions for `target_arch = "wasm32"` to also account for `target_arch
= "wasm64"` where appropriate. This commit also lists `wasm64` as an
allow-listed architecture to not have the `restricted_std` feature
enabled, enabling experimentation with `-Z build-std` externally.

The main goal of this commit is to enable playing around with
`wasm64-unknown-unknown` externally via `-Z build-std` in a way that's
similar to the `wasm32-unknown-unknown` target. These targets are
effectively the same and only differ in their pointer size, but wasm64
is much newer and has much less ecosystem/library support so it'll still
take time to get wasm64 fully-fledged.
2021-11-10 08:35:42 -08:00
Guillaume Gomez
f07f800364
Rollup merge of #90494 - Meziu:armv6k-3ds-target, r=sanxiyn
ARMv6K Horizon OS panic change

After a small change to `backtrace-rs` ([#448](https://github.com/rust-lang/backtrace-rs/pull/448)), `PanicStrategy::Unwind` is now fully supported.
2021-11-08 15:15:22 +01:00
Matthias Krüger
5c454551da more clippy fixes 2021-11-07 16:59:05 +01:00
pierwill
521b1ee974 Improve terminology around "after typeck" 2021-11-06 20:59:38 -05:00
Josh Stone
767471edeb Update LLVM comments around NoAliasMutRef 2021-11-05 12:22:51 -07:00
Josh Stone
c9567e2424 Move outline-atomics to aarch64-linux target definitions 2021-11-05 10:28:12 -07:00
Meziu
9cab312e54 ARMv6K Horizon OS panic change 2021-11-02 08:44:22 +01:00
Hans Kratz
37476287bf Use apple-a14 as target CPU for aarch64-apple-darwin.
After updating the minimum required LLVM version to 12 we can use
apple-a14 as that is closer in features to the Apple M1 than the A12.
Once the minimum required LLVM version is updated to 13 we can use
apple-m1.
2021-11-01 17:03:07 +01:00
bors
ff0e14829e Auto merge of #89062 - mikeleany:new-target, r=cjgillot
Add new tier 3 target: `x86_64-unknown-none`

Adds support for compiling OS kernels or other bare-metal applications for the x86-64 architecture.

Below are details on how this target meets the requirements for tier 3:

> A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)

I would be willing to be a target maintainer, though I would appreciate if others volunteered to help with that as well.

> Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.

Uses the same naming as the LLVM target, and the same convention as many other bare-metal targets.

> Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it.

I don't believe there is any ambiguity here.

> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.

I don't see any legal issues here.

> The target must not introduce license incompatibilities.
> Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).
> The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements.
>If the target supports building host tools (such as rustc or cargo), those host tools must not depend on proprietary (non-FOSS) libraries, other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance, rustc built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3.
> Targets should not require proprietary (non-FOSS) components to link a functional binary or library.
> "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are not limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users.

I see no issues with any of the above.

> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
> This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements.

Only relevant to those making approval decisions.

> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.

`core` and `alloc` can be used. `std` cannot be used as this is a bare-metal target.

> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running tests (even if they do not pass), the documentation must explain how to run tests for the target, using emulation if possible or dedicated hardware if necessary.

Use `--target=x86_64-unknown-none-elf` option to cross compile, just like any target. The target does not support running tests.

> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.
> Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.

I don't foresee this being a problem.

> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
> In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target.

No other targets should be affected by the pull request.
2021-10-31 18:57:14 +00:00
Martin Kröning
311a249f9d hermitkernel-target: Set OS to "none"
For our kernel targets, we should not set OS, as the kernel runs bare
metal without a circular dependency on std.

This also prepares us for unifying with
https://github.com/rust-lang/rust/pull/89062. This patch requires
libhermit-rs to change a `cfg`s from `target_os = "hermit"` to `target_os
= "none"`.

I tested this patch locally.
2021-10-29 18:07:36 +02:00
Andy Caldwell
b94da2bace
Enable combining +crt-static and relocation-model=pic on x86_64-unknown-linux-gnu 2021-10-28 15:32:37 +01:00
bors
a8f6e614f8 Auto merge of #89652 - rcvalle:rust-cfi, r=nagisa
Add LLVM CFI support to the Rust compiler

This PR adds LLVM Control Flow Integrity (CFI) support to the Rust compiler. It initially provides forward-edge control flow protection for Rust-compiled code only by aggregating function pointers in groups identified by their number of arguments.

Forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by defining and using compatible type identifiers (see Type metadata in the design document in the tracking issue #89653).

LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e., -Clto).

Thank you, `@eddyb` and `@pcc,` for all the help!
2021-10-27 09:19:42 +00:00
Ramon de C Valle
5d30e93189 Add LLVM CFI support to the Rust compiler
This commit adds LLVM Control Flow Integrity (CFI) support to the Rust
compiler. It initially provides forward-edge control flow protection for
Rust-compiled code only by aggregating function pointers in groups
identified by their number of arguments.

Forward-edge control flow protection for C or C++ and Rust -compiled
code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code
share the same virtual address space) will be provided in later work as
part of this project by defining and using compatible type identifiers
(see Type metadata in the design document in the tracking issue #89653).

LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e.,
-Clto).
2021-10-25 16:23:01 -07:00
DrMeepster
a46daf050b make thiscall on unsupported platforms an error 2021-10-25 14:56:21 -07:00
bors
d45ed7502a Auto merge of #90040 - nbdd0121:issue-90038, r=oli-obk
Fix wrong niche calculation when 2+ niches are placed at the start

When the niche is at the start, existing code incorrectly uses 1 instead of count for subtraction.

Fix #90038

`@rustbot` label: T-compiler
2021-10-19 08:13:35 +00:00
Gary Guo
7dbd5bb0bd Fix issue 90038 2021-10-19 06:43:33 +01:00
Stefan Lankes
7f34cedaef HermitCore's kernel itself doesn't support TLS
HermitCore's kernel itself doesn't support TLS.
Consequently, the entries in x86_64-unknown-none-hermitkernel should be removed.
This commit should help to finalize #89062.
2021-10-16 09:41:59 +02:00
Mike Leany
11d54dc1c6 Fix issue where PIC was added to the wrong target.
Should be for x86_64_unknown_none, but aarch64_unknown_none was inadvertently
updated instead.
2021-10-14 12:10:20 -06:00
Josh Triplett
3a1879299e x86_64-unknown-none: Use position-independent code by default
This avoids requiring relocation code, which a bare-metal environment
may not have or want.
2021-10-13 08:14:13 -06:00
Mike Leany
8b6764c4ef Fix build errors. 2021-10-13 08:14:13 -06:00
Josh Triplett
2037cee701 x86_64-unknown-none: Expand TargetOptions to specify more details
Specify the `cpu` and the `max_atomic_width` (64).

Set `stack_probes` similarly to other targets to work around known
issues, and copy the corresponding comment from those targets.

Build position-independent code that doesn't require relocations.

(Work on this target sponsored by Profian.)
2021-10-13 08:14:13 -06:00
Josh Triplett
6ab66192f9 x86_64-unknown-none: Disable more target features
Based on the list used for x86_64-unknown-none-linuxkernel.

(Work on this target sponsored by Profian.)
2021-10-13 08:14:12 -06:00
Josh Triplett
b0d1e3be23 x86_64-unknown-none: Drop the abi field
(Work on this target sponsored by Profian.)
2021-10-13 08:14:12 -06:00
Josh Triplett
b0efa05e5a x86_64-unknown-none: Fix module comment
(Work on this target sponsored by Profian.)
2021-10-13 08:14:12 -06:00
Josh Triplett
a23ee64c2c Rename x86_64-unknown-none-elf to x86_64-unknown-none
Most Rust freestanding/bare-metal targets use just `-unknown-none` here,
including aarch64-unknown-none, mipsel-unknown-none, and the BPF
targets. The *only* target using `-unknown-none-elf` is RISC-V.

The underlying toolchain doesn't care; LLVM accepts both `x86_64-unknown-none`
and `x86_64-unknown-none-elf`.

In addition, there's a long history of embedded x86 targets with varying
definitions for the `elf` suffix; on some of those embedded targets,
`elf` implied the inclusion of a C library based on newlib or similar.
Using `x86_64-unknown-none` avoids any potential ambiguity there.

(Work on this target sponsored by Profian.)
2021-10-13 08:14:09 -06:00
Mike Leany
5ba3a651f9 Use CodeModel::Kernel for x86_64-unknown-none-elf. 2021-10-13 08:13:00 -06:00
Mike Leany
80654c3d93 Fix code formatting. 2021-10-13 08:12:59 -06:00
Mike Leany
8aad5f45d5 Add new target: x86_64-unknown-none-elf 2021-10-13 08:12:50 -06:00
Jonah Petri
bc3eb354e7 add platform support details file for armv7-unknown-linux-uclibc 2021-10-06 14:33:13 +00:00
Yannick Koehler
11381a5a3a Add new target armv7-unknown-linux-uclibceabihf
Co-authored-by: Jonah Petri <jonah@petri.us>
2021-10-06 14:33:13 +00:00
bjorn3
83ddedf170 Remove various unused feature gates 2021-10-02 19:09:18 +02:00
Manish Goregaokar
6f1e930581
Rollup merge of #88820 - hlopko:add_pie_relocation_model, r=petrochenkov
Add `pie` as another `relocation-model` value

MCP: https://github.com/rust-lang/compiler-team/issues/461
2021-10-01 09:18:16 -07:00
Marcel Hlopko
198d90786b Add pie as another relocation-model value 2021-10-01 08:06:42 +02:00
Tomoaki Kawada
da9ca41c31 Add SOLID targets
SOLID[1] is an embedded development platform provided by Kyoto
Microcomputer Co., Ltd. This commit introduces a basic Tier 3 support
for SOLID.

# New Targets

The following targets are added:

 - `aarch64-kmc-solid_asp3`
 - `armv7a-kmc-solid_asp3-eabi`
 - `armv7a-kmc-solid_asp3-eabihf`

SOLID's target software system can be divided into two parts: an
RTOS kernel, which is responsible for threading and synchronization,
and Core Services, which provides filesystems, networking, and other
things. The RTOS kernel is a μITRON4.0[2][3]-derived kernel based on
the open-source TOPPERS RTOS kernels[4]. For uniprocessor systems
(more precisely, systems where only one processor core is allocated for
SOLID), this will be the TOPPERS/ASP3 kernel. As μITRON is
traditionally only specified at the source-code level, the ABI is
unique to each implementation, which is why `asp3` is included in the
target names.

More targets could be added later, as we support other base kernels
(there are at least three at the point of writing) and are interested
in supporting other processor architectures in the future.

# C Compiler

Although SOLID provides its own supported C/C++ build toolchain, GNU Arm
Embedded Toolchain seems to work for the purpose of building Rust.

# Unresolved Questions

A μITRON4 kernel can support `Thread::unpark` natively, but it's not
used by this commit's implementation because the underlying kernel
feature is also used to implement `Condvar`, and it's unclear whether
`std` should guarantee that parking tokens are not clobbered by other
synchronization primitives.

# Unsupported or Unimplemented Features

Most features are implemented. The following features are not
implemented due to the lack of native support:

- `fs::File::{file_attr, truncate, duplicate, set_permissions}`
- `fs::{symlink, link, canonicalize}`
- Process creation
- Command-line arguments

Backtrace generation is not really a good fit for embedded targets, so
it's intentionally left unimplemented. Unwinding is functional, however.

## Dynamic Linking

Dynamic linking is not supported. The target platform supports dynamic
linking, but enabling this in Rust causes several problems.

 - The linker invocation used to build the shared object of `std` is
   too long for the platform-provided linker to handle.

 - A linker script with specific requirements is required for the
   compiled shared object to be actually loadable.

As such, we decided to disable dynamic linking for now. Regardless, the
users can try to create shared objects by manually invoking the linker.

## Executable

Building an executable is not supported as the notion of "executable
files" isn't well-defined for these targets.

[1] https://solid.kmckk.com/SOLID/
[2] http://ertl.jp/ITRON/SPEC/mitron4-e.html
[3] https://en.wikipedia.org/wiki/ITRON_project
[4] https://toppers.jp/
2021-09-28 11:31:47 +09:00
the8472
26c7838118
Rollup merge of #89170 - rusticstuff:aarch64_macos_disable_leak_sanitizer, r=petrochenkov
Disable the leak sanitizer on Macos aarch64 for now

It is currently broken, see #88132.
2021-09-22 19:03:27 +02:00
Hans Kratz
59e37c829b Disable the leak sanitizer on Macos aarch64 for now.
It is currently broken, see #88132.
2021-09-22 08:05:34 +02:00
Mark Rousskov
c746be2219 Migrate to 2021 2021-09-20 22:21:42 -04:00
bors
db1fb85cff Auto merge of #88321 - glaubitz:m68k-linux, r=wesleywiser
Add initial support for m68k

This patch series adds initial support for m68k making use of the new M68k
backend introduced with LLVM-13. Additional changes will be needed to be
able to actually use the backend for this target.
2021-09-20 07:21:05 +00:00
Eduard-Mihai Burtescu
c1837ef1c5 Querify fn_abi_of_{fn_ptr,instance}. 2021-09-18 04:41:33 +03:00
Eduard-Mihai Burtescu
344df76fed ty::layout: intern FnAbis as &'tcx. 2021-09-18 01:42:45 +03:00
Eduard-Mihai Burtescu
7f2f927eb8 ty::layout: propagate errors up to (but not out of) FnAbi::of_*. 2021-09-18 01:42:44 +03:00
Eduard-Mihai Burtescu
4d36faf9ef rustc_target: adjust_for_cabi -> adjust_for_foreign_abi. 2021-09-18 01:42:43 +03:00
John Paul Adrian Glaubitz
580559129b compiler/rustc_target: Add support for m68k-linux-gnu 2021-09-17 15:07:12 +00:00
bors
9f85cd6f2a Auto merge of #87794 - bonega:enum_niche_prefer_zero, r=nagisa
Enum should prefer discriminant zero for niche

Given an enum with unassigned zero-discriminant, rust should prefer it for niche selection.
Zero as discriminant for `Option<Enum>` makes it possible for LLVM to optimize resulting asm.

- Eliminate branch when expected value coincides.
- Use smaller instruction `test eax, eax` instead of `cmp eax, ?`
- Possible interaction with zeroed memory?

Example:
```rust

pub enum Size {
    One = 1,
    Two = 2,
    Three = 3,
}

pub fn handle(x: Option<Size>) -> u8 {
    match x {
        None => {0}
        Some(size) => {size as u8}
    }
}
```
In this case discriminant zero is available as a niche.

Above example on nightly:
```asm
 mov     eax, edi
 cmp     al, 4
 jne     .LBB0_2
 xor     eax, eax
.LBB0_2:
 ret
```

PR:
```asm
 mov     eax, edi
 ret
```

I created this PR because I had a performance regression when I tried to use an enum to represent legal grapheme byte-length for utf8.

Using an enum instead of `NonZeroU8` [here](d683304f5d/src/internal/decoder_incomplete.rs (L90))
resulted in a performance regression of about 5%.
I consider this to be a somewhat realistic benchmark.

Thanks to `@ogoffart` for pointing me in the right direction!

Edit: Updated description
2021-09-13 22:14:57 +00:00
Andreas Liljeqvist
4d66fbc4b9 enum niche allocation grows toward zero if possible 2021-09-13 21:55:14 +02:00
bors
61a1029143 Auto merge of #88529 - Meziu:master, r=nagisa
ARMv6K Nintendo 3DS Tier 3 target added

Addition of the target specifications to build .elf files for Nintendo 3DS (ARMv6K, Horizon). Requires devkitARM 3DS toolkit for system libraries and arm-none-eabi-gcc linker.
2021-09-13 05:48:03 +00:00
Meziu
e07ae3ca26 ARMV6K 3DS: Removed useless parameters in target spec 2021-09-10 20:20:12 +02:00
Andreas Liljeqvist
bc95994c32 bugfix 2021-09-09 10:41:20 +02:00
Andreas Liljeqvist
a2ee1420b8 Wrap 2021-09-09 10:41:20 +02:00
Andreas Liljeqvist
9095cf9905 rename is_valid_for to is_valid 2021-09-09 10:41:19 +02:00
Andreas Liljeqvist
dd34e0c966 Rename (un)signed to (un)signed_int 2021-09-09 10:41:19 +02:00