Commit Graph

675 Commits

Author SHA1 Message Date
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
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 #88499 - eddyb:layout-off, r=nagisa
Provide `layout_of` automatically (given tcx + param_env + error handling).

After #88337, 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 #88338 (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 #88454 - devnexen:sunos_asan, r=wesleywiser
sunos systems add sanitizer supported.
2021-09-03 17:50:51 +00:00
bors
64929313f5 Auto merge of #88516 - 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 #87114 - 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 #88350 - programmerjake:add-ppc-cr-xer-clobbers, r=Amanieu
add support for clobbering xer, cr, and cr[0-7] for asm! on OpenPower/PowerPC

Fixes #88315
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 #88337 - 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 #88250 - rusticstuff:macos-lld, r=nagisa
Make `-Z gcc-ld=lld` work for Apple targets

`-Z gcc-ld=lld` was introduced in #85961. 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 #86945.
2021-08-29 04:51:14 +00:00
bors
2031fd6e46 Auto merge of #88245 - 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 #85931; 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 #88308 - 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 #88315
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 #88242 - 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 #87699 - 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 #88230 - 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 #88226, 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 #88077 - 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 #87570 - 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 #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 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 #88023 - 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 #87581 - Amanieu:asm_clobber_abi, r=nagisa
Add support for clobber_abi to asm!

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

Fixes #81092

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 #87922 - 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 #85357 - 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 #87535 - 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 #87664 - 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 #87449 - 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 #43575
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 #87124 - 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 #86062 - 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 #86017
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 #86922 - 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 #86416 - 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 #57182

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 #86196
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 #85775 - 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 #83572 - 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 #85920 - 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 #79608 - 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 #86014 - 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 #85948.
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 #85966 - 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 #85850 - 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 #85706 - 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 #85376 - 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 #85274 - luqmana:linker-is-gnu-gc-sections, r=petrochenkov
Only pass --[no-]gc-sections if linker is GNU ld.

Fixes a regression from #84468 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 #84468 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 #85312 - 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 #62042 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 #83901. #80641 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 #83800 should be addressed.
2021-05-10 19:15:19 +03:00
bors
c55c26cb36 Auto merge of #83800 - 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 #84930 - 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 #84072 - 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 #84658 - 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 #83412.

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

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

So we are reverting PR #77885 on stable and beta. We'll reland PR #77885 (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 #84310 - 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 #84334 - klensy:typo-compiler, r=jyn514
fix few typos in comments
2021-04-20 00:16:45 +00:00
Dylan DPC
3b81ea86fb
Rollup merge of #84126 - 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 #84008 - Dylan-DPC:rollup-invxvg8, r=Dylan-DPC
Rollup of 6 pull requests

Successful merges:

 - #80733 (Improve links in inline code in `core::pin`.)
 - #81764 (Stabilize `rustdoc::bare_urls` lint)
 - #81938 (Stabilize `peekable_peek_mut`)
 - #83980 (Fix outdated crate names in compiler docs)
 - #83992 (Merge idents when generating source content)
 - #84001 (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 #83853 - 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 #83495

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 #83495
2021-04-05 13:38:24 +01:00
Dylan DPC
0d12422f2d
Rollup merge of #80525 - 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 #83800.

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 #81802
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 #83593 - 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 #82982 - Dylan-DPC:rollup-mt497z7, r=Dylan-DPC
Rollup of 9 pull requests

Successful merges:

 - #81309 (always eagerly eval consts in Relate)
 - #82217 (Edition-specific preludes)
 - #82807 (rustdoc: Remove redundant enableSearchInput function)
 - #82924 (WASI: Switch to crt1-command.o to enable support for new-style commands)
 - #82949 (Do not attempt to unlock envlock in child process after a fork.)
 - #82955 (fix: wrong word)
 - #82962 (Treat header as first paragraph for shortened markdown descriptions)
 - #82976 (fix error message for copy(_nonoverlapping) overflow)
 - #82977 (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 #82924 - 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 #76570 - 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 #74990.

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

This RFC was created as part of the ffi-unwind project group tracked at rust-lang/lang-team#19.

### 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 #82733 - 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 #77916 - 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 #74247
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 #81451 - 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 #74247

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 #82601 - 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 #82594 - 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 #81514
2021-02-28 03:56:16 +00:00
Dylan DPC
a7f9aca0a6
Rollup merge of #82534 - 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 #47551 and encountered by the LLVM 12
update in #81451.

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 #81514
2021-02-27 17:55:22 +02:00
Guillaume Gomez
0db8349fff
Rollup merge of #81940 - jhpratt:stabilize-str_split_once, r=m-ou-se
Stabilize str_split_once

Closes #74773
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 #47551 and encountered by the LLVM 12
update in #81451.

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 #82166 - 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 #81966 - 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 #81632

r? `@shepmaster`
2021-02-21 15:26:42 +09:00
Jan-Erik Rediger
8d6ad11ab2
iOS simulator: pick the target based on the environment variable
LLVM picks the right things to put into the compiled object file based
on the target deployment version.
We need to communicate it through the target triple.
Only with that LLVM will use the right commands in the file to make it
look and behave like code compiled for the arm64 iOS simulator target.
2021-02-20 16:45:00 -05:00
Ricky (deg4uss3r)
f10fbbbd53
added aarch64_apple_ios_sim as a rustc target 2021-02-19 13:17:05 -05:00
Ariadne Conill
48b5c093d6 add s390x-unknown-linux-musl target 2021-02-19 03:14:28 +00:00
Khem Raj
f049e27354 add specs for riscv32/riscv64 musl targets
Signed-off-by: Khem Raj <raj.khem@gmail.com>
2021-02-16 16:34:32 -08:00
Matthias Krüger
4390a61b64 avoid full-slicing slices
If we already have a slice, there is no need to get another full-range slice from that, just use the original.
clippy::redundant_slicing
2021-02-16 00:31:11 +01:00
Miguel Ojeda
0df8ddee53 Stack probes: fix error message
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2021-02-11 20:33:16 +01:00
Jacob Pratt
c28f2a8bee
Stabilize str_split_once 2021-02-09 23:17:11 -05:00
bors
b593389edb Auto merge of #81346 - hug-dev:nonsecure-call-abi, r=jonas-schievink
Add a new ABI to support cmse_nonsecure_call

