Commit Graph

583 Commits

Author SHA1 Message Date
bors
b6f580acc0 Auto merge of - 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 .
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 - Meziu:armv6k-3ds-target, r=sanxiyn
ARMv6K Horizon OS panic change

After a small change to `backtrace-rs` ([](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 - 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 - 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 ).

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 ).

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 - 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 

`@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 .
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 - 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 - rusticstuff:aarch64_macos_disable_leak_sanitizer, r=petrochenkov
Disable the leak sanitizer on Macos aarch64 for now

It is currently broken, see .
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 .
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 - 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 - 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 - 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
Andreas Liljeqvist
9129f4306f Move unsigned_max etc into Size again 2021-09-09 10:41:19 +02:00
Andreas Liljeqvist
5b2f757dae Make abi::Abi Copy and remove a *lot* of refs
fix

fix

Remove more refs and clones

fix

more

fix
2021-09-09 10:41:19 +02:00
Andreas Liljeqvist
86ff6aeb82 Fix docstring 2021-09-09 10:41:18 +02:00
Andreas Liljeqvist
da92cd6dcf Use special Debug format when start > end 2021-09-09 10:41:18 +02:00
Andreas Liljeqvist
f5d8749f85 Remove contains_zero, respect the compiler 2021-09-09 10:41:18 +02:00
Andreas Liljeqvist
021c3346ed derive Copy for WrappingRange and Scalar 2021-09-09 10:41:18 +02:00
Andreas Liljeqvist
4c46296f22 fix match 2021-09-09 10:41:18 +02:00
Andreas Liljeqvist
05cd48b008 Add methods for checking for full ranges to Scalar and WrappingRange
Move *_max methods back to util

change to inline instead of inline(always)

Remove valid_range_exclusive from scalar
Use WrappingRange instead

implement always_valid_for in a safer way

Fix accidental edit
2021-09-09 10:41:17 +02:00
bors
e2750baf53 Auto merge of - eddyb:layout-off, r=nagisa
Provide `layout_of` automatically (given tcx + param_env + error handling).

After , there's no longer any uses of `LayoutOf` within `rustc_target` itself, so I realized I could move the trait to `rustc_middle::ty::layout` and redesign it a bit.

This is similar to  (and supersedes it), but at no ergonomic loss, since there's no funky `C: LayoutOf<Ty = Ty>` -> `Ty: TyAbiInterface<C>` generic `impl` chain, and each `LayoutOf` still corresponds to one `impl` (of `LayoutOfHelpers`) for the specific context.

After this PR, this is what's needed to get `trait LayoutOf` (with the `layout_of` method) implemented on some context type:
* `TyCtxt`, via `HasTyCtxt`
* `ParamEnv`, via `HasParamEnv`
* a way to transform `LayoutError`s into the desired error type
  * an error type of `!` can be paired with having `cx.layout_of(...)` return `TyAndLayout` *without* `Result<...>` around it, such as used by codegen
  * this is done through a new `LayoutOfHelpers` trait (and so is specifying the type of `cx.layout_of(...)`)

When going through this path (and not bypassing it with a manual `impl` of `LayoutOf`), the end result is that only the error case can be customized, the query itself and the success paths are guaranteed to be uniform.

(**EDIT**: just noticed that because of the supertrait relationship, you cannot actually implement `LayoutOf` yourself, the blanket `impl` fully covers all possible context types that could ever implement it)

Part of the motivation for this shape of API is that I've been working on querifying `FnAbi::of_*`, and what I want/need to introduce for that looks a lot like the setup in this PR - in particular, it's harder to express the `FnAbi` methods in `rustc_target`, since they're much more tied to `rustc` concepts.

r? `@nagisa` cc `@oli-obk` `@bjorn3`
2021-09-05 16:14:41 +00:00
bors
4878034c00 Auto merge of - devnexen:sunos_asan, r=wesleywiser
sunos systems add sanitizer supported.
2021-09-03 17:50:51 +00:00
bors
64929313f5 Auto merge of - matthiaskrgr:clippy_perf_end_august, r=jyn514,GuillaumeGomez
some low hanging clippy::perf fixes
2021-09-02 10:27:44 +00:00
bors
b27ccbc7e1 Auto merge of - cjgillot:abilint, r=estebank
Lint missing Abi in ast validation instead of lowering.
2021-09-02 06:06:24 +00:00
Eduard-Mihai Burtescu
4ce933f13f rustc_target: move LayoutOf to ty::layout. 2021-09-02 01:17:14 +03:00
Mara Bos
494c563f3b
Rollup merge of - programmerjake:add-ppc-cr-xer-clobbers, r=Amanieu
add support for clobbering xer, cr, and cr[0-7] for asm! on OpenPower/PowerPC

Fixes 
2021-09-01 09:23:26 +02:00
Camille GILLOT
8d7d488d3b Lint Abi in ast validation. 2021-08-31 20:30:17 +02:00
Matthias Krüger
7f2df9ad65 some low hanging clippy::perf fixes 2021-08-31 20:29:04 +02:00
Meziu
8078c4c809 ARMv6K Nintendo 3DS Tier 3 target added 2021-08-31 14:11:23 +02:00
David Carlier
8539a3c001 sunos systems add sanitizer supported. 2021-08-30 18:49:56 +01:00
Simonas Kazlauskas
748a089acd Disallow the aapcs CC on Aarch64
This never really worked and makes LLVM assert.
2021-08-30 13:46:07 +03:00
bors
9556d7a09a Auto merge of - eddyb:field-failure-is-not-an-option, r=nagisa
rustc_target: `TyAndLayout::field` should never error.

This refactor (making `TyAndLayout::field` return `TyAndLayout` without any `Result` around it) is based on a simple observation, regarding `TyAndLayout::field`:

If `cx.layout_of(ty)` succeeds (for some `cx` and `ty`), then `.field(cx, i)` on the resulting `TyAndLayout` should *always* succeed in computing `cx.layout_of(field_ty)` (where `field_ty` is the type of the `i`th field of `ty`).

The reason for this is that no matter which field is chosen, `cx.layout_of(field_ty)` *will have already been computed*, as part of computing `cx.layout_of(ty)`, as we cannot determine the layout of *any* type without considering the layouts of *all* of its fields.

And so it should be fine to turn any errors into ICEs, since they likely indicate a `cx` mismatch, or some other edge case that is due to a compiler bug (as opposed to ever being an user-facing error).

<hr/>

Each commit should probably be reviewed separately, though note that there's some `where` clauses (in `rustc_target::abi::call::*`) that change in most commits.

cc `@nagisa` `@oli-obk`
2021-08-29 22:54:26 +00:00
Eduard-Mihai Burtescu
78778fc6aa rustc_target: remove LayoutOf bound from TyAbiInterface. 2021-08-30 00:44:12 +03:00
Eduard-Mihai Burtescu
8e6d126b7d rustc_target: TyAndLayout::field should never error. 2021-08-30 00:44:09 +03:00
bors
757a65bfdf Auto merge of - rusticstuff:macos-lld, r=nagisa
Make `-Z gcc-ld=lld` work for Apple targets

`-Z gcc-ld=lld` was introduced in . It does not work on Macos because lld needs be either named `ld64` or passed `-flavor darwin` as the first two arguments in order to select the Mach-O flavor. Rust invokes cc (=clang) on Macos for linking which calls `ld` as linker binary and not `ld64`, so just creating an `ld64` binary and modifying the search path with `-B` does not work.

In order to solve this patch does:
* Set the `lld_flavor` for all Apple-derived targets to `LldFlavor::Ld64`. As far as I can see this actually works towards fixing `-Xlinker=rust-lld` as all those targets use the Mach-O object format.
* Copy/hardlink rust-lld to the gcc-ld subdirectory as ld64 next to ld.
* If `-Z gcc-ld=lld` is used and the target lld flavor is Ld64 add `-fuse-ld=/path/to/ld64` to the linker invocation.

Fixes .
2021-08-29 04:51:14 +00:00
bors
2031fd6e46 Auto merge of - Sl1mb0:s390-asm, r=Amanieu
S390x inline asm

This adds register definitions and constraint codes for the s390x general and floating point registers necessary for fixing ; as well as a few tests.

Further testing is needed, but I am a little unsure of what specific tests should be added to `src/test/assembly/asm/s390x.rs` to address this.
2021-08-28 08:04:41 +00:00
Eduard-Mihai Burtescu
87d1fb747f rustc_target: require TyAbiInterface in LayoutOf. 2021-08-27 13:09:32 +03:00
Eduard-Mihai Burtescu
8486571a10 rustc_target: rename TyAndLayoutMethods to TyAbiInterface. 2021-08-27 13:09:32 +03:00
Eduard-Mihai Burtescu
83d986aa28 rustc_target: add lifetime parameter to LayoutOf. 2021-08-27 13:09:32 +03:00
Eduard-Mihai Burtescu
efb4148865 #[inline] non-generic pub fns in rustc_target::abi and ty::layout. 2021-08-26 21:47:42 +03:00
bors
4b9f4b221b Auto merge of - eddyb:cooked-layouts, r=nagisa
Morph `layout_raw` query into `layout_of`.

Before this PR, `LayoutCx::layout_of` wrapped the `layout_raw` query, to:
* normalize the type, before attempting to compute the layout
* pass the layout to `record_layout_for_printing`, for `-Zprint-type-sizes`

Moving those two responsibilities into the query may reduce overhead (due to cached calls skipping those steps), but I want to do a perf run to know.

One of the changes I had to make was changing the return type of the query, to be able to both get out the type produced by normalizing inside the query *and* to match the signature of the old `TyCtxt::layout_of`. This change may be worse, perf-wise, so that's another reason I want to check.

r? `@nagisa` cc `@oli-obk`
2021-08-26 15:24:01 +00:00
Jacob Lifshay
5802f60355 add support for clobbering xer, cr, and cr[0-7] for asm! on OpenPower/PowerPC
Fixes 
2021-08-25 22:08:27 -07:00
Erik Desjardins
4d635fdf63 use undef for uninitialized bytes in constants 2021-08-25 17:49:28 -04:00
bors
e5484cec0e Auto merge of - bonega:allocation_range, r=oli-obk
Use custom wrap-around type instead of RangeInclusive

Two reasons:

1. More memory is allocated than necessary for `valid_range` in `Scalar`. The range is not used as an iterator and `exhausted` is never used.
2. `contains`, `count` etc. methods in `RangeInclusive` are doing very unhelpful(and dangerous!) things when used as a wrap-around range. - In general this PR wants to limit potentially confusing methods, that have a low probability of working.

Doing a local perf run, every metric shows improvement except for instructions.
Max-rss seem to have a very consistent improvement.

Sorry - newbie here, probably doing something wrong.
2021-08-25 02:17:41 +00:00
Eduard-Mihai Burtescu
edb4b2d8c2 Morph layout_raw query into layout_of. 2021-08-24 22:04:27 +03:00
Andreas Liljeqvist
f17e384a43 use convention for with_* methods 2021-08-24 19:41:58 +02:00
bors
47ab5f7ce2 Auto merge of - ubamrein:use-iphone-deployment-target-for-llvm, r=petrochenkov
Allow specifying an deployment target version for all iOS llvm targets

Closes: https://github.com/rust-lang/rust/issues/79408

This pull requests adds the same procedure to define the iOS-version for the LLVM-target as was used for the simulator target and the desktop target.

This then closes the original problem mentioned in the above issue. The problem with incompatible bitcode remains, but is probably not easy fixable.

I realised that something is still not right. Try to fix that.

r? `@petrochenkov`
2021-08-24 12:13:37 +00:00
Andreas Liljeqvist
e3f07b2e30 Force inline: small functions and single call-site 2021-08-24 10:18:07 +02:00
Patrick Amrein
8f65d154c8 allow specifying an ios version for the llvm target 2021-08-24 08:23:05 +02:00
linux1
a9f623707b Fix: made suggested change 2021-08-23 17:56:04 -04:00
linux1
05cd587726 Refactor: disabled frame pointer; consolidated unsupported register errors; added register prefix 2021-08-23 17:32:27 -04:00
Mara Bos
5cf025f076
Rollup merge of - steffahn:a_an, r=oli-obk
Fix typos “a”→“an”

Fix typos in comments; found using a regex to find some easy instance of incorrect usage of a vs. an.

While automation was used to find these, every change was checked manually.

Changes in submodules get separate PRs:
* https://github.com/rust-lang/stdarch/pull/1201
* https://github.com/rust-lang/cargo/pull/9821
* https://github.com/rust-lang/miri/pull/1874
* https://github.com/rust-lang/rls/pull/1746
* https://github.com/rust-analyzer/rust-analyzer/pull/9984
  _folks @ rust-analyzer are fast at merging…_
  * https://github.com/rust-analyzer/rust-analyzer/pull/9985
  * https://github.com/rust-analyzer/rust-analyzer/pull/9987
  * https://github.com/rust-analyzer/rust-analyzer/pull/9989

_For `clippy`, I don’t know if the changes should better better be moved to a PR to the original repo._

<hr>

This has some overlap with , but neither is a strict superset of the other.

If you want multiple commits, I can split it up; in that case, make sure to suggest a criterion for splitting.
2021-08-23 20:45:49 +02:00
Andreas Liljeqvist
d92810646e Simplify zero check 2021-08-23 15:52:47 +02:00
Andreas Liljeqvist
32d7e5b723 add with_start and with_end 2021-08-23 15:44:56 +02:00
Andreas Liljeqvist
d230b92ba7 implement debug in similar way to RangeInclusive 2021-08-23 15:05:40 +02:00
Andreas Liljeqvist
e8e6d9bd86 Rename to WrappingRange 2021-08-23 14:24:34 +02:00
Andreas Liljeqvist
70433955f4 implement contains_zero method 2021-08-23 14:20:38 +02:00
Andreas Liljeqvist
d50abd0249 Use ref 2021-08-23 14:18:48 +02:00
Andreas Liljeqvist
225a4bf922 Removed fixed fixme 2021-08-23 13:56:28 +02:00
Hans Kratz
0ac601d03e Mach-O (Macos/ios/...) LLD flavor is always LD64. 2021-08-23 08:27:08 +02:00
linux1
0c9e23c7ce Fix: appeased x.py test tidy --bless 2021-08-22 17:55:03 -04:00
linux1
eeb0b52bf8 Feat: further testing & support for i64 general register use 2021-08-22 17:55:03 -04:00
linux1
5f5afba5fb Feat: added s390x reg-definitions, constraint codes, and tests 2021-08-22 17:55:03 -04:00
linux1
f28793dd13 Feat: added inline asm support for s390x 2021-08-22 17:55:03 -04:00
Andreas Liljeqvist
5a501f73ff Use custom wrap-around type instead of Range 2021-08-22 21:46:03 +02:00
Guillaume Gomez
c6da5b08e0
Rollup merge of - kit-981:feature/fix-minimum-os-version-in-header, r=petrochenkov
Generate an iOS LLVM target with a specific version

This commit adds the `LC_VERSION_MIN_IPHONEOS` load command to the Mach-O header generated for `aarch64-apple-ios` binaries. The operating system will look for this load command to determine the minimum supported operating system version and will not allow the binary to run if it's absent. This logic already exists for the simulator toolchain.

I've been using `otool` from a [cctools](https://github.com/tpoechtrager/cctools-port) toolchain to parse the header and validate that this change adds the required load command.

This change appears to be enough to build Rust binaries that can run on a jailbroken iPhone.
2021-08-22 20:52:52 +02:00
Frank Steffahn
bf88b113ea Fix typos “a”→“an” 2021-08-22 15:35:11 +02:00
bors
db002a06ae Auto merge of - nikic:llvm-13, r=nagisa
Upgrade to LLVM 13

Work in progress update to LLVM 13. Main changes:

 * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler.
 * Codegen tests are updated for additional attributes.
 * Some data layouts have changed.
 * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448, which appears to trigger a bug in older versions of gold.
 * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement.

Upstream issues:

 * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by 1558bb80c0.
 * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by 81b106584f.
 * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork, https://reviews.llvm.org/D107216 posted for upstream revert.
 * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for ). This is an optimization regression that we may likely have to eat for this release. The fix for  was based on an incorrect premise, and this needs to be properly addressed in the MergeICmps pass.

The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed, but quite positive as LLVM upgrades go.

The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st.

r? `@ghost`
2021-08-21 09:25:28 +00:00
bors
20e92344bc Auto merge of - devnexen:fbsd_arm64, r=nagisa
freebsd arm64 add supported sanitizers.
2021-08-19 11:54:27 +00:00
Nikita Popov
b5cc03b71a Update powerpc64 data layout 2021-08-16 18:28:18 +02:00
Nikita Popov
6eaf227ce1 Update wasm data layout 2021-08-16 18:28:18 +02:00
kit
13e2f807a1 Generate an iOS LLVM target with a specific version
Without the specific version, the mach-o header will be missing the
minimum supported operating system version. This is mandatory for
running Rust binaries on iOS devices.
2021-08-16 17:31:37 +10:00
bors
85109e257a Auto merge of - Amanieu:asm_clobber_abi, r=nagisa
Add support for clobber_abi to asm!

This PR adds the `clobber_abi` feature that was proposed in .

Fixes 

cc `@rust-lang/wg-inline-asm`

r? `@nagisa`
2021-08-14 22:29:27 +00:00
DC
df751d82c8 freebsd arm64 add supported sanitizers. 2021-08-14 10:37:07 +01:00
Manish Goregaokar
692833a28f
Rollup merge of - Manishearth:c-enum-target-spec, r=nagisa,eddyb
Add c_enum_min_bits target spec field, use for arm-none and thumb-none targets

Fixes https://github.com/rust-lang/rust/issues/87917

<s>Haven't tested this yet, still playing around.</s>

This seems to fix the issue.
2021-08-12 10:04:14 -07:00
Manish Goregaokar
4c0e424461 Apply c_enum_min_bits = 8 to (arm|thumb)-none- platforms 2021-08-12 09:44:16 -07:00
Manish Goregaokar
fd116c806a Add c_enum_min_bits to target spec 2021-08-12 09:44:16 -07:00
Amanieu d'Antras
3fd463a5ca Add support for clobber_abi to asm! 2021-08-12 12:43:11 +01:00
ivmarkov
459eaa6bae STD support for the ESP-IDF framework 2021-08-10 12:09:00 +03:00
bors
ae90dcf020 Auto merge of - Andy-Python-Programmer:aarch64_uefi_target, r=petrochenkov
Add `aarch64-unknown-uefi` target

This pull request adds the `aarch64-unknown-uefi` target.
2021-08-09 13:16:51 +00:00
unknown
44b81fb8fc
Add the aarch64-unknown-uefi target
* This commit adds the aarch64-unknown-uefi target and also adds it into
the supported targets list under the tier-3 target table.
* Uses the small code model by default

Signed-off-by: Andy-Python-Programmer <andypythonappdeveloper@gmail.com>
2021-08-09 16:49:04 +10:00
bors
b53a93db2d Auto merge of - lf-:authors, r=Mark-Simulacrum
rfc3052 followup: Remove authors field from Cargo manifests

Since RFC 3052 soft deprecated the authors field, hiding it from
crates.io, docs.rs, and making Cargo not add it by default, and it is
not generally up to date/useful information for contributors, we may as well
remove it from crates in this repo.
2021-08-02 05:49:17 +00:00
bors
2e9c8705e9 Auto merge of - devnexen:netbsd_sanitizers_support, r=nagisa
netbsd x86_64 arch enable supported sanitizers.
2021-08-01 14:16:37 +00:00
bors
aadd6189ad Auto merge of - matthiaskrgr:clippyy_v2, r=nagisa
more clippy::complexity fixes

(also a couple of clippy::perf fixes)
2021-08-01 09:15:15 +00:00
David Carlier
4258e937f6 netbsd x86_64 arch enable supported sanitizers. 2021-07-31 15:26:55 +01:00
Jade
3cf820e17d rfc3052: Remove authors field from Cargo manifests
Since RFC 3052 soft deprecated the authors field anyway, hiding it from
crates.io, docs.rs, and making Cargo not add it by default, and it is
not generally up to date/useful information, we should remove it from
crates in this repo.
2021-07-29 14:56:05 -07:00
David Carlier
76d1453b5b freebsd remove compiler workaround.
related issue 
2021-07-25 17:38:44 +01:00
Matthias Krüger
3fd8cbb404 clippy::useless_format 2021-07-25 12:26:03 +02:00
Piotr Kubaj
763bc13ccc Add support for powerpc-unknown-freebsd 2021-07-22 17:29:33 +02:00
bors
64d171b8a4 Auto merge of - Andy-Python-Programmer:code_model_uefi_patch, r=petrochenkov
Use small code model for UEFI targets

* Since the code model only applies to the code and not the data and the code model
only applies to functions you call through using `call`, `jmp` and data with `lea`, etc…

  If you are calling functions using the function pointers from the UEFI structures the code
  model does not apply in that case. It’s just related to the address space size of your own binary.
  Since UEFI (uefi is all relocatable) uses relocatable PEs (relocatable code does not care about the
  code model) so, we use the small code model here.

* Since applications don't usually take gigabytes of memory, setting the
target to use the small code model should result in better codegen (comparable
with majority of other targets).

  Large code models are also known for generating horrible code, for
  example 16 bytes of code to load a single 8-byte value.

Signed-off-by: Andy-Python-Programmer <andypythonappdeveloper@gmail.com>
2021-07-17 10:15:33 +00:00
bors
153df0f6ef Auto merge of - nagisa:nagisa/what-a-lie, r=estebank
Do not allow JSON targets to set is-builtin: true

Note that this will affect (and make builds fail for) all of the projects out there that have target files invalid in this way. Crater, however, does not really cover these kinds of the codebases, so it is quite difficult to measure the impact. That said, the target files invalid in this way can start causing build failures each time LLVM is upgraded, anyway, so it is probably a good opportunity to disallow this property, entirely.

Another approach considered was to simply not parse this field anymore, which would avoid making the builds explicitly fail, but it wasn't clear to me if `is-builtin` was always set unintentionally… In case this was the case, I'd expect people to file a feature request stating specifically for what purpose they were using `is-builtin`.

Fixes 
2021-07-17 07:54:03 +00:00
Andy-Python-Programmer
db1e49257e
Use small code model for UEFI targets
* Since the code model only applies to the code and not the data and the code model
only applies to functions you call through using `call`, `jmp` and data with `lea`, etc…

If you are calling functions using the function pointers from the UEFI structures the code
model does not apply in that case. It’s just related to the address space size of your own binary.
Since UEFI (uefi is all relocatable) uses relocatable PEs (relocatable code does not care about the
code model) so, we use the small code model here.

* Since applications don't usually take gigabytes of memory, setting the
target to use the small code model should result in better codegen (comparable
with majority of other targets).

Large code models are also known for generating horrible code, for
example 16 bytes of code to load a single 8-byte value.

* Use the LLVM default code model for the architecture for the
x86_64-unknown-uefi targets. For reference small is the default
code model on x86 in LLVM: <7de2173c2a/llvm/lib/Target/X86/X86TargetMachine.cpp (L204)>

* Remove the comments too as they are not UEFI-specific and applies
to pretty much any target. I added them before as I was explicitily
setting the code model to small.

Signed-off-by: Andy-Python-Programmer <andypythonappdeveloper@gmail.com>
2021-07-17 14:08:40 +10:00
bors
ca99e3eb3a Auto merge of - joshtriplett:target-abi, r=oli-obk
target abi

Implement cfg(target_abi) (RFC 2992)

Add an `abi` field to `TargetOptions`, defaulting to "". Support using
`cfg(target_abi = "...")` for conditional compilation on that field.

Gated by `feature(cfg_target_abi)`.

Add a test for `target_abi`, and a test for the feature gate.

Add `target_abi` to tidy as a platform-specific cfg.

Update targets to use `target_abi`

All eabi targets have `target_abi = "eabi".`
All eabihf targets have `target_abi = "eabihf"`.
`armv6_unknown_freebsd` and `armv7_unknown_freebsd` have `target_abi = "eabihf"`.
All abi64 targets have `target_abi = "abi64"`.
All ilp32 targets have `target_abi = "ilp32"`.
All softfloat targets have `target_abi = "softfloat"`.
All *-uwp-windows-* targets have `target_abi = "uwp"`.
All spe targets have `target_abi = "spe"`.
All macabi targets have `target_abi = "macabi"`.
aarch64-apple-ios-sim has `target_abi = "sim"`.
`x86_64-fortanix-unknown-sgx` has `target_abi = "fortanix"`.
`x86_64-unknown-linux-gnux32` has `target_abi = "x32"`.

Add FIXME entries for targets for which existing values need to change
once `cfg_target_abi` becomes stable. (All of them are tier 3 targets.)

Add a test for `target_abi` in `--print cfg`.
2021-07-13 12:25:10 +00:00
bors
99f8efec46 Auto merge of - Amanieu:asm_clobber_only, r=nagisa
Add clobber-only register classes for asm!

These are needed to properly express a function call ABI using a clobber
list, even though we don't support passing actual values into/out of
these registers.
2021-07-11 01:06:58 +00:00
Amanieu d'Antras
d2a1d048d9 Add AArch64 z* registers as aliases for v* registers 2021-07-10 17:29:07 +02:00
Amanieu d'Antras
e1c3f5e017 Add clobber-only register classes for asm!
These are needed to properly express a function call ABI using a clobber
list, even though we don't support passing actual values into/out of
these registers.
2021-07-10 17:29:00 +02:00
Simonas Kazlauskas
f4701cd65c Do not allow JSON targets to set is-builtin: true 2021-07-08 23:50:12 +03:00
Josh Triplett
c3fbafddc0 Update targets to use target_abi
All eabi targets have target_abi = "eabi".
All eabihf targets have target_abi = "eabihf".
armv6_unknown_freebsd and armv7_unknown_freebsd have target_abi = "eabihf".
All abi64 targets have target_abi = "abi64".
All ilp32 targets have target_abi = "ilp32".
All softfloat targets have target_abi = "softfloat".
All *-uwp-windows-* targets have target_abi = "uwp".
All spe targets have target_abi = "spe".
All macabi targets have target_abi = "macabi".
aarch64-apple-ios-sim has target_abi = "sim".
x86_64-fortanix-unknown-sgx has target_abi = "fortanix".
x86_64-unknown-linux-gnux32 has target_abi = "x32".

Add FIXME entries for targets for which existing values need to change
once cfg_target_abi becomes stable. (All of them are tier 3 targets.)

Add a test for target_abi in `--print cfg`.
2021-07-07 08:52:35 -07:00
Josh Triplett
84d6e8aed3 Implement cfg(target_abi) (RFC 2992)
Add an `abi` field to `TargetOptions`, defaulting to "". Support using
`cfg(target_abi = "...")` for conditional compilation on that field.

Gated by `feature(cfg_target_abi)`.

Add a test for `target_abi`, and a test for the feature gate.

Add `target_abi` to tidy as a platform-specific cfg.

This does not add an abi to any existing target.
2021-07-07 08:52:35 -07:00
Simonas Kazlauskas
8240e7aa10 Replace per-target ABI denylist with an allowlist
It makes very little sense to maintain denylists of ABIs when, as far as
non-generic ABIs are concerned, targets usually only support a small
subset of the available ABIs.

This has historically been a cause of bugs such as us allowing use of
the platform-specific ABIs on x86 targets – these in turn would cause
LLVM errors or assertions to fire.

Fixes 

Sponsored by: standard.ai
2021-07-06 13:12:15 +03:00
Simonas Kazlauskas
9b67cba4f6 Add support for leaf fn frame pointer elimination
This PR adds ability for the target specifications to specify frame
pointer emission type that's not just “always” or “whatever cg decides”.

In particular there's a new mode that allows omission of the frame
pointer for leaf functions (those that don't call any other functions).

We then set this new mode for Aarch64-based Apple targets.

Fixes 
2021-06-30 19:45:17 +03:00
Smitty
157898e7d5 Point to the updated version of some dead links 2021-06-23 19:36:51 -04:00
Smitty
bdfcb88e8b Use HTTPS links where possible 2021-06-23 16:26:46 -04:00
bors
d789de67dc Auto merge of - adamrk:warn-unused-target-fields, r=nagisa
Emit warnings for unused fields in custom targets.

Add a warning which lists any fields in a custom target `json` file that aren't used. Currently unrecognized fields are ignored so, for example, a typo in the `json` will silently produce a target which isn't the one intended.
2021-06-21 06:56:51 +00:00
Adam Bratschi-Kaye
88b01f1178 Emit warnings for unused fields in custom targets. 2021-06-17 21:48:02 +02:00
bors
e062e5d34e Auto merge of - pkubaj:patch-1, r=nagisa
Add support for powerpc64le-unknown-freebsd
2021-06-17 18:06:44 +00:00
LeSeulArtichaut
e3ca81fd5a Use the now available implementation of IntoIterator for arrays 2021-06-14 23:40:09 +02:00
LingMan
07dbd4d398 Use try_into instead of asserting manually 2021-06-07 01:27:40 +02:00
Yuki Okushi
679a1d1ac1
Rollup merge of - luqmana:wasm-linker-tweaks, r=petrochenkov
Tweak wasm_base target spec to indicate linker is not GNU and update linker inferring logic for wasm-ld.

Reported via [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/wasi.20linker.20unknown.20argument.3A.20--as-needed): we try passing `--as-needed` to the linker if it's GNU ld which `wasm-ld` is not. Usually this isn't an issue for wasm as we would use the WasmLd linker driver but because the linker in question (`wasm32-unknown-wasi-wasm-ld`) ended with `-ld` our linker inferring [logic](f64503eb55/compiler/rustc_codegen_ssa/src/back/link.rs (L957-L1040)) used the `GccLinker` implementations. (UPD: The linker inferring logic actually didn't apply in this case because the linker is actually invoked through gcc in the reported issue. But it's still worth updating the logic I think.)

This change then has 2 parts:
1. Update wasm_base target spec to indicate `linker_is_gnu: false` plus a few additions of `target.is_like_wasm` to handle flags `wasm-ld` does in fact support.
2. Improve the linker detection logic to properly determine the correct flavor of wasm linker we're using when we can.

We need to add the new `target.is_like_wasm` branches to handle the case where the "linker" used could be something like clang which would then under the hood call wasm-ld.
2021-06-06 19:11:18 +09:00
bors
f434217aab Auto merge of - alessandrod:bpf, r=nagisa
BPF target support

This adds `bpfel-unknown-none` and `bpfeb-unknown-none`, two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target, where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker.

I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.
2021-06-06 01:02:32 +00:00
Guillaume Gomez
16504f6253
Rollup merge of - cr1901:msp430-link, r=jonas-schievink
msp430 linker does not accept -znoexecstack. Set linker_is_gnu to fal…

…se as workaround for now.

Tested locally and works. Closes .
2021-06-05 19:41:45 +02:00
William D. Jones
cd11cdb88c msp430 linker does not accept -znoexecstack. Set linker_is_gnu to false as workaround for now. 2021-06-04 20:37:53 -04:00
Yuki Okushi
5d30ab85b2
Rollup merge of - alexcrichton:wasm-simd-indirect, r=workingjubilee
wasm: Make simd types passed via indirection again

This commit updates wasm target specs to use `simd_types_indirect: true`
again. Long ago this was added since wasm simd types were always
translated to `v128` under-the-hood in LLVM, meaning that it didn't
matter whether that target feature was enabled or not. Now, however,
`v128` is conditionally used in codegen depending on target features
enabled, meaning that it's possible to get linker errors about different
signatures in code that correctly uses simd types. The fix is the same
as for all other platforms, which is to pass the type indirectly.
2021-06-05 06:13:43 +09:00
Yuki Okushi
36f1ed6de2
Rollup merge of - bjorn3:less_feature_gates, r=jyn514
Remove unused feature gates

The first commit removes a usage of a feature gate, but I don't expect it to be controversial as the feature gate was only used to workaround a limitation of rust in the past. (closures never being `Clone`)

The second commit uses `#[allow_internal_unstable]` to avoid leaking the `trusted_step` feature gate usage from inside the index newtype macro. It didn't work for the `min_specialization` feature gate though.

