Commit Graph

675 Commits

Author SHA1 Message Date
bors
df20355fa9 Auto merge of #95456 - RalfJung:size, r=oli-obk
allow large Size again

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MIPS64 targets under OpenWrt require soft-float fpu support.

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

Set explicit soft-float for tuple.

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

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

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

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

# Usage

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

# Comments/Caveats

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

# TODO

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

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

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

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

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

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

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

Fixes (partially) #74378.

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

Successful merges:

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

Failed merges:

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

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

Set explicit soft-float for tuple.

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

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

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

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

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

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

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

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

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

Tier 3 tuple for Mips64 OpenWrt toolchain.

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

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

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

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

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

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

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

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

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

- L4-bender does not yet support dynamic linking.

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

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

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

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

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

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

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

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

Successful merges:

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

Failed merges:

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

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

Best reviewed one commit at a time.

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

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

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

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

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

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

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

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

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

Done.

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

Done

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

Done.

* The target must not introduce license incompatibilities.

Done.

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

Fine with me.

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

Done.

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

Done.

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

Done.

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

Fine with me.

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

Ok.

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

Ok.

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

std is implemented.

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

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

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

Ok.

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

Ok.

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

Ok.

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

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

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

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

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

Fixes #90342, #91082.

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

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

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

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

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

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

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

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

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

Extra commits during review:

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

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

- [address-review] correct grammar in comment

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

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

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

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

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

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

- add an explicit `none` stack-protector option

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

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

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

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

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

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

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

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

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

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

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

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

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

I don't believe there is any ambiguity here.

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

I don't see any legal issues here.

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

I see no issues with any of the above.

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

Only relevant to those making approval decisions.

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

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

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

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

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

I don't foresee this being a problem.

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

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

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

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

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

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

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

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

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

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

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

Fix #90038

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

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

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

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

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

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

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

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

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

# New Targets

The following targets are added:

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

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

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

# C Compiler

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

# Unresolved Questions

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

# Unsupported or Unimplemented Features

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

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

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

## Dynamic Linking

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

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

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

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

## Executable

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

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

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

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

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

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

Example:
```rust

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

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

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

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

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

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

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

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

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