This adds support for the `cmse_nonsecure_call` feature to be able to perform non-secure function call.

See the discussion on Zulip [here](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Support.20for.20callsite.20attributes/near/223054928).

This is a followup to #75810 which added `cmse_nonsecure_entry`. As for that PR, I assume that the changes are small enough to not have to go through a RFC but I don't mind doing one if needed 😃
I did not yet create a tracking issue, but if most of it is fine, I can create one and update the various files accordingly (they refer to the other tracking issue now).

On the Zulip chat, I believe `@jonas-schievink` volunteered to be a reviewer 💯
2021-02-03 06:00:43 +00:00
Jack Huey
399c0a8e52
Rollup merge of #81455 - Amanieu:aarch64_ilp32, r=sanxiyn
Add AArch64 big-endian and ILP32 targets

This PR adds 3 new AArch64 targets:
- `aarch64_be-unknown-linux-gnu`
- `aarch64-unknown-linux-gnu_ilp32`
- `aarch64_be-unknown-linux-gnu_ilp32`

It also fixes some ABI issues on big-endian ARM and AArch64.
2021-02-02 16:01:35 -05:00
Mark Rousskov
d5b760ba62 Bump rustfmt version
Also switches on formatting of the mir build module
2021-02-02 09:09:52 -05:00
Hugues de Valon
ce9818f2b7 Add a new ABI to support cmse_nonsecure_call
This commit adds a new ABI to be selected via `extern
"C-cmse-nonsecure-call"` on function pointers in order for the compiler to
apply the corresponding cmse_nonsecure_call callsite attribute.
For Armv8-M targets supporting TrustZone-M, this will perform a
non-secure function call by saving, clearing and calling a non-secure
function pointer using the BLXNS instruction.

See the page on the unstable book for details.

Signed-off-by: Hugues de Valon <hugues.devalon@arm.com>
2021-02-02 13:04:31 +00:00
Jonas Schievink
ed5614599a
Rollup merge of #81255 - sunfishcode:wasi-no-export-dynamic, r=alexcrichton
Don't link with --export-dynamic on wasm32-wasi

Remove --export-dynamic from the link arguments on the wasm32-wasi
target, as it emits spurious exports and increases code size.

Leave it in place for wasm32-unknown-unknown and
wasm32-unknown-emscripten. Even though it isn't a great solution
there, users are likely depending on its behavior there.
2021-01-31 16:36:44 +01:00
Simonas Kazlauskas
915a04e2a4 Consider Scalar to be a bool only if its unsigned
This seems right, given that conceptually bools are unsigned, but the
implications of this change may have more action at distance that I'm
not sure how to exhaustively consider.

For instance there are a number of cases where code attaches range
metadata if `scalar.is_bool()` holds. Supposedly it would no longer be
attached to the `repr(i8)` enums? Though I'm not sure why booleans are
being special-cased here in the first place...

Fixes #80556
2021-01-30 00:49:10 +02:00
bors
74500b9978 Auto merge of #81493 - JohnTitor:rollup-sa4m4zh, r=JohnTitor
Rollup of 10 pull requests

Successful merges:

 - #79570 (rustc: Stabilize `-Zrun-dsymutil` as `-Csplit-debuginfo`)
 - #79819 (Add `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` lint)
 - #79991 (rustdoc: Render HRTB correctly for bare functions)
 - #80215 (Use -target when linking binaries for Mac Catalyst)
 - #81158 (Point to span of upvar making closure FnMut)
 - #81176 (Improve safety of `LateContext::qpath_res`)
 - #81287 (Split rustdoc JSON types into separately versioned crate)
 - #81306 (Fuse inner iterator in FlattenCompat and improve related tests)
 - #81333 (clean up some const error reporting around promoteds)
 - #81459 (Fix rustdoc text selection for page titles)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2021-01-29 00:58:43 +00:00
Yuki Okushi
d9e56f48c5
Rollup merge of #79570 - alexcrichton:split-debuginfo, r=bjorn3
rustc: Stabilize `-Zrun-dsymutil` as `-Csplit-debuginfo`

This commit adds a new stable codegen option to rustc,
`-Csplit-debuginfo`. The old `-Zrun-dsymutil` flag is deleted and now
subsumed by this stable flag. Additionally `-Zsplit-dwarf` is also
subsumed by this flag but still requires `-Zunstable-options` to
actually activate. The `-Csplit-debuginfo` flag takes one of
three values:

* `off` - This indicates that split-debuginfo from the final artifact is
  not desired. This is not supported on Windows and is the default on
  Unix platforms except macOS. On macOS this means that `dsymutil` is
  not executed.

* `packed` - This means that debuginfo is desired in one location
  separate from the main executable. This is the default on Windows
  (`*.pdb`) and macOS (`*.dSYM`). On other Unix platforms this subsumes
  `-Zsplit-dwarf=single` and produces a `*.dwp` file.

* `unpacked` - This means that debuginfo will be roughly equivalent to
  object files, meaning that it's throughout the build directory
  rather than in one location (often the fastest for local development).
  This is not the default on any platform and is not supported on Windows.

Each target can indicate its own default preference for how debuginfo is
handled. Almost all platforms default to `off` except for Windows and
macOS which default to `packed` for historical reasons.