The third commit removes (almost) all feature gates from the compiler that weren't used anyway.
2021-06-04 13:42:54 +09:00
Alex Crichton
55769a5ca9 wasm: Make simd types passed via indirection again
This commit updates wasm target specs to use `simd_types_indirect: true`
again. Long ago this was added since wasm simd types were always
translated to `v128` under-the-hood in LLVM, meaning that it didn't
matter whether that target feature was enabled or not. Now, however,
`v128` is conditionally used in codegen depending on target features
enabled, meaning that it's possible to get linker errors about different
signatures in code that correctly uses simd types. The fix is the same
as for all other platforms, which is to pass the type indirectly.
2021-06-03 09:55:45 -07:00
Yuki Okushi
9b1e105ade
Rollup merge of - jrmuizel:fpe, r=nagisa
Turn off frame pointer elimination on all Apple platforms.

This ends up disabling frame pointer elimination on aarch64_apple_darwin
which matches what clang does by default along with the
aarch64_apple_ios and x86_64_apple_darwin targets.

Further, the Apple docs "Writing ARM64 Code for Apple Platforms" has a section
called "Respect the Purpose of Specific CPU Registers" which
specifically calls out the frame pointer register (x29):

   The frame pointer register (x29) must always address a valid frame
   record. Some functions — such as leaf functions or tail calls — may
   opt not to create an entry in this list As a result, stack traces
   are always meaningful, even without debug information.

