Commit Graph

1924 Commits

Author SHA1 Message Date
bors e3bcddb44b Auto merge of #31078 - nbaksalyar:illumos, r=alexcrichton
This pull request adds support for [Illumos](http://illumos.org/)-based operating systems: SmartOS, OpenIndiana, and others. For now it's x86-64 only, as I'm not sure if 32-bit installations are widespread. This PR is based on #28589 by @potatosalad, and also closes #21000, #25845, and #25846.

Required changes in libc are already merged: https://github.com/rust-lang-nursery/libc/pull/138

Here's a snapshot required to build a stage0 compiler:
https://s3-eu-west-1.amazonaws.com/nbaksalyar/rustc-sunos-snapshot.tar.gz
It passes all checks from `make check`.

There are some changes I'm not quite sure about, e.g. macro usage in `src/libstd/num/f64.rs` and `DirEntry` structure in `src/libstd/sys/unix/fs.rs`, so any comments on how to rewrite it better would be greatly appreciated.

Also, LLVM configure script might need to be patched to build it successfully, or a pre-built libLLVM should be used. Some details can be found here: https://llvm.org/bugs/show_bug.cgi?id=25409

Thanks!

r? @brson
2016-02-03 22:40:32 +00:00
Alex Crichton 178d4b0fd3 Revert "mk: fix some undefined variable warnings"
This reverts commit d03712977d.
2016-02-01 23:27:04 -08:00
bors 7cae6b59b4 Auto merge of #30367 - tamird:fix-makefile-bugs, r=alexcrichton
Some of this is scary stuff. Probably time to lint against this.

Found with `make --warn-undefined-variables`.

r? @alexcrichton
2016-02-01 18:27:54 +00:00
bors 91e804409b Auto merge of #31303 - alexcrichton:mips-warnings, r=aturon
Currently any compilation to MIPS spits out the warning:

    'generic' is not a recognized processor for this target (ignoring processor)

Doesn't make for a great user experience! We don't encounter this in the normal
bootstrap because the cpu/feature set are set by the makefiles. Instead let's
just propagate these to the defaults for the entire target all the time (still
overridable from the command line) and prevent warnings from being emitted by
default.
2016-02-01 12:24:01 +00:00
Tamir Duberstein d03712977d mk: fix some undefined variable warnings
Some of this is scary stuff. Probably time to lint against this.

Found with `make --warn-undefined-variables`.
2016-02-01 05:21:06 -05:00
petevine 2efd024ad3 Fix the armv7 linux target 2016-01-31 22:26:34 +01:00
Nikita Baksalyar f189d7a693
Add Illumos support 2016-01-31 18:57:26 +03:00
bors 9041b93058 Auto merge of #31298 - japaric:mips-musl, r=alexcrichton
This target covers MIPS devices that run the trunk version of OpenWRT.

The x86_64-unknown-linux-musl target always links statically to C libraries. For
the mips(el)-unknown-linux-musl target, we opt for dynamic linking (like most of
other targets do) to keep binary size down.

As for the C compiler flags used in the build system, we use the same flags used
for the mips(el)-unknown-linux-gnu target.

r? @alexcrichton
2016-01-31 12:27:06 +00:00
Jorge Aparicio 64ac041b1f rustc: set MIPS cpu/features in the compiler
cf #31303
2016-01-30 14:44:40 -05:00
Jorge Aparicio 146dfce803 revert changes used for local testing 2016-01-30 14:44:38 -05:00
bors 9bda7ea81d Auto merge of #31274 - brson:nobench, r=nikomatsakis
I don't believe these test cases have served any purpose in years.

The shootout benchmarks are now upstreamed. A new benchmark suite
should rather be maintained out of tree.

r? @nikomatsakis
2016-01-30 14:50:44 +00:00
Manish Goregaokar 5ff52dbf2f Rollup merge of #31290 - alexcrichton:fix-powerpc64, r=brson
We forgot to pass down the `-m64` flag to gcc, so we were actually compiling
powerpc code which would then later fail to link!
2016-01-30 17:57:16 +05:30
Alex Crichton 0316013b49 rustc: Set MIPS cpu/features in the compiler
Currently any compilation to MIPS spits out the warning:

    'generic' is not a recognized processor for this target (ignoring processor)

Doesn't make for a great user experience! We don't encounter this in the normal
bootstrap because the cpu/feature set are set by the makefiles. Instead let's
just propagate these to the defaults for the entire target all the time (still
overridable from the command line) and prevent warnings from being emitted by
default.
2016-01-29 23:44:46 -08:00
bors 303892ee15 Auto merge of #30448 - alexcrichton:llvmup, r=nikomatsakis
These commits perform a few high-level changes with the goal of enabling i686 MSVC unwinding:

* LLVM is upgraded to pick up the new exception handling instructions and intrinsics for MSVC. This puts us somewhere along the 3.8 branch, but we should still be compatible with LLVM 3.7 for non-MSVC targets.
* All unwinding for MSVC targets (both 32 and 64-bit) are implemented in terms of this new LLVM support. I would like to also extend this to Windows GNU targets to drop the runtime dependencies we have on MinGW, but I'd like to land this first.
* Some tests were fixed up for i686 MSVC here and there where necessary. The full test suite should be passing now for that target.

In terms of landing this I plan to have this go through first, then verify that i686 MSVC works, then I'll enable `make check` on the bots for that target instead of just `make` as-is today.

Closes #25869
2016-01-30 00:25:44 +00:00
Alex Crichton 58f1b9c7fc Get tests working on MSVC 32-bit 2016-01-29 16:25:21 -08:00
Jorge Aparicio 7b026f0355 add support for mips(el)-unknown-linux-musl
This target covers MIPS devices that run the trunk version of OpenWRT.

The x86_64-unknown-linux-musl target always links statically to C libraries. For
the mips(el)-unknown-linux-musl target, we opt for dynamic linking (like most of
other targets do) to keep binary size down.

As for the C compiler flags used in the build system, we use the same flags used
for the mips(el)-unknown-linux-gnu target.
2016-01-29 18:46:25 -05:00
Brian Anderson 005c9624bb Remove src/test/bench
I don't believe these test cases have served any purpose in years.

The shootout benchmarks are now upstreamed. A new benchmark suite
should rather be maintained out of tree.
2016-01-29 21:54:30 +00:00
Alex Crichton ea31ff20f0 mk: Fix cross-compiling to armv7-unknown-linux-gnu
The cross prefix was not likely the actual compiler that needed to be used, but
rather the standard `arm-linux-gnueabihf-gcc` compiler can just be used with
`-march=armv7`.
2016-01-29 12:36:45 -08:00
Alex Crichton 7e1acc57d8 mk: Fix compiling jemalloc for powerpc64
We forgot to pass down the `-m64` flag to gcc, so we were actually compiling
powerpc code which would then later fail to link!
2016-01-29 12:23:17 -08:00
Manish Goregaokar 7a0e490bdd Rollup merge of #31276 - alexcrichton:fix-powerpc64-cross-prefix, r=brson
Looks like the way to create these executables is to use the standard
`powerpc-linux-gnu-gcc` compiler but with the `-m64` option.
2016-01-29 20:19:39 +05:30
Manish Goregaokar cbfc5e3704 Rollup merge of #31252 - alexcrichton:ios-old-mac, r=brson
Unfortunately older clang compilers don't support this argument, so the
bootstrap will fail. We don't actually really need to optimized the C code we
compile, however, as currently we're just compiling jemalloc and not much else.
2016-01-29 20:19:38 +05:30
bors 7bd87c1f1b Auto merge of #30948 - fabricedesre:rpi2, r=alexcrichton
This adds support for the armv7 crosstool-ng toolchain for the Raspberry Pi 2.

Getting the toolchain ready:
Checkout crosstool-ng from https://github.com/crosstool-ng/crosstool-ng
Build crosstool-ng
Configure the rpi2 target with |ct-ng armv7-rpi2-linux-gnueabihf|
Build the toolchain with |ct-build| and add the path to $toolchain_install_dir/bin to your $PATH

Then, on the rust side:
configure --target=armv7-rpi2-linux-gnueabihf && make && make install

To cross compile for the rpi2,
add $rust_install_path/lib to your $LD_LIBRARY_PATH, then use
rustc --target=armv7-rpi2-linux-gnueabihf -C linker=armv7-rpi2-linux-gnueabihf-g++ hello.rs
2016-01-29 06:41:22 +00:00
Alex Crichton ba97b06609 mk: Fix cross prefix for powerpc64
Looks like the way to create these executables is to use the standard
`powerpc-linux-gnu-gcc` compiler but with the `-m64` option.
2016-01-28 21:50:29 -08:00
bors 53c2933d44 Auto merge of #30900 - michaelwoerister:trans_item_collect, r=nikomatsakis
The purpose of the translation item collector is to find all monomorphic instances of functions, methods and statics that need to be translated into LLVM IR in order to compile the current crate.

So far these instances have been discovered lazily during the trans path. For incremental compilation we want to know the set of these instances in advance, and that is what the trans::collect module provides.
In the future, incremental and regular translation will be driven by the collector implemented here.

r? @nikomatsakis
cc @rust-lang/compiler

Translation Item Collection
===========================

This module is responsible for discovering all items that will contribute to
to code generation of the crate. The important part here is that it not only
needs to find syntax-level items (functions, structs, etc) but also all
their monomorphized instantiations. Every non-generic, non-const function
maps to one LLVM artifact. Every generic function can produce
from zero to N artifacts, depending on the sets of type arguments it
is instantiated with.
This also applies to generic items from other crates: A generic definition
in crate X might produce monomorphizations that are compiled into crate Y.
We also have to collect these here.

The following kinds of "translation items" are handled here:

 - Functions
 - Methods
 - Closures
 - Statics
 - Drop glue

The following things also result in LLVM artifacts, but are not collected
here, since we instantiate them locally on demand when needed in a given
codegen unit:

 - Constants
 - Vtables
 - Object Shims

General Algorithm
-----------------
Let's define some terms first:

 - A "translation item" is something that results in a function or global in
   the LLVM IR of a codegen unit. Translation items do not stand on their
   own, they can reference other translation items. For example, if function
   `foo()` calls function `bar()` then the translation item for `foo()`
   references the translation item for function `bar()`. In general, the
   definition for translation item A referencing a translation item B is that
   the LLVM artifact produced for A references the LLVM artifact produced
   for B.

 - Translation items and the references between them for a directed graph,
   where the translation items are the nodes and references form the edges.
   Let's call this graph the "translation item graph".

 - The translation item graph for a program contains all translation items
   that are needed in order to produce the complete LLVM IR of the program.

The purpose of the algorithm implemented in this module is to build the
translation item graph for the current crate. It runs in two phases:

 1. Discover the roots of the graph by traversing the HIR of the crate.
 2. Starting from the roots, find neighboring nodes by inspecting the MIR
    representation of the item corresponding to a given node, until no more
    new nodes are found.

The roots of the translation item graph correspond to the non-generic
syntactic items in the source code. We find them by walking the HIR of the
crate, and whenever we hit upon a function, method, or static item, we
create a translation item consisting of the items DefId and, since we only
consider non-generic items, an empty type-substitution set.

Given a translation item node, we can discover neighbors by inspecting its
MIR. We walk the MIR and any time we hit upon something that signifies a
reference to another translation item, we have found a neighbor. Since the
translation item we are currently at is always monomorphic, we also know the
concrete type arguments of its neighbors, and so all neighbors again will be
monomorphic. The specific forms a reference to a neighboring node can take
in MIR are quite diverse. Here is an overview:

The most obvious form of one translation item referencing another is a
function or method call (represented by a CALL terminator in MIR). But
calls are not the only thing that might introduce a reference between two
function translation items, and as we will see below, they are just a
specialized of the form described next, and consequently will don't get any
special treatment in the algorithm.

A function does not need to actually be called in order to be a neighbor of
another function. It suffices to just take a reference in order to introduce
an edge. Consider the following example:

```rust
fn print_val<T: Display>(x: T) {
    println!("{}", x);
}

fn call_fn(f: &Fn(i32), x: i32) {
    f(x);
}

fn main() {
    let print_i32 = print_val::<i32>;
    call_fn(&print_i32, 0);
}
```
The MIR of none of these functions will contain an explicit call to
`print_val::<i32>`. Nonetheless, in order to translate this program, we need
an instance of this function. Thus, whenever we encounter a function or
method in operand position, we treat it as a neighbor of the current
translation item. Calls are just a special case of that.

In a way, closures are a simple case. Since every closure object needs to be
constructed somewhere, we can reliably discover them by observing
`RValue::Aggregate` expressions with `AggregateKind::Closure`. This is also
true for closures inlined from other crates.

Drop glue translation items are introduced by MIR drop-statements. The
generated translation item will again have drop-glue item neighbors if the
type to be dropped contains nested values that also need to be dropped. It
might also have a function item neighbor for the explicit `Drop::drop`
implementation of its type.

A subtle way of introducing neighbor edges is by casting to a trait object.
Since the resulting fat-pointer contains a reference to a vtable, we need to
instantiate all object-save methods of the trait, as we need to store
pointers to these functions even if they never get called anywhere. This can
be seen as a special case of taking a function reference.

Since `Box` expression have special compiler support, no explicit calls to
`exchange_malloc()` and `exchange_free()` may show up in MIR, even if the
compiler will generate them. We have to observe `Rvalue::Box` expressions
and Box-typed drop-statements for that purpose.

Interaction with Cross-Crate Inlining
-------------------------------------
The binary of a crate will not only contain machine code for the items
defined in the source code of that crate. It will also contain monomorphic
instantiations of any extern generic functions and of functions marked with
The collection algorithm handles this more or less transparently. When
constructing a neighbor node for an item, the algorithm will always call
`inline::get_local_instance()` before proceeding. If no local instance can
be acquired (e.g. for a function that is just linked to) no node is created;
which is exactly what we want, since no machine code should be generated in
the current crate for such an item. On the other hand, if we can
successfully inline the function, we subsequently can just treat it like a
local item, walking it's MIR et cetera.

Eager and Lazy Collection Mode
------------------------------
Translation item collection can be performed in one of two modes:

 - Lazy mode means that items will only be instantiated when actually
   referenced. The goal is to produce the least amount of machine code
   possible.

 - Eager mode is meant to be used in conjunction with incremental compilation
   where a stable set of translation items is more important than a minimal
   one. Thus, eager mode will instantiate drop-glue for every drop-able type
   in the crate, even of no drop call for that type exists (yet). It will
   also instantiate default implementations of trait methods, something that
   otherwise is only done on demand.

Open Issues
-----------
Some things are not yet fully implemented in the current version of this
module.

Since no MIR is constructed yet for initializer expressions of constants and
statics we cannot inspect these properly.

Ideally, no translation item should be generated for const fns unless there
is a call to them that cannot be evaluated at compile time. At the moment
this is not implemented however: a translation item will be produced
regardless of whether it is actually needed or not.

<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/rust-lang/rust/30900)
<!-- Reviewable:end -->
2016-01-29 03:41:44 +00:00
Fabrice Desré 63b4639691 Add support for armv7 toolchains 2016-01-28 09:45:56 -08:00
Alex Crichton 1a910a0ff3 mk: Remove the -mfpu=vfp4 argument from arm iOS
Unfortunately older clang compilers don't support this argument, so the
bootstrap will fail. We don't actually really need to optimized the C code we
compile, however, as currently we're just compiling jemalloc and not much else.
2016-01-27 22:34:26 -08:00
Michael Woerister 862911df9a Implement the translation item collector.
The purpose of the translation item collector is to find all monomorphic instances of functions, methods and statics that need to be translated into LLVM IR in order to compile the current crate.
So far these instances have been discovered lazily during the trans path. For incremental compilation we want to know the set of these instances in advance, and that is what the trans::collect module provides.
In the future, incremental and regular translation will be driven by the collector implemented here.
2016-01-26 10:17:45 -05:00
Alex Crichton 2273b52023 mk: Move from `-D warnings` to `#![deny(warnings)]`
This commit removes the `-D warnings` flag being passed through the makefiles to
all crates to instead be a crate attribute. We want these attributes always
applied for all our standard builds, and this is more amenable to Cargo-based
builds as well.