Some equivalencies for previous unstable flags with the new flags are:

* `-Zrun-dsymutil=yes` -> `-Csplit-debuginfo=packed`
* `-Zrun-dsymutil=no` -> `-Csplit-debuginfo=unpacked`
* `-Zsplit-dwarf=single` -> `-Csplit-debuginfo=packed`
* `-Zsplit-dwarf=split` -> `-Csplit-debuginfo=unpacked`

Note that `-Csplit-debuginfo` still requires `-Zunstable-options` for
non-macOS platforms since split-dwarf support was *just* implemented in
rustc.

There's some more rationale listed on #79361, but the main gist of the
motivation for this commit is that `dsymutil` can take quite a long time
to execute in debug builds and provides little benefit. This means that
incremental compile times appear that much worse on macOS because the
compiler is constantly running `dsymutil` over every single binary it
produces during `cargo build` (even build scripts!). Ideally rustc would
switch to not running `dsymutil` by default, but that's a problem left
to get tackled another day.

Closes #79361
2021-01-29 09:17:20 +09:00
bors
b05fd2a15d Auto merge of #81388 - bjorn3:wasm_bindgen_fix, r=nikomatsakis
Fix abi for wasm-bindgen

Hopefully fixes https://github.com/rust-lang/rust/issues/81386. `@alexcrichton` can you confirm this fixes wasm-bindgen?

r? `@alexcrichton`
2021-01-28 22:01:42 +00:00
Alex Crichton
a124043fb0 rustc: Stabilize -Zrun-dsymutil as -Csplit-debuginfo
This commit adds a new stable codegen option to rustc,
`-Csplit-debuginfo`. The old `-Zrun-dsymutil` flag is deleted and now
subsumed by this stable flag. Additionally `-Zsplit-dwarf` is also
subsumed by this flag but still requires `-Zunstable-options` to
actually activate. The `-Csplit-debuginfo` flag takes one of
three values:

* `off` - This indicates that split-debuginfo from the final artifact is
  not desired. This is not supported on Windows and is the default on
  Unix platforms except macOS. On macOS this means that `dsymutil` is
  not executed.

* `packed` - This means that debuginfo is desired in one location
  separate from the main executable. This is the default on Windows
  (`*.pdb`) and macOS (`*.dSYM`). On other Unix platforms this subsumes
  `-Zsplit-dwarf=single` and produces a `*.dwp` file.

* `unpacked` - This means that debuginfo will be roughly equivalent to
  object files, meaning that it's throughout the build directory
  rather than in one location (often the fastest for local development).
  This is not the default on any platform and is not supported on Windows.

Each target can indicate its own default preference for how debuginfo is
handled. Almost all platforms default to `off` except for Windows and
macOS which default to `packed` for historical reasons.

Some equivalencies for previous unstable flags with the new flags are:

* `-Zrun-dsymutil=yes` -> `-Csplit-debuginfo=packed`
* `-Zrun-dsymutil=no` -> `-Csplit-debuginfo=unpacked`
* `-Zsplit-dwarf=single` -> `-Csplit-debuginfo=packed`
* `-Zsplit-dwarf=split` -> `-Csplit-debuginfo=unpacked`

Note that `-Csplit-debuginfo` still requires `-Zunstable-options` for
non-macOS platforms since split-dwarf support was *just* implemented in
rustc.

There's some more rationale listed on #79361, but the main gist of the
motivation for this commit is that `dsymutil` can take quite a long time
to execute in debug builds and provides little benefit. This means that
incremental compile times appear that much worse on macOS because the
compiler is constantly running `dsymutil` over every single binary it
produces during `cargo build` (even build scripts!). Ideally rustc would
switch to not running `dsymutil` by default, but that's a problem left
to get tackled another day.

Closes #79361
2021-01-28 08:51:11 -08:00
Amanieu d'Antras
8783d1a47e Add big-endian and ILP32 AArch64 targets 2021-01-27 22:47:57 +00:00
Amanieu d'Antras
d53b0a04a6 Fix ARM and AArch64 calling convention for passing small composite types
On big-endian the values need to be right-aligned within a 64-bit register, as if the value had been read with a 64-bit load instruction.
2021-01-27 22:47:56 +00:00
Tomasz Miąsko
83dc7fe669 Inline trivial implementation of rustc_target::abi::Align 2021-01-27 16:13:18 +01:00
bjorn3
c1c06f3e3f Use PassMode::Direct for Abi::Aggregate by default 2021-01-26 14:49:35 +01:00
bjorn3
eb99ea5142 Revert "Wasm-bindgen abi compat using cast_to"
This reverts commit 903c553f4a.
2021-01-26 13:38:59 +01:00
bjorn3
903c553f4a Wasm-bindgen abi compat using cast_to 2021-01-26 11:31:37 +01:00
bjorn3
36df9c55e5 Revert "Share wasm-bindgen compat abi selection code"
This reverts commit e7a056fe20.
2021-01-26 11:09:06 +01:00
bjorn3
e7a056fe20 Share wasm-bindgen compat abi selection code 2021-01-25 21:32:57 +01:00
bors
72c7b70267 Auto merge of #80838 - nagisa:nagisa/stack-probe-type, r=cuviper
Target stack-probe support configurable finely

This adds capability to configure the target's stack probe support in a
more precise manner than just on/off. In particular now we allow
choosing between always inline-asm, always call or either one of those
depending on the LLVM version.

Note that this removes the ability to turn off the generation of the
stack-probe attribute. This is valid to replace it with inline-asm for all targets because
`probe-stack="inline-asm"` will not generate any machine code on targets
that do not currently support stack probes. This makes support for stack
probes on targets that don't have any right now automatic with LLVM
upgrades in the future.