Other platforms are updated to not override the default.
2021-06-03 14:35:28 +09:00
Jeff Muizelaar
aab854596f Turn off frame pointer elimination on all Apple platforms.
This ends up disabling frame pointer elimination on aarch64_apple_darwin
which matches what clang does by default along with the
aarch64_apple_ios and x86_64_apple_darwin targets.

Further, the Apple docs "Writing ARM64 Code for Apple Platforms" has a section
called "Respect the Purpose of Specific CPU Registers" which
specifically calls out the frame pointer register (x29):

   The frame pointer register (x29) must always address a valid frame
   record. Some functions — such as leaf functions or tail calls — may
   opt not to create an entry in this list As a result, stack traces
   are always meaningful, even without debug information.

Other platforms are updated to not override the default.
2021-06-02 13:49:29 -04:00
Tomasz Miąsko
c1f6495b8e Miscellaneous inlining improvements 2021-06-02 08:49:58 +02:00
Luqman Aden
f667aca127 Tweak wasm_base target spec to indicate linker is not GNU and update linker inferring logic for wasm-ld. 2021-06-01 17:13:10 -07:00
bjorn3
312f964478 Remove unused feature gates 2021-05-31 13:55:43 +02:00
Alessandro Decina
ab93a139ef BPF: misc minor review fixes 2021-05-29 22:23:32 +10:00
Alessandro Decina
bd8e5ce4b9 BPF: abi: extend args/ret to 32 bits
Let LLVM extend to 64 bits when alu32 is not enabled
2021-05-29 22:23:32 +10:00
Jacob Pratt
bc2f0fb5a9
Specialize implementations
Implementations in stdlib are now optimized as they were before.
2021-05-26 18:07:09 -04:00
Alessandro Decina
b2a6967114 Add support for BPF inline assembly 2021-05-23 18:03:27 +10:00
Alessandro Decina
12e70929d6 Add BPF target
This change adds the bpfel-unknown-none and bpfeb-unknown-none targets
which can be used to generate little endian and big endian BPF
2021-05-23 18:03:27 +10:00
Luqman Aden
3221a5e65b Remove linker_is_gnu: true cases as that is now the default. 2021-05-20 23:36:04 -07:00
Luqman Aden
0188664425 Swap TargetOptions::linker_is_gnu default from false to true and update targets as appropriate. 2021-05-20 16:47:08 -07:00
bors
3e827cc21e Auto merge of - RalfJung:ptrless-allocs, r=oli-obk
CTFE core engine allocation & memory API improvemenets