Note that all `deny(warnings)` attributes are gated with a `cfg(stage0)`
attribute currently to match the same semantics we have today
2016-01-24 20:35:55 -08:00
Alex Crichton 5cd9ca90c5 mk: Remove all perf-related targets
I don't believe these have been used at all recently, and I doubt many of them
still work, so remove the stale support.
2016-01-21 14:45:23 -08:00
Oliver Schneider c124deca7b move more checks out of librustc 2016-01-21 10:52:37 +01:00
Brian Anderson e2b5ada771 Bump version to 1.8 2016-01-20 03:39:19 +00:00
bors 83c3b7f5a4 Auto merge of #30930 - oli-obk:fix/30887, r=arielb1
this makes sure the checks run before typeck (which might use the constant or const
function to calculate an array length) and gives prettier error messages in case of for
loops and such (since they aren't expanded yet).

fixes #30887

r? @pnkfelix
2016-01-16 08:20:31 +00:00
Oliver Schneider 1471d932a9 move const block checks before lowering step
this makes sure the checks run before typeck (which might use the constant or const
function to calculate an array length) and gives prettier error messages in case of for
loops and such (since they aren't expanded yet).
2016-01-15 13:16:54 +01:00
Manish Goregaokar 7208d25003 Rollup merge of #30776 - antonblanchard:powerpc64_merge, r=alexcrichton
This adds support for big endian and little endian PowerPC64.
make check runs clean apart from one big endian backtrace issue.
2016-01-15 17:28:28 +05:30
Manish Goregaokar 74458cf42a Rollup merge of #30874 - dhuseby:fixing_bitrig_tests, r=alexcrichton
fixes the failing bitrig unit tests.
2016-01-14 19:12:28 +05:30
Manish Goregaokar 1246f43bf9 Rollup merge of #30863 - jseyfried:no_rc, r=eddyb
Use arena allocation instead of reference counting for `Module`s to fix memory leaks from `Rc` cycles.

A module references its module children and its import resolutions, and an import resolution references the module defining the imported name, so there is a cycle whenever a module imports something from an ancestor module.

For example,
```rust
mod foo { // `foo` references `bar`.
    fn baz() {}
    mod bar { // `bar` references the import.
        use foo::baz; // The import references `foo`.
    }
}
```
2016-01-14 11:04:43 +05:30
Dave Huseby a933526fc4 Fixes #30873 2016-01-13 11:25:01 -08:00
bors b0eec55c3f Auto merge of #30794 - joerg-krause:fix-arm-unknown-linux-gnueabi-float-abi, r=alexcrichton
gnueabi indicates soft whereas gnueabihf indicates hard floating-point ABI.
2016-01-13 16:57:01 +00:00
Anton Blanchard b372910476 Add powerpc64 and powerpc64le support
This adds support for big endian and little endian PowerPC64.
make check runs clean apart from one big endian backtrace issue.
2016-01-13 01:39:00 +00:00
Jeffrey Seyfried a8514d3ecc resolve: use arena allocation instead of reference counting for `Module`s to fix memory leaks from Rc cycles 2016-01-13 00:54:16 +00:00
bors 3246eaec90 Auto merge of #30678 - Amanieu:no_elf_tls, r=alexcrichton
I also re-enabled the use of `#[thread_local]` on AArch64. It was originally disabled in the PR that introduced AArch64 (#19790), but the reasons for this were not explained. `#[thread_local]` seems to work fine in my tests on AArch64, so I don't think this should be an issue.

cc @alexcrichton @akiss77
2016-01-12 08:30:56 +00:00
bors dedaebd5a1 Auto merge of #30599 - brson:extra, r=alexcrichton
This mixes in additional information into the hash that is
passed to -C extra-filename. It can be used to further distinguish
the standard libraries if they must be installed next to each
other.

Closes #29559

Frankly, I'm not sure if this solves a real problem. It's meant to help with side-by-side and overlapping installations where there are two sets of libs in /usr, but there are other potential issues there as well, including that some of our artifacts don't use this extra-filename munging, and it's not something our installers can support at all.

cc @jauhien Do you still think this helps the Gentoo case?
2016-01-12 03:00:00 +00:00
Amanieu d'Antras e304fb43a3 Replace no_elf_tls with target_thread_local 2016-01-11 10:38:36 +00:00
Jörg Krause 035a0933f8 Fix arm-unknown-linux-gnueabi floating-point ABI
gnueabi indicates soft whereas gnueabihf indicates hard floating-point ABI.
2016-01-09 14:25:02 +01:00
Felix S. Klock II b043ded802 finish enabling -C rpath by default in rustc. See #30353. 2016-01-06 16:24:18 +01:00
Simonas Kazlauskas ad3371aedb Rollup merge of #30365 - tamird:update-valgrind, r=pnkfelix
Since `darwin` is really `apple-darwin`, the valgrind-rpass tests were not actually being run with valgrind on mac before. Also, the `HOST` check was completely wrong.

r? @alexcrichton
2015-12-31 18:52:19 +02:00
Brian Anderson ce81f24340 configure: Add --extra-filename flag
This mixes in additional information into the hash that is
passed to -C extra-filename. It can be used to further distinguish
the standard libraries if they must be installed next to each
other.

Closes #29559
2015-12-29 00:18:15 +00:00
bors 5178449f1c Auto merge of #30175 - alexcrichton:less-c-code, r=brson
All these definitions can now be written in Rust, so do so!
2015-12-22 07:23:16 +00:00
Alex Crichton 2f42ac438e std: Remove rust_builtin C support library
All these definitions can now be written in Rust, so do so!
2015-12-21 22:12:48 -08:00
bors 5d4efcb132 Auto merge of #30434 - alexcrichton:update-jemalloc, r=alexcrichton
It's been awhile since we last updated jemalloc, and there's likely some bugs
that have been fixed since the last version we're using, so let's try to update
again.
2015-12-21 23:31:06 +00:00