(This is valid to do based on the fact that clang unconditionally sets
this attribute when `-fstack-clash-protection` is used, AFAICT)

cc #77885
r? `@cuviper`
2021-01-24 09:44:42 +00:00
bjorn3
c3367dbc6f Add some comments to PassMode 2021-01-23 12:57:35 +01:00
bjorn3
a93dace55c Never create an temporary PassMode::Direct when it is not a valid pass mode for a type 2021-01-23 10:30:39 +01:00
bjorn3
da0309c711 Use PassMode::Pair by default for Abi::ScalarPair for all abi's and in return position
Abi::ScalarPair is only ever used for types that don't have a stable
layout anyway so this doesn't break any FFI. It does however reduce the
amount of special casing on the abi outside of the code responsible for
abi specific adjustments to the pass mode.
2021-01-23 10:30:38 +01:00
Dan Gohman
9abcfa55c3 Don't link with --export-dynamic on wasm32-wasi
Remove --export-dynamic from the link arguments on the wasm32-wasi
target, as it emits spurious exports and increases code size.

Leave it in place for wasm32-unknown-unknown and
wasm32-unknown-emscripten. Even though it isn't a great solution
there, users are likely depending on its behavior there.
2021-01-21 16:13:43 -08:00
Simonas Kazlauskas
1b15ec656b Use a call probe on the x86_64-uefi target
Fixes #81196
2021-01-20 01:37:45 +02:00
Simonas Kazlauskas
007080b607 Target stack-probe support configurable finely
This adds capability to configure the target's stack probe support in a
more precise manner than just on/off. In particular now we allow
choosing between always inline-asm, always call or either one of those
depending on the LLVM version on a per-target basis.
2021-01-16 12:38:02 +02:00
Dylan DPC
492cb39825
Rollup merge of #80662 - rxrbln:master, r=estebank
Added support for i386-unknown-linux-gnu and i486-unknown-linux-gnu

Support for both can be useful when creating new firmware, boot loaders,
or embedded operating systems.
2021-01-13 03:20:15 +01:00
Yuki Okushi
56504a00f2
Rollup merge of #80042 - sivadeilra:cold_bits, r=oli-obk
Split a func into cold/hot parts, reducing binary size

I noticed that the Size::bits function is called in many places,
and is inlined into them. On x86_64-pc-windows-msvc, this function
is inlined 527 times, and compiled separately (non-inlined) 3 times.

Each of those inlined calls contains code that panics. This commit
moves the `panic!` call into a separate function and marks that
function with `#[cold]`.

This reduces binary size by 24 KB. Not much, but it's something.
Changes like this often reduce pressure on instruction-caches,
since it reduces the amount of code that is inlined into hot code
paths. Or more precisely, it removes cold code from hot cache lines.
2021-01-12 07:59:08 +09:00
Yuki Okushi
edcfe7b629
Rollup merge of #79998 - devsnek:wasm32-bindgen-compat, r=alexcrichton
Use correct ABI for wasm32 by default

Introduces `wasm32-unknown-bindgen` for those wishing to use the bindgen compat abi. `wasm32-*` now uses the correct abi by default.

Fixes https://github.com/rustwasm/team/issues/291
2021-01-12 07:59:06 +09:00
Yuki Okushi
1d83f9828f
Rollup merge of #79997 - coolreader18:wasm-reactor, r=alexcrichton
Emit a reactor for cdylib target on wasi

Fixes #79199, and relevant to #73432

Implements wasi reactors, as described in WebAssembly/WASI#13 and [`design/application-abi.md`](https://github.com/WebAssembly/WASI/blob/master/design/application-abi.md)

Empty `lib.rs`, `lib.crate-type = ["cdylib"]`:

```shell
$ cargo +reactor build --release --target wasm32-wasi
   Compiling wasm-reactor v0.1.0 (/home/coolreader18/wasm-reactor)
    Finished release [optimized] target(s) in 0.08s
$ wasm-dis target/wasm32-wasi/release/wasm_reactor.wasm >reactor.wat
```
`reactor.wat`:
```wat
(module
 (type $none_=>_none (func))
 (type $i32_=>_none (func (param i32)))
 (type $i32_i32_=>_i32 (func (param i32 i32) (result i32)))
 (type $i32_=>_i32 (func (param i32) (result i32)))
 (type $i32_i32_i32_=>_i32 (func (param i32 i32 i32) (result i32)))
 (import "wasi_snapshot_preview1" "fd_prestat_get" (func $__wasi_fd_prestat_get (param i32 i32) (result i32)))
 (import "wasi_snapshot_preview1" "fd_prestat_dir_name" (func $__wasi_fd_prestat_dir_name (param i32 i32 i32) (result i32)))
 (import "wasi_snapshot_preview1" "proc_exit" (func $__wasi_proc_exit (param i32)))
 (import "wasi_snapshot_preview1" "environ_sizes_get" (func $__wasi_environ_sizes_get (param i32 i32) (result i32)))
 (import "wasi_snapshot_preview1" "environ_get" (func $__wasi_environ_get (param i32 i32) (result i32)))
 (memory $0 17)
 (table $0 1 1 funcref)
 (global $global$0 (mut i32) (i32.const 1048576))
 (global $global$1 i32 (i32.const 1049096))
 (global $global$2 i32 (i32.const 1049096))
 (export "memory" (memory $0))
 (export "_initialize" (func $_initialize))
 (export "__data_end" (global $global$1))
 (export "__heap_base" (global $global$2))
 (func $__wasm_call_ctors
  (call $__wasilibc_initialize_environ_eagerly)
  (call $__wasilibc_populate_preopens)
 )
 (func $_initialize
  (call $__wasm_call_ctors)
 )
 (func $malloc (param $0 i32) (result i32)
  (call $dlmalloc
   (local.get $0)
  )
 )
 ;; lots of dlmalloc, memset/memcpy, & libpreopen code
)
```