This is a first step towards https://github.com/rust-lang/miri/issues/841.
- make `Allocation` API offset-based (no more making up `Pointer`s just to access an `Allocation`)
- make `Memory` API higher-level (combine checking for access and getting access into one operation)

The Miri-side PR is at https://github.com/rust-lang/miri/pull/1804.
r? `@oli-obk`
2021-05-19 10:11:28 +00:00
Jack Huey
ec0e0d1e7a
Rollup merge of - luqmana:linker-is-gnu-gc-sections, r=petrochenkov
Only pass --[no-]gc-sections if linker is GNU ld.

Fixes a regression from  where linking now fails with solaris linkers. LinkerFlavor::Gcc does not always mean GNU ld specifically. And in the case of at least the solaris ld in illumos, that flag is unrecognized and will cause the linking step to fail.

Even though removing the `is_like_solaris` branch from `gc_sections` in  made sense as `-z ignore/record` are more analogous to the `--[no-]-as-needed` flags, it inadvertently caused solaris linkers to be passed the `--gc-sections` flag. So let's just change it to be more explicit about when we pass those flags.
2021-05-18 22:36:04 -04:00
Ralf Jung
563ab4a106 add Align::ONE; add methods to access alloc.extra 2021-05-18 19:33:55 +02:00
bors
fe72845f7b Auto merge of - ehuss:macro_use-unused-attr, r=petrochenkov
Fix unused attributes on macro_rules.

