| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Most of the Rust community agrees that the vec! macro is clearer when
called using square brackets [] instead of regular brackets (). Most of
these ocurrences are from before macros allowed using different types of
brackets.
There is one left unchanged in a pretty-print test, as the pretty
printer still wants it to have regular brackets.
|
|
|
|
Disable jemalloc on aarch64/powerpc
Sounds like jemalloc is broken on systems which differ in page size than the
host it was compiled on (unless an option was passed). This unfortunately
reduces the portability of binaries created and can often make Rust segfault by
default. For now let's patch over this by disabling jemalloc until we can figure
out a better solution.
Closes #36994
Closes #37320
cc jemalloc/jemalloc#467
|
|
Support for aarch64 architecture on Fuchsia
This patch adds support for the aarch64-unknown-fuchsia target. Also
updates src/liblibc submodule to include required libc change.
|
|
Sounds like jemalloc is broken on systems which differ in page size than the
host it was compiled on (unless an option was passed). This unfortunately
reduces the portability of binaries created and can often make Rust segfault by
default. For now let's patch over this by disabling jemalloc until we can figure
out a better solution.
Closes #36994
Closes #37320
cc jemalloc/jemalloc#467
|
|
check target abi support
This PR checks for each extern function / block whether the ABI / calling convention used is supported by the current target.
This was achieved by adding an `abi_blacklist` field to the target specifications, listing the calling conventions unsupported for that target.
|
|
This patch adds support for the aarch64-unknown-fuchsia target. Also
updates src/liblibc submodule to include required libc change.
|
|
|
|
Prefer FIXME to TODO
|
|
Adds support for the x86_64-unknown-fuchsia target, which covers the
Fuchsia operating system.
|
|
cc [`?` tracking issue](https://github.com/rust-lang/rust/issues/31436)
|
|
rustc: Try again to disable NEON on armv7 linux
This is a follow-up to #35814 which apparently didn't disable it hard enough. It
looks like LLVM's default armv7 target enables NEON so we'd otherwise have to
pass `-neon`, but we're already enabling armv7 with `+v7` supposedly, so let's
try just telling LLVM that the armv7 target is arm and then enable features
selectively.
Closes #36913
|
|
This is a follow-up to #35814 which apparently didn't disable it hard enough. It
looks like LLVM's default armv7 target enables NEON so we'd otherwise have to
pass `-neon`, but we're already enabling armv7 with `+v7` supposedly, so let's
try just telling LLVM that the armv7 target is arm and then enable features
selectively.
Closes #36913
|
|
to better express the idea that omitting this field defaults this value
to target_pointer_width
|
|
|
|
|
|
|
|
|
|
|
|
this commit adds 4 new target definitions to the compiler for easier
cross compilation to ARM Cortex-M devices.
- `thumbv6m-none-eabi`
- For the Cortex-M0, Cortex-M0+ and Cortex-M1
- This architecture doesn't have hardware support (instructions) for
atomics. Hence, the `Atomic*` structs are not available for this
target.
- `thumbv7m-none-eabi`
- For the Cortex-M3
- `thumbv7em-none-eabi`
- For the FPU-less variants of the Cortex-M4 and Cortex-M7
- On this target, all the floating point operations will be lowered
software routines (intrinsics)
- `thumbv7em-none-eabihf`
- For the variants of the Cortex-M4 and Cortex-M7 that do have a FPU.
- On this target, all the floating point operations will be lowered
to hardware instructions
No binary releases of standard crates, like `core`, are planned for
these targets because Cargo, in the future, will compile e.g. the `core`
crate on the fly as part of the `cargo build` process. In the meantime,
you'll have to compile the `core` crate yourself. [Xargo] is the easiest
way to do that as in handles the compilation of `core` automatically and
can be used just like Cargo: `xargo build --target thumbv6m-none-eabi`
is all that's needed.
[Xargo]: https://crates.io/crates/xargo
|
|
Haiku: Fix target triplet delimiter
|
|
|
|
|
|
|
|
add a panic-strategy field to the target specification
Now a target can define its panic strategy in its specification. If a
user doesn't specify a panic strategy via the command line, i.e. '-C
panic', then the compiler will use the panic strategy defined by the
target specification.
Custom targets can pick their panic strategy via the "panic-strategy"
field of their target specification JSON file. If omitted in the
specification, the strategy defaults to "unwind".
closes #36647
---
I checked that compiling an executable for a custom target with "panic-strategy" set to "abort" doesn't need the "eh_personality" lang item and also that standard crates compiled for that custom target didn't contained undefined symbols to _Unwind_Resume. But this needs an actual unit test, any suggestion on how to test this?
Most of the noise in the diff is due to moving `PanicStrategy` from the `rustc` to the `rustc_back` crate.
r? @alexcrichton
cc @phil-opp
|
|
|
|
Now a target can define its panic strategy in its specification. If a
user doesn't specify a panic strategy via the command line, i.e. '-C
panic', then the compiler will use the panic strategy defined by the
target specification.
Custom targets can pick their panic strategy via the "panic-strategy"
field of their target specification JSON file. If omitted in the
specification, the strategy defaults to "unwind".
closes #36647
|
|
|
|
* Hand rebased from Niels original work on 1.9.0
|
|
|
|
Replace try! with ?.
|
|
libcompiler-rt.a is dead, long live libcompiler-builtins.rlib
This commit moves the logic that used to build libcompiler-rt.a into a
compiler-builtins crate on top of the core crate and below the std crate.
This new crate still compiles the compiler-rt instrinsics using gcc-rs
but produces an .rlib instead of a static library.
Also, with this commit rustc no longer passes -lcompiler-rt to the
linker. This effectively makes the "no-compiler-rt" field of target
specifications a no-op. Users of `no_std` will have to explicitly add
the compiler-builtins crate to their crate dependency graph *if* they
need the compiler-rt intrinsics. Users of the `std` have to do nothing
extra as the std crate depends on compiler-builtins.
Finally, this a step towards lazy compilation of std with Cargo as the
compiler-rt intrinsics can now be built by Cargo instead of having to
be supplied by the user by some other method.
closes #34400
|
|
|
|
This adds support for building the Rust compiler and standard
library for s390x-linux, allowing a full cross-bootstrap sequence
to complete. This includes:
- Makefile/configure changes to allow native s390x builds
- Full Rust compiler support for the s390x C ABI
(only the non-vector ABI is supported at this point)
- Port of the standard library to s390x
- Update the liblibc submodule to a version including s390x support
- Testsuite fixes to allow clean "make check" on s390x
Caveats:
- Resets base cpu to "z10" to bring support in sync with the default
behaviour of other compilers on the platforms. (Usually, upstream
supports all older processors; a distribution build may then chose
to require a more recent base version.) (Also, using zEC12 causes
failures in the valgrind tests since valgrind doesn't fully support
this CPU yet.)
- z13 vector ABI is not yet supported. To ensure compatible code
generation, the -vector feature is passed to LLVM. Note that this
means that even when compiling for z13, no vector instructions
will be used. In the future, support for the vector ABI should be
added (this will require common code support for different ABIs
that need different data_layout strings on the same platform).
- Two test cases are (temporarily) ignored on s390x to allow passing
the test suite. The underlying issues still need to be fixed:
* debuginfo/simd.rs fails because of incorrect debug information.
This seems to be a LLVM bug (also seen with C code).
* run-pass/union/union-basic.rs simply seems to be incorrect for
all big-endian platforms.
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
|
|
add mips64-gnu and mips64el-gnu targets
With this commit one can build no_core (and probably no_std as well)
Rust programs for these targets. It's not yet possible to cross compile
std for these targets because rust-lang/libc doesn't know about the
mips64 architecture.
These targets have been tested by cross compiling the "smallest hello"
program (see code below) and then running it under QEMU.
``` rust
extern {
fn puts(_: *const u8);
}
fn start(_: isize, _: *const *const u8) -> isize {
unsafe {
let msg = b"Hello, world!\0";
puts(msg as *const _ as *const u8);
}
0
}
trait Copy {}
trait Sized {}
```
cc #36015
r? @alexcrichton
cc @brson
The cabi stuff is likely wrong. I just copied cabi_mips source and changed some `4`s to `8`s and `32`s to `64`s. It was enough to get libc's `puts` to work but I'd like someone familiar with this module to check it.
|
|
|
|
A new target, `s390x-unknown-linux-gnu`, has been added to the compiler
and can be used to build no_core/no_std Rust programs.
Known limitations:
- librustc_trans/cabi_s390x.rs is missing. This means no support for
`extern "C" fn`.
- No support for this arch in libc. This means std can be cross compiled
for this target.
|
|
With this commit one can build no_core (and probably no_std as well)
Rust programs for these targets. It's not yet possible to cross compile
std for these targets because rust-lang/libc doesn't know about the
mips64 architecture.
These targets have been tested by cross compiling the "smallest hello"
program (see code below) and then running it under QEMU.
``` rust
#![feature(start)]
#![feature(lang_items)]
#![feature(no_core)]
#![no_core]
#[link(name = "c")]
extern {
fn puts(_: *const u8);
}
#[start]
fn start(_: isize, _: *const *const u8) -> isize {
unsafe {
let msg = b"Hello, world!\0";
puts(msg as *const _ as *const u8);
}
0
}
#[lang = "copy"]
trait Copy {}
#[lang = "sized"]
trait Sized {}
```
|
|
One of the primary platforms for the `armv7-unknown-linux-gnueabihf` target,
Linux distributions, do not enable NEON extensions by default. This PR disables
that feature by defualt but enables the `d16` feature which enables VFP3D16 that
distributions do enable.
Closes #35590
|
|
These targets cover OpenWRT 15.05 devices, which use the soft float ABI
and the uclibc library. None of the other built-in mips targets covered
those devices (mips-gnu is hard float and glibc-based, mips-musl is
musl-based).
With this commit one can now build std for these devices using these
commands:
```
$ configure --enable-rustbuild --target=mips-unknown-linux-uclibc
$ make
```
cc #35673
|
|
|
|
Rollup of 8 pull requests
- Successful merges: #34802, #35033, #35085, #35114, #35134, #35140, #35141, #35157
- Failed merges:
|
|
Use "x86-64" as the target CPU for NetBSD and Bitrig on amd64.
Using "generic" disables a number of features that are present on all
x86_64 cpus, the "x86-64" target cpu is the common denominator for that
arch.
Refs #20777
|
|
LLVM upgrade
As discussed in https://internals.rust-lang.org/t/need-help-with-emscripten-port/3154/46 I'm trying to update the used LLVM checkout in Rust.
I basically took @shepmaster's code and applied it on top (though I did the commits manually, the [original commits have better descriptions](https://github.com/rust-lang/rust/compare/master...avr-rust:avr-support).
With these changes I was able to build rustc. `make check` throws one last error on `run-pass/issue-28950.rs`. Output: https://gist.github.com/badboy/bcdd3bbde260860b6159aa49070a9052
I took the metadata changes as is and they seem to work, though it now uses the module in another step. I'm not sure if this is the best and correct way.
Things to do:
* [x] ~~Make `run-pass/issue-28950.rs` pass~~ unrelated
* [x] Find out how the `PositionIndependentExecutable` setting is now used
* [x] Is the `llvm::legacy` still the right way to do these things?
cc @brson @alexcrichton
|
|
|
|
|
|
it's the same as linux_musl_base
|
|
|
|
|