I went with repurposing cdylib because I figured that it doesn't make much sense to have a wasi shared library that can't be initialized, and even if someone was using it adding an `_initialize` export is a very small change.
2021-01-12 07:58:59 +09:00
Gus Caplan
5ba3be1d60
squash! fix wasi 2021-01-11 15:31:52 -06:00
Gus Caplan
8f64cec022
new target 2021-01-11 14:22:41 -06:00
Gus Caplan
94bf59ea34
Use correct ABI for wasm32 by default
Introduces `RUSTC_USE_WASM32_BINDGEN_COMPAT_ABI` env var to use the
compat ABI if need.
2021-01-11 14:22:38 -06:00
Noah
92d3537abb
Add wasi-exec-model cg option for emitting wasi reactors 2021-01-08 13:09:40 -06:00
Lzu Tao
8ee804dc2b Change related spec files to use the new enum 2021-01-06 13:34:20 +00:00
Lzu Tao
fa4d8bc878 Prefer enum Endian in rustc_target::Target 2021-01-06 13:34:19 +00:00
Arlie Davis
4721b6518c Split a func into cold/hot parts, reducing binary size
I noticed that the Size::bits function is called in many places,
and is inlined into them. On x86_64-pc-windows-msvc, this function
is inlined 527 times, and compiled separately (non-inlined) 3 times.

Each of those inlined calls contains code that panics. This commit
moves the `panic!` call into a separate function and marks that
function with `#[cold]`.

This reduces binary size by 24 KB. By itself, that's not a substantial
reduction. However, changes like this often reduce pressure on
instruction-caches, since it reduces the amount of code that is inlined
into hot code paths. Or more precisely, it removes cold code from hot
cache lines. It also removes all conditionals from Size::bits(),
which is called in many places.
2021-01-05 12:52:34 -08:00
René Rebe
a0b0aecda3 Added support for i386-unknown-linux-gnu and i486-unknown-linux-gnu
Support for both can be useful when creating new firmware, boot loaders,
or embedded operating systems.
2021-01-05 12:05:36 +01:00
Jakub Kulik
acc63bc5ba Add support for target aliases 2020-12-16 10:41:07 +01:00
Tyler Mandry
0327b5dac5
Rollup merge of #79917 - sivadeilra:asm_symbols, r=petrochenkov
Use Symbol for inline asm register class names

This takes care of one "FIXME":
// FIXME: use direct symbol comparison for register class names

Instead of using string literals, this uses Symbol for register
class names.

This is part of work I am doing to improve how Symbol interning works.
2020-12-10 21:33:19 -08:00
Arlie Davis
40ed0f6857 Use Symbol for inline asm register class names
This takes care of one "FIXME":
// FIXME: use direct symbol comparison for register class names

Instead of using string literals, this uses Symbol for register
class names.
2020-12-10 13:51:56 -08:00
Eric Arellano
12db2225b6 Dogfood 'str_split_once() with compiler/ 2020-12-07 12:48:44 -07:00
bors
6645da366e Auto merge of #78684 - devsnek:inline-asm-wasm, r=Amanieu
Add wasm32 support to inline asm

There is some contention around inline asm and wasm, and I really only made this to figure out the process of hacking on rustc, but I figured as long as the code existed, it was worth uploading.

cc `@Amanieu`
2020-12-01 20:23:06 +00:00
Gus Caplan
d9f237caa6
Add wasm32 support to inline asm 2020-12-01 12:18:21 -06:00
Ondrej Perutka
b2ad73e8a4 Add built-in support for the armv5te-unknown-linux-uclibceabi target 2020-11-30 09:47:09 +01:00
Benedikt Terhechte
96779647c4 Add support for Arm64 Catalyst on ARM Macs 2020-11-26 11:31:59 +01:00
Lzu Tao
6bfe27a3e0 Drop support for cloudabi targets 2020-11-22 17:11:41 -05:00
bjorn3
43968aa8b8 Replace sext() and zext() with single ext() method 2020-11-21 19:22:31 +01:00
bjorn3
6a5f537fb9 Rename prefix_chunk to prefix_chunk_size 2020-11-21 19:22:31 +01:00
bjorn3
39b8b2b623 Remove StructRet arg attr
It is applied exactly when the return value has an indirect pass mode.
Except for InReg on x86 fastcall, arg attrs are now only used for
optimization purposes and thus are fine to ignore.
2020-11-21 19:22:31 +01:00
bjorn3
42b0b8080d Replace ByVal attribute with on_stack field for Indirect
This makes it clearer that only PassMode::Indirect allows ByVal
2020-11-21 19:22:30 +01:00
bjorn3
967a228208 Replace ZExt and SExt flags with ArgExtension enum
Both flags are mutually exclusive
2020-11-21 19:07:38 +01:00
Dylan DPC
96fc0f4c2f
Rollup merge of #78993 - petrochenkov:specdash, r=oli-obk
rustc_target: Fix dash vs underscore mismatches in option names

Fixes https://github.com/rust-lang/rust/issues/78981 (regression from https://github.com/rust-lang/rust/pull/78875, the old option names used dashes)
2020-11-15 03:02:59 +01:00
bors
66c1309446 Auto merge of #78959 - petrochenkov:likeuefi, r=nagisa
rustc_target: Mark UEFI targets as `is_like_windows`/`is_like_msvc`

And document what `is_like_windows` and `is_like_msvc` actually mean in more detail.