The `unused_attributes` lint wasn't firing on attributes of `macro_rules` definitions. The consequence is that many attributes are silently ignored on `macro_rules`. The reason is that `unused_attributes` is a late-lint pass, and only has access to the HIR, which does not have macro_rules definitions.

My solution here is to change `non_exported_macro_attrs` to be `macro_attrs` (a list of all attributes used for `macro_rules`, instead of just those for `macro_export`), and then to check this list in the `unused_attributes` lint. There are a number of alternate approaches, but this seemed the most reliable and least invasive. I am open to completely different approaches, though.

One concern is that I don't fully understand the implications of extending `non_exported_macro_attrs` to include non-exported macros. That list was originally added in  to handle stability attributes, so I suspect it was just an optimization since that was all that was needed. It was later extended to be included in SVH in .  also added a use to check for `invalid` attributes, which seems a little odd to me (it didn't validate non-exported macros, and seems highly specific).

Overall, there doesn't seem to be a clear story of when `unused_attributes` should be used versus an error like E0518. I considered alternatively using an "allow list" of built-in attributes that can be used on macro_rules (allow, warn, deny, forbid, cfg, cfg_attr, macro_export, deprecated, doc), but I feel like that could be a pain to maintain.

Some built-in attributes already present hard-errors when used with macro_rules. These are each hard-coded in various places:
- `derive`
- `test` and `bench`
- `proc_macro` and `proc_macro_derive`
- `inline`
- `global_allocator`

The primary motivation is that I sometimes see people use `#[macro_use]` in front of `macro_rules`, which indicates there is some confusion out there (evident that there was even a case of it in rustc).
2021-05-16 20:19:45 +00:00
Luqman Aden
45225d24bf Windows mingw targets use gcc as the linker so the target spec should also indicate linker_is_gnu. 2021-05-15 22:09:34 -07:00
Eric Huss
5bbc240ffb Fix unused attributes on macro_rules. 2021-05-15 16:13:46 -07:00
Dr. Chat
69acee3ffe Add asm!() support for PowerPC64 2021-05-13 22:31:47 -05:00
Dr. Chat
b1bb5d662c Add initial asm!() support for PowerPC
This includes GPRs and FPRs only
2021-05-11 19:04:16 -05:00
Simonas Kazlauskas
b7c5599d22 Adjust target search algorithm for rustlib path
With this the concerns expressed in  should be addressed.
2021-05-10 19:15:19 +03:00
bors
c55c26cb36 Auto merge of - xobs:impl-16351-nightly, r=nagisa
Add default search path to `Target::search()`

The function `Target::search()` accepts a target triple and returns a `Target` struct defining the requested target.

There is a `// FIXME 16351: add a sane default search path?` comment that indicates it is desirable to include some sort of default. This was raised in https://github.com/rust-lang/rust/issues/16351 which was closed without any resolution.

https://github.com/rust-lang/rust/pull/31117 was proposed, however that has platform-specific logic that is unsuitable for systems without `/etc/`.

This patch implements the suggestion raised in https://github.com/rust-lang/rust/issues/16351#issuecomment-180878193 where a `target.json` file may be placed in `$(rustc --print sysroot)/lib/rustlib/<target-triple>/target.json`. This allows shipping a toolchain distribution as a single file that gets extracted to the sysroot.
2021-05-09 22:01:26 +00:00
Dylan DPC
cea6e4d6b9
Rollup merge of - hermitcore:target, r=nagisa
rename LLVM target for RustyHermit

- RustyHermit is a library operating system, where the user-
  and the kernel-space use the same target
