| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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`
|
|
|
|
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.
|
|
|
|
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.
|
|
Enable #[thread_local] on armv6k-nintendo-3ds
|
|
|
|
RustyHermit now maintains custom json targets, which are distributed with the kernel. [1]
[1]: https://github.com/hermitcore/libhermit-rs/pull/395
|
|
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.
|
|
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.
|
|
Signed-off-by: codehorseman <cricis@yeah.net>
|
|
Update riscv32im-unknown-none-elf to Tier2 support.
Downgrade to Tier 3 platform support.
|
|
`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.
|
|
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`
|
|
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```
|
|
|
|
|
|
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```````````````
|
|
more complete sparc64 ABI fix for aggregates with floating point members
Previous fix didn't handle nested structures at all.
|
|
Support can be determined by checking for the "d32" LLVM feature.
|
|
|
|
|
|
Checking of asm! register operands now properly takes function
attributes such as #[target_feature] and #[instruction_set] into
account.
|
|
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.
|
|
This is already handled by supported_types().
|
|
|
|
Previous fix didn't handle nested structures at all.
|
|
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.
|
|
|
|
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`
|
|
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>
|
|
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
|
|
Previously these were entirely disallowed, except for r11 which was
allowed by accident.
|
|
Upgrade to LLVM 14
LLVM patch state:
* [x] https://github.com/llvm/llvm-project/commit/a55727f334b39600bfc71144b11b42aae6b94e0b Backported.
* [x] https://github.com/rust-lang/llvm-project/commit/c3c82dc12402dd41441180c0c6cf7aed7e330c53 Backported as https://github.com/llvm/llvm-project/commit/917c47b3bf0dfc45a2a5ba12c1397d647ecf4017.
* [x] https://github.com/rust-lang/llvm-project/commit/6e8f9ab632d12271355d10d34c9835a7ba14e4b9 No plan to upstream.
* [x] https://github.com/llvm/llvm-project/commit/319f4b2d52e31b000db75a0a2484b5f2ab90534a Backported.
* [x] https://github.com/rust-lang/llvm-project/commit/8b2c25d321f877161f85218479e2d1317d770e18 No plan to upstream.
* [x] https://github.com/rust-lang/llvm-project/commit/75fef2efd427362c8f16b2d09e6ebf44069e3919 No plan to upstream.
* [ ] https://github.com/rust-lang/llvm-project/commit/adef757547de5a570d9f6a00d3e6ac16c666ab79 Upstreamed as https://github.com/llvm/llvm-project/commit/2d2ef384b2f6e723edb793d08f52e7f4dc94ba3a. Needs backport.
* [x] https://github.com/rust-lang/llvm-project/commit/4b7c1b4910e9fa9e04f23f06be078e168ef4c0ee No plan to upstream.
* [x] https://github.com/rust-lang/llvm-project/commit/3f5ab0c061adb723f25b94243828b6b5407720c8 No plan to upstream.
* [x] https://github.com/rust-lang/llvm-project/commit/514d05500e0e15e358f05f5c4cec78a805858f8e No plan to upstream.
* [ ] https://github.com/rust-lang/llvm-project/commit/54c586958564582b3341d1838a5de86541e5fecf 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`
|
|
New address spaces were added in https://reviews.llvm.org/D111154.
|
|
https://reviews.llvm.org/D115942 changed the alignment of f80.
|
|
Adds support for the LLVM MemTagSanitizer.
|
|
|
|
|
|
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`
|
|
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
|
|
|
|
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>
|
|
|
|
|
|
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.
|
|
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`
|
|
Drop json::from_reader
Just a small cleanup -- this was essentially unused; the one use site is better suited to reading from &str regardless.
|
|
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.
|
|
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>
|