Addresses FIXMEs left from https://github.com/rust-lang/rust/pull/71030.
r? `@nagisa`
2020-11-14 09:11:25 +00:00
bors
1a25580c6c Auto merge of #78951 - petrochenkov:unknown, r=ehuss
rustc_target: Change os and vendor values to "none" and "unknown" for some targets

Closes https://github.com/rust-lang/rust/issues/77730
r? `@ehuss`
2020-11-14 06:44:18 +00:00
Mara Bos
76fa5f25ab
Rollup merge of #78950 - khyperia:spirv-asm, r=Amanieu
Add asm register information for SPIR-V

As discussed in [zulip](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Defining.20asm!.20for.20new.20architecture), we at [rust-gpu](https://github.com/EmbarkStudios/rust-gpu) would like to support `asm!` for our SPIR-V backend. However, we cannot do so purely without frontend support: [this match](d4ea0b3e46/compiler/rustc_target/src/asm/mod.rs (L185)) fails and so `asm!` is not supported ([error reported here](d4ea0b3e46/compiler/rustc_ast_lowering/src/expr.rs (L1095))). To resolve this, we need to stub out register information for SPIR-V to support getting the `asm!` content all the way to [`AsmBuilderMethods::codegen_inline_asm`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/traits/trait.AsmBuilderMethods.html#tymethod.codegen_inline_asm), at which point the rust-gpu backend can do all the parsing and codegen that is needed.

This is a pretty weird PR - adding support for a backend that isn't in-tree feels pretty gross to me, but I don't see an easy way around this. ``@Amanieu`` said I should submit it anyway, so, here we are! Let me know if this needs to go through a more formal process (MCP?) and what I should do to help this along.

I based this off the [wasm asm PR](https://github.com/rust-lang/rust/pull/78684), which unfortunately this PR conflicts with that one quite a bit, sorry for any merge conflict pain :(

---

Some open questions:

- What do we call the register class? Some context, SPIR-V is an SSA-based IR, there are "instructions" that create IDs (referred to as `<id>` in the spec), which can be referenced by other instructions. So, `reg` isn't exactly accurate, they're SSA IDs, not re-assignable registers.
- What happens when a SPIR-V register gets to the LLVM backend? Right now it's a `bug!`, but should that be a `sess.fatal()`? I'm not sure if it's even possible to reach that point, maybe there's a check that prevents the `spirv` target from even reaching that codepath.
2020-11-12 19:46:14 +01:00
Vadim Petrochenkov
04d41e1f40 rustc_target: Mark UEFI targets as is_like_windows/is_like_msvc
Document what `is_like_windows` and `is_like_msvc` mean in more detail.
2020-11-12 19:40:41 +03:00
Vadim Petrochenkov
dd682cb48c rustc_target: Fix dash vs underscore mismatches in option names 2020-11-12 19:33:07 +03:00
Jonas Schievink
904b658303
Rollup merge of #78930 - petrochenkov:notlikeandroid, r=Mark-Simulacrum
rustc_taret: Remove `TargetOptions::is_like_android`

This option was replaced by more specific options and is no longer used by the compiler.
2020-11-11 20:59:10 +01:00
khyperia
0e34b73996 Change capitalization of Spirv to SpirV
This matches the capitalization of RiscV
2020-11-11 19:18:06 +01:00
Vadim Petrochenkov
e0a8f22053 rustc_target: Make sure that in-tree targets follow conventions for os and vendor values 2020-11-11 20:59:37 +03:00
Vadim Petrochenkov
1def24c5f4 rustc_target: Normalize vendor from "" to "unknown" for all targets
Majority of targets use "unknown" vendor and changing it from "unknown" to omitted doesn't make sense.
From the LLVM docs (https://clang.llvm.org/docs/CrossCompilation.html#target-triple):

>Most of the time it can be omitted (and Unknown) will be assumed, which sets the defaults for the specified architecture.
>When a parameter is not important, it can be omitted, or you can choose unknown and the defaults will be used. If you choose a parameter that Clang doesn’t know, like blerg, it’ll ignore and assume unknown
2020-11-11 20:40:51 +03:00
Vadim Petrochenkov
443b45fa9f rustc_target: Change os from "unknown" to "none" for bare metal targets
x86_64-fortanix-unknown-sgx and wasm32-unknown-unknown still have os == "unknown" because both have libstd
2020-11-11 20:24:14 +03:00
khyperia
f3441348e0 Add asm register information for SPIR-V 2020-11-11 17:38:02 +01:00
Vadim Petrochenkov
ca17a91fb7 rustc_target: Move target env "gnu" from linux_base to linux_gnu_base 2020-11-11 11:38:40 +03:00
Vadim Petrochenkov
ce91c68943 rustc_taret: Remove TargetOptions::is_like_android 2020-11-10 23:51:34 +03:00
Jonas Schievink
105f4b8792
Rollup merge of #78875 - petrochenkov:cleantarg, r=Mark-Simulacrum
rustc_target: Further cleanup use of target options

Follow up to https://github.com/rust-lang/rust/pull/77729.

Implements items 2 and 4 from the list in https://github.com/rust-lang/rust/pull/77729#issue-500228243.

The first commit collapses uses of `target.options.foo` into `target.foo`.

The second commit renames some target options to avoid tautology:
`target.target_endian` -> `target.endian`
`target.target_c_int_width` -> `target.c_int_width`
`target.target_os` -> `target.os`
`target.target_env` -> `target.env`
`target.target_vendor` -> `target.vendor`
`target.target_family` -> `target.os_family`
`target.target_mcount` -> `target.mcount`

r? `@Mark-Simulacrum`
2020-11-10 14:45:21 +01:00
David Hewitt
8d43b3cbb9 Add #[cfg(panic = "...")] 2020-11-09 15:30:49 +00:00
Vadim Petrochenkov
7f9117540f Address review comments 2020-11-08 17:31:47 +03:00
Vadim Petrochenkov
dc004d4809 rustc_target: Rename some target options to avoid tautology
`target.target_endian` -> `target.endian`
`target.target_c_int_width` -> `target.c_int_width`
`target.target_os` -> `target.os`
`target.target_env` -> `target.env`
`target.target_vendor` -> `target.vendor`
`target.target_family` -> `target.os_family`
`target.target_mcount` -> `target.mcount`
2020-11-08 17:29:13 +03:00
Vadim Petrochenkov
bf66988aa1 Collapse all uses of target.options.foo into target.foo
with an eye on merging `TargetOptions` into `Target`.

`TargetOptions` as a separate structure is mostly an implementation detail of `Target` construction, all its fields logically belong to `Target` and available from `Target` through `Deref` impls.
2020-11-08 17:29:13 +03:00
Vadim Petrochenkov
c0c0597e09 Update recently added targets 2020-11-07 14:34:44 +03:00
Vadim Petrochenkov
d41fe05d1a rustc_target: Move linker_flavor from Target to TargetOptions 2020-11-07 14:27:48 +03:00
Vadim Petrochenkov
b294cc71a2 rustc_target: Move target_vendor from Target to TargetOptions 2020-11-07 14:27:47 +03:00
Vadim Petrochenkov
d5fd31197f rustc_target: Move target_env from Target to TargetOptions 2020-11-07 14:27:47 +03:00
Vadim Petrochenkov
74ffb9b4a2 rustc_target: Move target_os from Target to TargetOptions 2020-11-07 14:27:47 +03:00
Vadim Petrochenkov
91533cf10e rustc_target: Move target_endian from Target to TargetOptions 2020-11-07 14:27:46 +03:00
Vadim Petrochenkov
ffe65f825b rustc_target: Move target_c_int_width from Target to TargetOptions 2020-11-07 14:27:46 +03:00
Guillaume Gomez
55b4d21e25 Fix automatic_links warnings 2020-11-05 10:22:08 +01:00
Oli Scherer
332750f9eb
Update compiler/rustc_target/src/abi/mod.rs
Co-authored-by: Ralf Jung <post@ralfj.de>
2020-11-04 15:13:06 +01:00
Oli Scherer
5f087f089f
Update compiler/rustc_target/src/abi/mod.rs
Co-authored-by: Ralf Jung <post@ralfj.de>
2020-11-04 15:12:44 +01:00
oli
abacaf2aef u128 truncation and sign extension are not just interpreter related 2020-11-04 13:41:58 +00:00
Stephan
1a232cb976 indicate calling convention 2020-11-02 23:29:00 +01:00
Stephan
96db99a145
improve comments
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
2020-11-02 23:18:32 +01:00
Stephan
7d2441134b add blacklist for unsupported calling conventions 2020-11-02 22:52:47 +01:00
Stephan
6e58b1c3c9 add mipsel_unknown_none target 2020-11-02 19:11:24 +01:00
Joshua Nelson
57c6ed0c07 Fix even more clippy warnings 2020-10-30 10:13:39 -04:00
Jonas Schievink
fb92b70f95
Rollup merge of #77716 - francesca64:revert-ios-dynamic-linking, r=jonas-schievink
Revert "Allow dynamic linking for iOS/tvOS targets."

This reverts PR #73516.

On macOS I compile static libs for iOS, automated using [cargo-mobile](https://github.com/BrainiumLLC/cargo-mobile), which has worked smoothly for the past 2 years. However, upon updating to Rust 1.46.0, I was no longer able to use Rust on iOS. I've bisected this to the PR referenced above.

For most projects tested, apps now immediately crash with a message like this:
```
dyld: Library not loaded: /Users/francesca/Projects/example/target/aarch64-apple-ios/debug/deps/libexample.dylib
  Referenced from: /private/var/containers/Bundle/Application/745912AF-A928-465C-B340-872BD1C9F368/example.app/example
  Reason: image not found
dyld: launch, loading dependent libraries
DYLD_LIBRARY_PATH=/usr/lib/system/introspection
DYLD_INSERT_LIBRARIES=/Developer/usr/lib/libBacktraceRecording.dylib:/Developer/usr/lib/libMainThreadChecker.dylib:/Developer/Library/PrivateFrameworks/DTDDISupport.framework/libViewDebuggerSupport.dylib:/Developer/Library/PrivateFrameworks/GPUTools.framework/libglInterpose.dylib:/usr/lib/libMTLCapture.dylib
```

This can be reproduced by using cargo-mobile to generate a winit example project, and then attempting to run it on an iOS device (`cargo mobile init && cargo apple open`).

In our projects that depend on DisplayLink, the build instead fails with a linker error:
```
= note: Undefined symbols for architecture arm64:
            "_CACurrentMediaTime", referenced from:
                display_link::ios::run_callback_ios10::hda81197ff46aedbd in libapp-4f0abc1d7684103f.rlib(app-4f0abc1d7684103f.40d4iro0yz1iy487.rcgu.o)
                display_link::ios::run_callback_pre_ios10::h91f085da19374320 in libapp-4f0abc1d7684103f.rlib(app-4f0abc1d7684103f.40d4iro0yz1iy487.rcgu.o)
          ld: symbol(s) not found for architecture arm64
```

After reverting the change to enable dynamic linking on iOS, everything works the same as it did on Rust 1.45.2 for me.

In the future, would it be possible for me to be pinged when iOS-related PRs are made? I work for a company that intends on using Rust on iOS in production, so I'd gladly provide testing.

cc @aspenluxxxy
2020-10-24 14:11:59 +02:00
est31
4fa5578774 Replace target.target with target and target.ptr_width with target.pointer_width
Preparation for a subsequent change that replaces
rustc_target::config::Config with its wrapped Target.

On its own, this commit breaks the build. I don't like making
build-breaking commits, but in this instance I believe that it
makes review easier, as the "real" changes of this PR can be
seen much more easily.

Result of running:

find compiler/ -type f -exec sed -i -e 's/target\.target\([)\.,; ]\)/target\1/g' {} \;
find compiler/ -type f -exec sed -i -e 's/target\.target$/target/g' {} \;
find compiler/ -type f -exec sed -i -e 's/target.ptr_width/target.pointer_width/g' {} \;
./x.py fmt
2020-10-15 12:02:24 +02:00
est31
0d1aa1e034 Rename target_pointer_width to pointer_width and turn it into an u32
Rename target_pointer_width to pointer_width because it is already
member of the Target struct.

The compiler supports only three valid values for target_pointer_width:
16, 32, 64. Thus it can safely be turned into an int.
This means less allocations and clones as well as easier handling of the type.
2020-10-15 12:02:23 +02:00
est31
64ba25d0f2 Use integer literals for builtin target_pointer_width fields
Also change target_pointer_width to pointer_width.

Preparation for a subsequent type change of
target_pointer_width to an integer together with a rename
to pointer_width.

On its own, this commit breaks the build. I don't like making
build-breaking commits, but in this instance I believe that it
makes review easier, as the "real" changes of this PR can be
seen much more easily.

Result of running:

find compiler/rustc_target/src/spec/ -type f -exec sed -i -e 's/target_pointer_width: "\(.*\)"\..*,/pointer_width: \1,/g' {} \;
2020-10-15 12:01:53 +02:00
Dylan DPC
596235281c
Rollup merge of #77765 - amshafer:master, r=petrochenkov
Add LLVM flags to limit DWARF version to 2 on BSD

This has been a thorn in my side for a while, I can finally generate flamegraphs of rust programs on bsd again. This fixes dtrace profiling on freebsd, I think it might help with lldb as well but I can't test that because my current rust-lldb setup is messed up.

I'm limiting the dwarf version to 2 on all bsd's (netbsd/openbsd/freebsd) since it looks like this applies to all of them, but I have only tested on freebsd.

Let me know if there's anything I can improve!

---
Currently on FreeBSD dtrace profiling does not work and shows jumbled/incorrect
symbols in the backtraces. FreeBSD does not support the latest versions of DWARF
in dtrace (and lldb?) yet, and needs to be limited to DWARF2 in the same way as macos.

This adds an is_like_bsd flag since it was missing. NetBSD/OpenBSD/FreeBSD all
match this.

This effectively copies #11864 but targets FreeBSD instead of macos.
2020-10-14 02:30:34 +02:00
Austin Shafer
4511f8b9f3 Add a target option for selecting a DWARF version
Certain platforms need to limit the DWARF version emitted (oxs, *bsd). This
change adds a dwarf_version entry to the options that allows a platform to
specify the dwarf version to use. By default this option is none and the default
DWARF version is selected.

Also adds an option for printing Option<u32> json keys
2020-10-13 15:56:30 -04:00
bors
d65c08e9cc Auto merge of #75406 - mati865:mingw-aslr, r=Mark-Simulacrum
Enable ASLR for windows-gnu

Fixes https://github.com/rust-lang/rust/issues/16514
Fixes https://github.com/rust-lang/rust/issues/16593
Fixes https://github.com/rust-lang/rust/issues/17684

Passes the tests for me with x86_64 toolchain.
2020-10-13 14:12:08 +00:00
bors
7bc5839e99 Auto merge of #77337 - lzutao:asm-mips64, r=Amanieu
Add asm! support for mips64

- [x] Updated `src/doc/unstable-book/src/library-features/asm.md`.
- [ ] No vector type support. I don't know much about those types.

cc #76839
2020-10-10 17:32:28 +00:00
bors
0e022fc2b8 Auto merge of #77580 - petrochenkov:norestarg, r=matthewjasper
rustc_target: Refactor away `TargetResult`

Follow-up to https://github.com/rust-lang/rust/pull/77202.

Construction of a built-in target is always infallible now, so `TargetResult` is no longer necessary.

The second commit contains some further cleanup based on built-in target construction being infallible.
2020-10-10 09:07:35 +00:00
xd009642
a6e2b636e6 Implement the instruction_set attribute 2020-10-08 23:32:20 +01:00
Francesca Lovebloom
16e10bf81e Revert "Allow dynamic linking for iOS/tvOS targets."
This reverts commit 56e115a262.
2020-10-07 15:46:05 -07:00
Vadim Petrochenkov
1444ad7ba1 rustc_target: Further simplify loading of built-in targets
using the fact that it is infallible.

JSON roundtrip check on every rustc run is also removed, it's already performed by unit tests.
2020-10-05 19:35:26 +03:00
Vadim Petrochenkov
021fcbd90c rustc_target: Refactor away TargetResult
Construction of a built-in target is always infallible now, so `TargetResult` is no longer necessary.
2020-10-05 19:28:19 +03:00
Josh Triplett
a3944a0abd Support static linking with glibc and target-feature=+crt-static
With this change, it's possible to build on a linux-gnu target and pass
RUSTFLAGS='-C target-feature=+crt-static' or the equivalent via a
`.cargo/config.toml` file, and get a statically linked executable.

This requires libc 0.2.79, which adds support for static linking with
glibc.

Add `crt_static_respected` to the `linux_base` target spec.

Update `android_base` and `linux_musl_base` accordingly. Avoid enabling
crt_static_respected on Android platforms, since that hasn't been
tested.
2020-10-04 22:12:08 -07:00
Lzu Tao
4d570fb45e Removes reg aliases since there are many ABIs: o32/n32/n64 2020-10-04 12:01:21 +00:00