- by a mistake a previous patch changes the target to an incorect value
- this merge request revert the previous changes
2021-05-07 16:19:21 +02:00
Stefan Lankes
76f884abb9 rename LLVM target for RustyHermit
RustyHermit ist is a library operating system. In this case, we link a static library as kernel to the application. The final result is a bootable application. The library and the application have to use the same target. Currently, the targets are different (see also https://github.com/rust-lang/rust/blob/master/compiler/rustc_target/src/spec/x86_64_unknown_hermit.rs). Consequently, this commit change the LLVM target to 'hermit'.

This kernel spec is needed to disable the usage of FPU registers, which are not allowed in kernel space. In contrast to Linux, everything is running in ring 0 and also in the same address space.

Signed-off-by: Stefan Lankes <slankes@eonerc.rwth-aachen.de>
2021-05-07 10:09:11 +02:00
Joshua M. Clulow
31c2ad0d4c illumos should put libc last in library search order
Under some conditions, the toolchain will produce a sequence of linker
arguments that result in a NEEDED list that puts libc before libgcc_s;
e.g.,

    [0]  NEEDED            0x2046ba            libc.so.1
    [1]  NEEDED            0x204723            libm.so.2
    [2]  NEEDED            0x204736            libsocket.so.1
    [3]  NEEDED            0x20478b            libumem.so.1
    [4]  NEEDED            0x204763            libgcc_s.so.1

Both libc and libgcc_s provide an unwinder implementation, but libgcc_s
provides some extra symbols upon which Rust directly depends.  If libc
is first in the NEEDED list we will find some of those symbols in libc
but others in libgcc_s, resulting in undefined behaviour as the two
implementations do not use compatible interior data structures.

This solution is not perfect, but is the simplest way to produce correct
binaries on illumos for now.
2021-05-06 17:08:10 -07:00
Dylan DPC
966e9e2471
Rollup merge of - nagisa:target-family-two-the-movie, r=petrochenkov
Allow setting `target_family` to multiple values, and implement `target_family="wasm"`

As per the conclusion in [this thread](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Are.20we.20comfortable.20with.20adding.20an.20insta-stable.20cfg.28wasm.29.3F/near/233158441), this implements an ability to specify any number of `target_family` values, allowing for more flexible generic groups, or "families", to be created than just the OS-based unix/windows dichotomy.

cc https://github.com/rust-lang/reference/pull/1006
2021-05-03 00:32:40 +02:00
Simonas Kazlauskas
1a491e2304 Set target_family="wasm" for wasm targets 2021-05-03 00:32:44 +03:00
bors
603a42ec54 Auto merge of - Amanieu:reserved_regs, r=petrochenkov
Be stricter about rejecting LLVM reserved registers in asm!

LLVM will silently produce incorrect code if these registers are used as operands.

cc `@rust-lang/wg-inline-asm`
2021-05-01 13:01:24 +00:00
Amanieu d'Antras
ea310d9253 Reserve x18 on AArch64 and un-reserve x16 2021-05-01 13:25:56 +01:00
Felix S. Klock II
8d1083e319 Change to probe-stack=call (instead of inline-or-call) everywhere again, for now.
We had already reverted the change on stable back in PR .

Since then, we've had some movement on issue , but not a 100% fix.

But also since then, we had bug reported, issue , that looks like outright
codegen breakage, rather than problems confined to debuginfo issues.

So we are reverting PR  on stable and beta. We'll reland PR  (or some
variant) switching back to an LLVM-dependent selection of out-of-line call vs
inline-asm, after these other issues have been resolved.
2021-04-29 15:13:21 -04:00
Amanieu d'Antras
e6a731eb90 Be stricter about rejecting LLVM reserved registers in asm! 2021-04-28 18:30:36 +01:00
bors
b56b175c6c Auto merge of - RalfJung:const-fn-feature-flags, r=oli-obk
further split up const_fn feature flag

This continues the work on splitting up `const_fn` into separate feature flags:
* `const_fn_trait_bound` for `const fn` with trait bounds
* `const_fn_unsize` for unsizing coercions in `const fn` (looks like only `dyn` unsizing is still guarded here)

I don't know if there are even any things left that `const_fn` guards... at least libcore and liballoc do not need it any more.

`@oli-obk` are you currently able to do reviews?
2021-04-24 23:16:03 +00:00
Sean Cross
f9d390d14a Merge remote-tracking branch 'upstream/master' into impl-16351-nightly
Signed-off-by: Sean Cross <sean@xobs.io>
2021-04-25 00:35:25 +08:00
bors
e888a57da8 Auto merge of - klensy:typo-compiler, r=jyn514
fix few typos in comments
2021-04-20 00:16:45 +00:00
Dylan DPC
3b81ea86fb
Rollup merge of - 12101111:musl-sanitizer, r=davidtwco
Enable sanitizers for x86_64-unknown-linux-musl

