| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Necessary for the new XCode?
|
|
thumbv7neon-unknown-linux-gnueabihf
These two targets enable both thumb-mode and NEON for ARMv7 CPUs.
|
|
This adds a new rustc target-configuration called 'x86_64-unknown_uefi'.
Furthermore, it adds a UEFI base-configuration to be used with other
targets supported by UEFI (e.g., i386, armv7hl, aarch64, itanium, ...).
UEFI systems provide a very basic operating-system environment, meant
to unify how systems are booted. It is tailored for simplicity and fast
setup, as it is only meant to bootstrap other systems. For instance, it
copies most of the ABI from Microsoft Windows, rather than inventing
anything on its own. Furthermore, any complex CPU features are
disabled. Only one CPU is allowed to be up, no interrupts other than
the timer-interrupt are allowed, no process-separation is performed,
page-tables are identity-mapped, ...
Nevertheless, UEFI has an application model. Its main purpose is to
allow operating-system vendors to write small UEFI applications that
load their kernel and terminate the UEFI system. However, many other
UEFI applications have emerged in the past, including network-boot,
debug-consoles, and more.
This UEFI target allows to compile rust code natively as UEFI
applications. No standard library support is added, but libcore can be
used out-of-the-box if a panic-handler is provided. Furthermore,
liballoc works as well, if a `GlobalAlloc` handler is provided. Both
have been tested with this target-configuration.
Note that full libstd support is unlikely to happen. While UEFI does
have standardized interfaces for networking and alike, none of these
are mandatory and they are unlikely to be shipped in common consumer
firmwares. Furthermore, several features like process-separation are
not available (or only in very limited fashion). Those parts of libstd
would have to be masked.
|
|
|
|
|
|
|
|
Add Armv8-M Mainline targets
This commit enables the Armv8-M Mainline architecture profile.
It adds two targets:
- `thumbv8m.main-none-eabi`
- `thumbv8m.main-none-eabihf`
The second one uses the Floating Point Unit for floating point
operations. It mainly targets the Cortex-M33 processor, which
can have the optional Floating Point Unit extension.
It follows #55041 which does it for Baseline. I will rebase this branch on top of it when it is merged to not create conflicts as we have some files in common. To make it work, it still relies on the Cargo change to be merged (accepting "." in target names, rust-lang/cargo#6255).
The goal would also be to add this target in the CI so that the `core` library is available for everybody. To do this, some changes will be needed to compile successfully the needed libraries:
* `cc-rs` needs to be updated to allow compiling C code for Armv8-M architectures profiles. It is only a few lines to add [here](https://github.com/alexcrichton/cc-rs/blob/a76611ad9836fa8c44fa8220a1d2a96dd3b7d4b6/src/lib.rs#L1299).
* Some assembly files in `builtins` in `compiler-rt` were not assembling for Armv8-M Mainline. I sent changes [upstream](https://reviews.llvm.org/D51854) to that project to fix that. The Rust version of `compiler-rt` will have to be updated to contain [that commit](https://github.com/llvm-mirror/compiler-rt/commit/a34cdf8bb498dc2f5dd415542f8e83261d2eeb88).
I tested it using the [Musca-A Test Chip board](https://developer.arm.com/products/system-design/development-boards/iot-test-chips-and-boards/musca-a-test-chip-board) but more intensively on the [Armv8-M FVP](https://developer.arm.com/products/system-design/fixed-virtual-platforms) (emulation platform). I am going to try to release my test code soon, once I tidy it up :+1:
|
|
This commit enables the Armv8-M Mainline architecture profile.
It adds two targets:
- thumbv8m.main-none-eabi
- thumbv8m.main-none-eabihf
The second one uses the Floating Point Unit for floating point
operations. It mainly targets the Cortex-M33 processor, which
can have the optional Floating Point Unit extension.
|
|
|
|
targets: thumbv8m: Add target for baseline ARMv8-M
Tested against a SAM L11 MCU.
|
|
|
|
|
|
Pass additional linker flags when targeting Fuchsia
This is a follow up to 8aa9267 which changed the driver to use lld
directly rather than invoking it through Clang. This change ensures
we pass all the necessary flags to lld.
|
|
rustc_target: separate out an individual alignment quantity type from Align.
Before this PR, `rustc_target::abi::Align` combined "power-of-two alignment quantity" semantics, with a distinction between ABI (required) and preferred alignment (by having two quantities).
After this PR, `Align` is only *one* such quantity, and a new `AbiAndPrefAlign` type is introduced to hold the pair of ABI and preferred `Align` quantities.
`Align` is used everywhere one quantity is necessary/sufficient, simplifying some of the code in codegen/miri, while `AbiAndPrefAlign` only in layout computation (to propagate preferred alignment).
r? @oli-obk cc @nagisa @RalfJung @nikomatsakis
|
|
Add SGX target to rustc
This adds the `x86_64-fortanix-unknown-sgx` target specification to the Rust compiler. See #56066 for more details about this target.
|
|
This is a follow up to 8aa9267 which changed the driver to use lld
directly rather than invoking it through Clang. This change ensures
we pass all the necessary flags to lld.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The requirements here are not "ELFv1" requirements, but big-endian
requirements, as the extension or non-extension of the argument is
necessary to put the argument in the correct half of the register.
Parameter passing in the ELFv2 ABI needs these same transformations.
Since this code makes no difference on little-endian machines, simplify
it to use the same code path everywhere.
|
|
|
|
|
|
|
|
This commit cleans up allocator injection logic found in the compiler
around selecting the global allocator. It turns out that now that
jemalloc is gone the compiler never actually injects anything! This
means that basically everything around loading crates here and there can
be easily pruned.
This also removes the `exe_allocation_crate` option from custom target
specs as it's no longer used by the compiler anywhere.
|
|
Rollup of 17 pull requests
Successful merges:
- #55630 (resolve: Filter away macro prelude in modules with `#[no_implicit_prelude]` on 2018 edition)
- #55687 (Take supertraits into account when calculating associated types)
- #55745 (Convert `outlives_components`' return value to a `SmallVec` outparam.)
- #55764 (Fix Rc/Arc allocation layout)
- #55792 (Prevent ICE in const-prop array oob check)
- #55799 (Removed unneeded instance of `// revisions` from a lint test)
- #55800 (Fix ICE in `return_type_impl_trait`)
- #55801 (NLL: Update box insensitivity test)
- #55802 (Don't inline virtual calls (take 2))
- #55816 (Use `SmallVec` to avoid allocations in `from_decimal_string`.)
- #55819 (Typecheck patterns of all match arms first, so we get types for bindings)
- #55822 (ICE with #![feature(nll)] and elided lifetimes)
- #55828 (Add missing `rustc_promotable` attribute to unsigned `min_value` and `max_value`)
- #55839 (Fix docstring spelling mistakes)
- #55844 (Fix documentation typos.)
- #55845 (Set BINARYEN_TRAP_MODE=clamp)
- #55856 (rustdoc: refactor: move all static-file include!s into a single module)
|
|
Support for the program data address space option of LLVM's Target Datalayout
This was introduced recently (specifically, for AVR, cc @dylanmckay).
(I came up with this when attempting to run [avr-rust](https://github.com/avr-rust/rust) rebased on the latest [rust-lang](https://github.com/rust-lang/rust) commits. If this requires a different design, some additional discussions, or is not something to pursue right now, I'd be happy to close this PR).
Note that this somewhat overlaps with @DiamondLovesYou's #51576, I think, although the implementation here is significantly simpler: Since the address space applies to _all_ program data, we can just check the pointee's type whenever we create an LLVM pointer type. If it is a function we use the program data address space; if not we use the default address space.
cc @eddyb, who has been reviewing #51576
Ref: https://llvm.org/docs/LangRef.html#data-layout
|
|
This avoids trapping in the -Zsaturating-float-casts implementation.
|
|
rustc: Delete grouping logic from the musl target
This commit deletes the injection of `-(` and `-)` options to the linker
for the musl targets. This actually causes problems today on nightly if
you execute:
$ echo 'fn main() {}' >> foo.rs
$ rustc --target x86_64-unknown-linux-musl -C panic=abort
you get a linker error about "cannot nest groups". This comes about
because rustc injects its own `--start-group` and `--end-group`
variables which clash with the outer `-(` and `-)` variables. It's not
entirely clear to me why this doesn't affect the musl target by default
(in `-C panic=unwind` mode).
The compiler's own injection of `--start-group` and `--end-group` should
solve the issues mentioned in the comment for injecting `-(` and `-)` as
well.
|
|
of LLVM's Target Datalayout.
https://llvm.org/docs/LangRef.html#data-layout
|
|
Use lld directly for Fuchsia target
Fuchsia already uses lld as the default linker, so there's no reason
to always invoke it through Clang, instead we can simply invoke lld
directly and pass the set of flags that matches Clang.
|
|
Fuchsia already uses lld as the default linker, so there's no reason
to always invoke it through Clang, instead we can simply invoke lld
directly and pass the set of flags that matches Clang.
|
|
|
|
This commit deletes the injection of `-(` and `-)` options to the linker
for the musl targets. This actually causes problems today on nightly if
you execute:
$ echo 'fn main() {}' >> foo.rs
$ rustc --target x86_64-unknown-linux-musl -C panic=abort
you get a linker error about "cannot nest groups". This comes about
because rustc injects its own `--start-group` and `--end-group`
variables which clash with the outer `-(` and `-)` variables. It's not
entirely clear to me why this doesn't affect the musl target by default
(in `-C panic=unwind` mode).
The compiler's own injection of `--start-group` and `--end-group` should
solve the issues mentioned in the comment for injecting `-(` and `-)` as
well.
|
|
This commit adds opt-in support to the compiler to link to `jemalloc` in
the compiler. When activated the compiler will depend on `jemalloc-sys`,
instruct jemalloc to unprefix its symbols, and then link to it. The
feature is activated by default on Linux/OSX compilers for x86_64/i686
platforms, and it's not enabled anywhere else for now. We may be able to
opt-in other platforms in the future! Also note that the opt-in only
happens on CI, it's otherwise unconditionally turned off by default.
Closes #36963
|
|
This commit removes all jemalloc related submodules, configuration, etc,
from the bootstrap, from the standard library, and from the compiler.
This will be followed up with a change to use jemalloc specifically as
part of rustc on blessed platforms.
|
|
* Also update the bootstrap compiler
* Update cargo to 1.32.0
* Clean out stage0 annotations
|
|
PR #51953 enabled the Atomic*.{load,store} API on MSP430. Unfortunately, the
LLVM backend doesn't currently support those atomic operations, so this commit
removes the API and leaves instructions on how and when to enable it in the
future.
|
|
|
|
|
|
|
|
|
|
|
|
The upcoming SIMD support in the wasm target is unique from the other
platforms where it's either unconditionally available or not available,
there's no halfway where a subsection of the program can use it but no
other parts of the program can use it. In this world it's valid for wasm
SIMD args to always be passed by value and there's no need to pass them
by reference.
This commit adds a new custom target specification option
`simd_types_indirect` which defaults to `true`, but the wasm backend
disables this and sets it to `false`.
|
|
impl Eq+Hash for TyLayout
As proposed by @eddyb at https://github.com/rust-lang/rust/pull/53671#pullrequestreview-159761136.
I have an upcoming PR that would also significantly benefit from this.
|
|
Disable the PLT where possible to improve performance
for indirect calls into shared libraries.
This optimization is enabled by default where possible.
- Add the `NonLazyBind` attribute to `rustllvm`:
This attribute informs LLVM to skip PLT calls in codegen.
- Disable PLT unconditionally:
Apply the `NonLazyBind` attribute on every function.
- Only enable no-plt when full relro is enabled:
Ensures we only enable it when we have linker support.
- Add `-Z plt` as a compiler option
|
|
|