Those 4 sanitizers get musl target support in LLVM 12 release.
2021-04-19 22:00:04 +02:00
klensy
f43ee8ebf6 fix few typos 2021-04-19 15:57:08 +03:00
Ralf Jung
bd9556956a fix feature use in rustc libs 2021-04-18 22:05:45 +02:00
pkubaj
a2f532de21
Replace get_mut(& with entry( for powerpc64le-unknown-freebsd 2021-04-14 08:54:11 +00:00
pkubaj
43a2b1abf1
Switch powerpc64le-unknown-freebsd to or_default() 2021-04-14 00:15:38 +00:00
LingMan
28aed81f7d Avoid an Option<Option<_>>
By simply swapping the calls to `map` and `and_then` around the complexity of
handling an `Option<Option<_>>` disappears.
2021-04-13 18:42:19 +02:00
Simonas Kazlauskas
4afea69090 Allow setting target_family to multiple values
This enables us to set more generic labels shared between targets. For
example `target_family="wasm"` across all targets that are conceptually
"wasm".

See https://github.com/rust-lang/reference/pull/1006
2021-04-11 01:18:38 +03:00
12101111
7cd0a4d352
Enable sanitizers for x86_64-unknown-linux-musl 2021-04-09 23:22:17 +08:00
bors
2e495d2e84 Auto merge of - Dylan-DPC:rollup-invxvg8, r=Dylan-DPC
Rollup of 6 pull requests

Successful merges:

 -  (Improve links in inline code in `core::pin`.)
 -  (Stabilize `rustdoc::bare_urls` lint)
 -  (Stabilize `peekable_peek_mut`)
 -  (Fix outdated crate names in compiler docs)
 -  (Merge idents when generating source content)
 -  (Update Clippy)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2021-04-08 19:38:54 +00:00
pierwill
0019ca9141 Fix outdated crate names in compiler docs
Changes `librustc_X` to `rustc_X`, only in documentation comments.
Plain code comments are left unchanged.

Also fix incorrect file paths.
2021-04-08 11:12:14 -05:00
Alex Crichton
482a3d06c3 rustc: Add a new wasm ABI
This commit implements the idea of a new ABI for the WebAssembly target,
one called `"wasm"`. This ABI is entirely of my own invention
and has no current precedent, but I think that the addition of this ABI
might help solve a number of issues with the WebAssembly targets.

When `wasm32-unknown-unknown` was first added to Rust I naively
"implemented an abi" for the target. I then went to write `wasm-bindgen`
which accidentally relied on details of this ABI. Turns out the ABI
definition didn't match C, which is causing issues for C/Rust interop.
Currently the compiler has a "wasm32 bindgen compat" ABI which is the
original implementation I added, and it's purely there for, well,
`wasm-bindgen`.

Another issue with the WebAssembly target is that it's not clear to me
when and if the default C ABI will change to account for WebAssembly's
multi-value feature (a feature that allows functions to return multiple
values). Even if this does happen, though, it seems like the C ABI will
be guided based on the performance of WebAssembly code and will likely
not match even what the current wasm-bindgen-compat ABI is today. This
leaves a hole in Rust's expressivity in binding WebAssembly where given
a particular import type, Rust may not be able to import that signature
with an updated C ABI for multi-value.

To fix these issues I had the idea of a new ABI for WebAssembly, one
called `wasm`. The definition of this ABI is "what you write
maps straight to wasm". The goal here is that whatever you write down in
the parameter list or in the return values goes straight into the
function's signature in the WebAssembly file. This special ABI is for
intentionally matching the ABI of an imported function from the
environment or exporting a function with the right signature.

With the addition of a new ABI, this enables rustc to:

* Eventually remove the "wasm-bindgen compat hack". Once this
  ABI is stable wasm-bindgen can switch to using it everywhere.
  Afterwards the wasm32-unknown-unknown target can have its default ABI
  updated to match C.

* Expose the ability to precisely match an ABI signature for a
  WebAssembly function, regardless of what the C ABI that clang chooses
  turns out to be.

* Continue to evolve the definition of the default C ABI to match what
  clang does on all targets, since the purpose of that ABI will be
  explicitly matching C rather than generating particular function
  imports/exports.

Naturally this is implemented as an unstable feature initially, but it
would be nice for this to get stabilized (if it works) in the near-ish
future to remove the wasm32-unknown-unknown incompatibility with the C
ABI. Doing this, however, requires the feature to be on stable because
wasm-bindgen works with stable Rust.
2021-04-08 08:03:18 -07:00
Vadim Petrochenkov
e7e485cf51 rustc_target: Rely on defaults more in target specs 2021-04-05 23:12:56 +03:00
Dylan DPC
49b178e9ff
Rollup merge of - Amanieu:asm_no_high_x86_64, r=nagisa
Disallow the use of high byte registes as operands on x86_64

They are still allowed on x86 though.

Fixes 

r? `@nagisa`
2021-04-05 15:48:43 +02:00
Amanieu d'Antras
b1bcff0731 Disallow the use of high byte registes as operands on x86_64
They are still allowed on x86 though.

Fixes 
2021-04-05 13:38:24 +01:00
Dylan DPC
0d12422f2d
Rollup merge of - devsnek:wasm64, r=nagisa
wasm64 support

There is still some upstream llvm work needed before this can land.
2021-04-05 00:24:23 +02:00
Gus Caplan
da66a31572
wasm64 2021-04-04 11:29:34 -05:00
Sean Cross
8f73fe91f5 compiler: run python3 ./x.py fmt
This fixes a build issue with formatting as part of .

Signed-off-by: Sean Cross <sean@xobs.io>
2021-04-03 15:00:10 +08:00
Sean Cross
6f1ac8d756 rustc: target: add sysroot to rust_target_path
This enables placing a `target.json` file into the rust sysroot under
the target-specific directory.

Signed-off-by: Sean Cross <sean@xobs.io>
2021-04-03 14:39:40 +08:00
Simonas Kazlauskas
a3c0f0a3df (De-)serialize the supported_sanitizers 2021-04-03 00:37:49 +03:00
Simonas Kazlauskas
16c1d0ae06 Maintain supported sanitizers as a target property
This commit adds an additional target property – `supported_sanitizers`,
and replaces the hardcoded allowlists in argument parsing to use this
new property.

Fixes 
2021-04-03 00:37:49 +03:00
Simonas Kazlauskas
64af7eae1e Move SanitizerSet to rustc_target 2021-04-03 00:37:49 +03:00
Vadim Petrochenkov
cc5392e76b linker: Use data execution prevention options by default when linker supports them 2021-03-28 23:44:40 +03:00
bors
505ed7fb1b Auto merge of - petrochenkov:nounwrap, r=nagisa
rustc_target: Avoid unwraps when adding linker flags

These `unwrap`s assume that some linker flags were already added by `*_base::opts()` methods, but that's doesn't necessarily remain the case when we are reducing the number of flags hardcoded in targets, as https://github.com/rust-lang/rust/pull/83587 shows.

r? `@nagisa`
2021-03-28 08:53:51 +00:00
Vadim Petrochenkov
049a49b911 rustc_target: Avoid unwraps when adding linker flags 2021-03-28 02:28:48 +03:00
Vadim Petrochenkov
6615ee89be linker: Use --as-needed by default when linker supports it 2021-03-28 01:49:15 +03:00
Piotr Kubaj
24152ec296 Add support for powerpc64le-unknown-freebsd. 2021-03-27 17:02:06 +01:00
hyd-dev
f900ee331d
Allow not emitting uwtable on Android 2021-03-23 04:39:58 +08:00
Nikita Popov
dfc4cafe8e Move decision aboute noalias into codegen_llvm
The frontend shouldn't be deciding whether or not to use mutable
noalias attributes, as this is a pure LLVM concern. Only provide
the necessary information and do the actual decision in
codegen_llvm.
2021-03-21 20:10:53 +01:00
Justin Restivo
9a3e23fed2 riscvgc-unknown-none-elf use lp64d ABI 2021-03-17 10:45:58 -04:00
Amanieu d'Antras
ba00ddc39a Address review comments 2021-03-14 23:21:03 +00:00
Amanieu d'Antras
fa3694fada Always lower asm! to valid HIR 2021-03-13 20:49:32 +00:00
bors
f98721f886 Auto merge of - Dylan-DPC:rollup-mt497z7, r=Dylan-DPC
Rollup of 9 pull requests

Successful merges:

 -  (always eagerly eval consts in Relate)
 -  (Edition-specific preludes)
 -  (rustdoc: Remove redundant enableSearchInput function)
 -  (WASI: Switch to crt1-command.o to enable support for new-style commands)
 -  (Do not attempt to unlock envlock in child process after a fork.)
 -  (fix: wrong word)
 -  (Treat header as first paragraph for shortened markdown descriptions)
 -  (fix error message for copy(_nonoverlapping) overflow)
 -  (Rename `Option::get_or_default` to `get_or_insert_default`)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2021-03-10 19:12:53 +00:00
Dylan DPC
881bbb758a
Rollup merge of - sunfishcode:wasi-command, r=alexcrichton
WASI: Switch to crt1-command.o to enable support for new-style commands

This switches Rust's WASI target to use crt1-command.o instead of
crt1.o, which enables support for new-style commands. By default,
new-style commands work the same way as old-style commands, so nothing
immediately changes here, but this will be needed by later changes to
enable support for typed arguments.

See here for more information on new-style commands:
 - https://github.com/WebAssembly/wasi-libc/pull/203
 - https://reviews.llvm.org/D81689

r? ```@alexcrichton```
2021-03-10 17:55:41 +01:00
bors
17a07d71bf Auto merge of - cratelyn:implement-rfc-2945-c-unwind-abi, r=Amanieu
Implement RFC 2945: "C-unwind" ABI

## Implement RFC 2945: "C-unwind" ABI

This branch implements [RFC 2945]. The tracking issue for this RFC is .

The feature gate for the issue is `#![feature(c_unwind)]`.

This RFC was created as part of the ffi-unwind project group tracked at .

### Changes

Further details will be provided in commit messages, but a high-level overview
of the changes follows:

* A boolean `unwind` payload is added to the `C`, `System`, `Stdcall`,
and `Thiscall` variants, marking whether unwinding across FFI boundaries is
acceptable. The cases where each of these variants' `unwind` member is true
correspond with the `C-unwind`, `system-unwind`, `stdcall-unwind`, and
`thiscall-unwind` ABI strings introduced in RFC 2945 [3].

* This commit adds a `c_unwind` feature gate for the new ABI strings.
Tests for this feature gate are included in `src/test/ui/c-unwind/`, which
ensure that this feature gate works correctly for each of the new ABIs.
A new language features entry in the unstable book is added as well.

* We adjust the `rustc_middle::ty::layout::fn_can_unwind` function,
used to compute whether or not a `FnAbi` object represents a function that
should be able to unwind when `panic=unwind` is in use.

* Changes are also made to
`rustc_mir_build::build::should_abort_on_panic` so that the function ABI is
used to determind whether it should abort, assuming that the `panic=unwind`
strategy is being used, and no explicit unwind attribute was provided.

[RFC 2945]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md
2021-03-10 16:44:04 +00:00
Yuki Okushi
761a2b389d
Rollup merge of - Yn0ga:master, r=estebank
Add powerpc-unknown-openbsd target
2021-03-10 08:01:29 +09:00
katelyn a. martin
05bf037fec address pr review comments
### Add debug assertion to check `AbiDatas` ordering

    This makes a small alteration to `Abi::index`, so that we include a
    debug assertion to check that the index we are returning corresponds
    with the same abi in our data array.

    This will help prevent ordering bugs in the future, which can
    manifest in rather strange errors.

 ### Using exhaustive ABI matches

    This slightly modifies the changes from our previous commits,
    favoring exhaustive matches in place of `_ => ...` fall-through
    arms.

    This should help with maintenance in the future, when additional
    ABI's are added, or when existing ABI's are modified.

 ### List all `-unwind` ABI's in unstable book

    This updates the `c-unwind` page in the unstable book to list _all_
    of the other ABI strings that are introduced by this feature gate.

    Now, all of the ABI's specified by RFC 2945 are shown.

Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>
Co-authored-by: Niko Matsakis <niko@alum.mit.edu>
2021-03-09 14:40:33 -05:00
katelyn a. martin
df45c579de rustc_target: add "unwind" payloads to Abi
### Overview

    This commit begins the implementation work for RFC 2945. For more
    information, see the rendered RFC [1] and tracking issue [2].

    A boolean `unwind` payload is added to the `C`, `System`, `Stdcall`,
    and `Thiscall` variants, marking whether unwinding across FFI
    boundaries is acceptable. The cases where each of these variants'
    `unwind` member is true correspond with the `C-unwind`,
    `system-unwind`, `stdcall-unwind`, and `thiscall-unwind` ABI strings
    introduced in RFC 2945 [3].

 ### Feature Gate and Unstable Book

    This commit adds a `c_unwind` feature gate for the new ABI strings.
    Tests for this feature gate are included in `src/test/ui/c-unwind/`,
    which ensure that this feature gate works correctly for each of the
    new ABIs.

    A new language features entry in the unstable book is added as well.

 ### Further Work To Be Done

    This commit does not proceed to implement the new unwinding ABIs,
    and is intentionally scoped specifically to *defining* the ABIs and
    their feature flag.

 ### One Note on Test Churn

    This will lead to some test churn, in re-blessing hash tests, as the
    deleted comment in `src/librustc_target/spec/abi.rs` mentioned,
    because we can no longer guarantee the ordering of the `Abi`
    variants.

    While this is a downside, this decision was made bearing in mind
    that RFC 2945 states the following, in the "Other `unwind` Strings"
    section [3]:

    >  More unwind variants of existing ABI strings may be introduced,
    >  with the same semantics, without an additional RFC.

    Adding a new variant for each of these cases, rather than specifying
    a payload for a given ABI, would quickly become untenable, and make
    working with the `Abi` enum prone to mistakes.

    This approach encodes the unwinding information *into* a given ABI,
    to account for the future possibility of other `-unwind` ABI
    strings.

 ### Ignore Directives

    `ignore-*` directives are used in two of our `*-unwind` ABI test
    cases.

    Specifically, the `stdcall-unwind` and `thiscall-unwind` test cases
    ignore architectures that do not support `stdcall` and
    `thiscall`, respectively.

    These directives are cribbed from
    `src/test/ui/c-variadic/variadic-ffi-1.rs` for `stdcall`, and
    `src/test/ui/extern/extern-thiscall.rs` for `thiscall`.

    This would otherwise fail on some targets, see:
    fcf697f902

 ### Footnotes

[1]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md
[2]: https://github.com/rust-lang/rust/issues/74990
[3]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md#other-unwind-abi-strings
2021-03-09 14:38:29 -05:00
Dan Gohman
fdb899ba4b WASI: Switch to crt1-command.o to enable support for new-style commands
This switches Rust's WASI target to use crt1-command.o instead of
crt1.o, which enables support for new-style commands. By default,
new-style commands work the same way as old-style commands, so nothing
immediately changes here, but this will be needed by later changes to
enable support for typed arguments.

See here for more information on new-style commands:
 - https://github.com/WebAssembly/wasi-libc/pull/203
 - https://reviews.llvm.org/D81689
2021-03-08 17:49:34 -08:00
Yuki Okushi
d1dc16623f
Rollup merge of - QuiltOS:kernel-code-targets-os-none, r=joshtriplett
Change built-in kernel targets to be os = none throughout

Whether for Rust's own `target_os`, LLVM's triples, or GNU config's, the
OS-related have fields have been for code running *on* that OS, not code
hat is *part* of the OS.

The difference is huge, as syscall interfaces are nothing like
freestanding interfaces. Kernels are (hypervisors and other more exotic
situations aside) freestanding programs that use the interfaces provided
by the hardware. It's *those* interfaces, the ones external to the
program being built and its software dependencies, that are the content
of the target.

For the Linux Kernel in particular, `target_env: "gnu"` is removed for
the same reason: that `-gnu` refers to glibc or GNU/linux, neither of
which applies to the kernel itself.

Relates to 
2021-03-07 10:41:04 +09:00
yn0ga
ccca767834 Add powerpc-unknown-openbsd target
Add powerpc-unknown-openbsd target

* Fix missing abi::endian crate
* Missing platform-support.md
2021-03-04 22:43:34 +01:00
bors
409920873c Auto merge of - nikic:llvm-12, r=nagisa
Upgrade to LLVM 12

This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far.

r? `@cuviper`
2021-03-04 15:16:44 +00:00
John Ericson
9d25ccf0e8 Change built-in kernel targets to be os = none throughout
Whether for Rust's own `target_os`, LLVM's triples, or GNU config's, the
OS-related have fields have been for code running *on* that OS, not code
that is *part* of the OS.

The difference is huge, as syscall interfaces are nothing like
freestanding interfaces. Kernels are (hypervisors and other more exotic
situations aside) freestanding programs that use the interfaces provided
by the hardware. It's *those* interfaces, the ones external to the
program being built and its software dependencies, that are the content
of the target.

For the Linux Kernel in particular, `target_env: "gnu"` is removed for
the same reason: that `-gnu` refers to glibc or GNU/linux, neither of
which applies to the kernel itself.

Relates to 

Thanks @ojeda for catching some things.
2021-03-01 12:46:25 -05:00
Jakub Kulik
c615bed387 Change default Solaris x86 target to x86_64-pc-solaris 2021-03-01 15:05:31 +01:00
bors
43fc1b3e24 Auto merge of - terhechte:catalyst-support-m1-fix, r=petrochenkov
Fixed support for macOS Catalyst on ARM64

When I initially added Arm64 Catalyst support in https://github.com/rust-lang/rust/pull/77484 I had access to a DTK. However, while waiting to merge the PR some other changes were merged which caused conflicts in the branch. When fixing those conflicts I had no access to the DTK anymore and didn't try out if the resulting binaries did indeed work on Apple Silicon. I finally have a M1 and I realized that some small changes were necessary to support Apple Silicon. This PR adds the required changes. I've been running binaries generated with this branch for some time now and they work without issues.
2021-03-01 00:07:29 +00:00
Nikita Popov
092643a266 Explicitly mark x86-interrupt ABI argument as byval
The first argument to an x86-interrupt ABI function was implicitly
treated as byval prior to LLVM 12. Since LLVM 12, it has to be
marked as such explicitly: 2e0e03c6a0
2021-02-28 10:19:44 +01:00
Nikita Popov
55f345f325 Support LLVM 12 in rustc 2021-02-28 10:19:44 +01:00
bors
6e2801c44e Auto merge of - nagisa:nagisa/remove-rumprun, r=petrochenkov
Remove the x86_64-rumprun-netbsd target

Herein we remove the target from the compiler and the code from libstd intended to support the now-defunct rumprun project.

Closes 
2021-02-28 03:56:16 +00:00
Dylan DPC
a7f9aca0a6
Rollup merge of - nikic:musl-crtend, r=nagisa
Link crtbegin/crtend on musl to terminate .eh_frame

For some targets, rustc uses a "CRT fallback", where it links CRT
object files it ships instead of letting the host compiler link
them.

On musl, rustc currently links crt1, crti and crtn (provided by
libc), but does not link crtbegin and crtend (provided by libgcc).
In particular, crtend is responsible for terminating the .eh_frame
section. Lack of terminator may result in segfaults during
unwinding, as reported in  and encountered by the LLVM 12
update in .

This patch links crtbegin and crtend for musl as well, following
the table at the top of crt_objects.rs.

r? ``@nagisa``
2021-02-27 21:56:19 +01:00
Benedikt Terhechte
a1670aa9f5 Fixed support for macOS Catalyst for Apple Silicon 2021-02-27 18:15:55 +01:00
Simonas Kazlauskas
a757fae245 Remove the x86_64-rumprun-netbsd target
Closes 
2021-02-27 17:55:22 +02:00
Guillaume Gomez
0db8349fff
Rollup merge of - jhpratt:stabilize-str_split_once, r=m-ou-se
Stabilize str_split_once

Closes 
2021-02-26 15:52:29 +01:00
Nikita Popov
c7091f5a07 Link crtbegin/crtend on musl to terminate .eh_frame
For some targets, rustc uses a "CRT fallback", where it links CRT
object files it ships instead of letting the host compiler link
them.

On musl, rustc currently links crt1, crti and crtn (provided by
libc), but does not link crtbegin and crtend (provided by libgcc).
In particular, crtend is responsible for terminating the .eh_frame
section. Lack of terminator may result in segfaults during
unwinding, as reported in  and encountered by the LLVM 12
update in .

This patch links crtbegin and crtend for musl as well, following
the table at the top of crt_objects.rs.
2021-02-26 11:02:51 +01:00
Dylan DPC
8979fd4237
Rollup merge of - kaniini:s390x-musl-target, r=nagisa
add s390x-unknown-linux-musl target

This is the first step in bringup for Rust on s390x.

The libc and std crates need modifications as well, but getting this upstream makes that work easier.
2021-02-23 02:51:53 +01:00
Simon Vandel Sillesen
2d1e0adfe9 New pass to deduplicate blocks 2021-02-21 21:51:54 +01:00
Yuki Okushi
882fd69b22
Rollup merge of - deg4uss3r:degausser/aarch64_apple_ios_sim, r=shepmaster
Add new `rustc` target for Arm64 machines that can target the iphonesimulator

This PR lands a new target (`aarch64-apple-ios-sim`) that targets arm64 iphone simulator, previously unreachable from Apple Silicon machines.

resolves 

r? `@shepmaster`
2021-02-21 15:26:42 +09:00