Commit Graph

439 Commits

Author SHA1 Message Date
Dan Gohman
7b6b764917 Control LLVM's TrapUnreachable feature through rustc's TargetOptions. 2017-11-11 12:15:43 -08:00
Amanieu d'Antras
b233a6e096 Add support for specifying the TLS model 2017-11-03 00:29:54 +00:00
Marco A L Barbosa
03419c846a Bump cc to 1.01 to include x86_64-unknown-linux-gnux32 support 2017-10-11 21:35:53 -03:00
bors
b2f67c8d56 Auto merge of #45041 - est31:master, r=alexcrichton
Remove support for the PNaCl target (le32-unknown-nacl)

This removes support for the `le32-unknown-nacl` target which is currently supported by rustc on tier 3. Despite the "nacl" in the name, the target doesn't output native code (x86, ARM, MIPS), instead it outputs binaries in the PNaCl format.

There are two reasons for the removal:

* Google [has announced](https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webassembly.html) deprecation of the PNaCl format. The suggestion is to migrate to wasm. Happens we already have a wasm backend!
* Our PNaCl LLVM backend is provided by the fastcomp patch set that the LLVM fork used by rustc contains in addition to vanilla LLVM (`src/llvm/lib/Target/JSBackend/NaCl`). Upstream LLVM doesn't have PNaCl support. Removing PNaCl support will enable us to move away from fastcomp (#44006) and have a lighter set of patches on top of upstream LLVM inside our LLVM fork. This will help distribution packagers of Rust.

Fixes #42420
2017-10-09 04:59:02 +00:00
Alex Crichton
4ca1b19fde rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.

This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:

* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
  single compilation. That is, we won't load upstream rlibs, but we'll instead
  just perform ThinLTO amongst all codegen units produced by the compiler for
  the local crate. This is intended to emulate a desired end point where we have
  codegen units turned on by default for all crates and ThinLTO allows us to do
  this without performance loss.

* In anther mode, like full LTO today, we'll optimize all upstream dependencies
  in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
  should finish much more quickly.

There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:

* Controlling parallelism means we can use the existing jobserver support to
  avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
  integrates with our own incremental strategy, but this is yet to be
  determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
  having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
  creation, where all our options we used today aren't necessarily supported by
  upstream LLVM yet.

My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-10-07 08:17:52 -07:00
est31
6f7dd654cd Remove nacl from librustc_llvm 2017-10-05 05:01:02 +02:00
Alex Crichton
ded38dbfc2 rustc: Enable LTO and multiple codegen units
This commit is a refactoring of the LTO backend in Rust to support compilations
with multiple codegen units. The immediate result of this PR is to remove the
artificial error emitted by rustc about `-C lto -C codegen-units-8`, but longer
term this is intended to lay the groundwork for LTO with incremental compilation
and ultimately be the underpinning of ThinLTO support.

The problem here that needed solving is that when rustc is producing multiple
codegen units in one compilation LTO needs to merge them all together.
Previously only upstream dependencies were merged and it was inherently relied
on that there was only one local codegen unit. Supporting this involved
refactoring the optimization backend architecture for rustc, namely splitting
the `optimize_and_codegen` function into `optimize` and `codegen`. After an LLVM
module has been optimized it may be blocked and queued up for LTO, and only
after LTO are modules code generated.

Non-LTO compilations should look the same as they do today backend-wise, we'll
spin up a thread for each codegen unit and optimize/codegen in that thread. LTO
compilations will, however, send the LLVM module back to the coordinator thread
once optimizations have finished. When all LLVM modules have finished optimizing
the coordinator will invoke the LTO backend, producing a further list of LLVM
modules. Currently this is always a list of one LLVM module. The coordinator
then spawns further work to run LTO and code generation passes over each module.

In the course of this refactoring a number of other pieces were refactored:

* Management of the bytecode encoding in rlibs was centralized into one module
  instead of being scattered across LTO and linking.
* Some internal refactorings on the link stage of the compiler was done to work
  directly from `CompiledModule` structures instead of lists of paths.
* The trans time-graph output was tweaked a little to include a name on each
  bar and inflate the size of the bars a little
2017-09-30 00:22:15 -07:00
Alex Crichton
7694ca419b Update to the cc crate
This is the name the `gcc` crate has moved to
2017-09-28 07:45:50 -07:00
Tamir Duberstein
231d9e7e5d
Remove rustc_bitflags; use the bitflags crate 2017-09-17 14:19:24 -04:00
Ralf Jung
13cf229037 disable gcc warnings 2017-09-05 18:46:26 +02:00
Ralf Jung
12d84cc009 update gcc crate
Use gcc::Build rather than deprecated gcc::Config.
Fixes #43973
2017-09-02 21:51:18 +02:00
Tamir Duberstein
b3f50caee0
*: remove crate_{name,type} attributes
Fixes #41701.
2017-08-25 16:18:21 -04:00
Vadim Petrochenkov
de4dbe5789 rustc: Remove some dead code 2017-08-19 13:27:16 +03:00
Zack M. Davis
1b6c9605e4 use field init shorthand EVERYWHERE
Like #43008 (f668999), but _much more aggressive_.
2017-08-15 15:29:17 -07:00
bors
2b82b7e50a Auto merge of #43554 - eddyb:apfloat, r=nikomatsakis
APFloat: Rewrite It In Rust and use it for deterministic floating-point CTFE.

As part of the CTFE initiative, we're forced to find a solution for floating-point operations.
By design, IEEE-754 does not explicitly define everything in a deterministic manner, and there is some variability between platforms, at the very least (e.g. NaN payloads).

If types are to evaluate constant expressions involving type (or in the future, const) generics, that evaluation needs to be *fully deterministic*, even across `rustc` host platforms.
That is, if `[T; T::X]` was used in a cross-compiled library, and the evaluation of `T::X` executed a floating-point operation, that operation has to be reproducible on *any other host*, only knowing `T` and the definition of the `X` associated const (as either AST or HIR).

Failure to uphold those rules allows an associated type (e.g. `<Foo as Iterator>::Item`) to be seen as two (or more) different types, depending on the current host, and such type safety violations typically allow writing of a `transmute` in safe code, given enough generics.

The options considered by @rust-lang/compiler were:
1. Ban floating-point operations in generic const-evaluation contexts
2. Emulate floating-point operations in an uniformly deterministic fashion

The former option may seem appealing at first, but floating-point operations *are allowed today*, so they can't be banned wholesale, a distinction has to be made between the code that already works, and future generic contexts. *Moreover*, every computation that succeeded *has to be cached*, otherwise the generic case can be reproduced without any generics. IMO there are too many ways it can go wrong, and a single violation can be enough for an unsoundness hole.
Not to mention we may end up really wanting floating-point operations *anyway*, in CTFE.

I went with the latter option, and seeing how LLVM *already* has a library for this exact purpose (as it needs to perform optimizations independently of host floating-point capabilities), i.e. `APFloat`, that was what I ended up basing this PR on.
But having been burned by the low reusability of bindings that link to LLVM, and because I would *rather* the floating-point operations to be wrong than not deterministic or not memory-safe (`APFloat` does far more pointer juggling than I'm comfortable with), I decided to RIIR.

This way, we have a guarantee of *no* `unsafe` code, a bit more control over the where native floating-point might accidentally be involved, and non-LLVM backends can share it.
I've also ported all the testcases over, *before* any functionality, to catch any mistakes.

Currently the PR replaces all CTFE operations to go through `apfloat::ieee::{Single,Double}`, keeping only the bits of the `f32` / `f64` memory representation in between operations.
Converting from a string also double-checks that `core::num` and `apfloat` agree on the interpretation of a floating-point number literal, in case either of them has any bugs left around.

r? @nikomatsakis
f? @nagisa @est31

<hr/>

Huge thanks to @edef1c for first demoing usable `APFloat` bindings and to @chandlerc for fielding my questions on IRC about `APFloat` peculiarities (also upstreaming some bugfixes).
2017-08-05 13:12:56 +00:00
Eduard-Mihai Burtescu
c457b26e33 rustc_trans: do not pass floating-point values to LLVM through FFI. 2017-08-02 17:28:11 +03:00
Corey Farwell
ab3fb956f3 Rollup merge of #43389 - alexcrichton:thread-error, r=michaelwoerister
Thread through the original error when opening archives

This updates the management of opening archives to thread through the original
piece of error information from LLVM over to the end consumer, trans.
2017-08-02 01:22:26 +00:00
Alex Crichton
9010567dcc Bump master to 1.21.0
This commit bumps the master branch's version to 1.21.0 and also updates the
bootstrap compiler from the freshly minted beta release.
2017-07-25 07:03:19 -07:00
Tim Neumann
1ee87b3765 rustllvm: split DebugLoc in UnpackOptimizationDiagnostic 2017-07-21 19:09:10 +02:00
Alex Crichton
81eea9e431 Thread through the original error when opening archives
This updates the management of opening archives to thread through the original
piece of error information from LLVM over to the end consumer, trans.
2017-07-21 09:44:01 -07:00
Sean McArthur
74b2d69358 remove associated_consts feature gate 2017-07-06 11:52:25 -07:00
Alex Crichton
695dee063b rustc: Implement the #[global_allocator] attribute
This PR is an implementation of [RFC 1974] which specifies a new method of
defining a global allocator for a program. This obsoletes the old
`#![allocator]` attribute and also removes support for it.

[RFC 1974]: https://github.com/rust-lang/rfcs/pull/197

The new `#[global_allocator]` attribute solves many issues encountered with the
`#![allocator]` attribute such as composition and restrictions on the crate
graph itself. The compiler now has much more control over the ABI of the
allocator and how it's implemented, allowing much more freedom in terms of how
this feature is implemented.

cc #27389
2017-07-05 14:37:01 -07:00
bors
d41b791c1a Auto merge of #42971 - stepancheg:ir-demangle, r=nagisa
When writing LLVM IR output demangled fn name in comments

`--emit=llvm-ir` looks like this now:

```
; <alloc::vec::Vec<T> as core::ops::index::IndexMut<core::ops::range::RangeFull>>::index_mut
; Function Attrs: inlinehint uwtable
define internal { i8*, i64 } @"_ZN106_$LT$alloc..vec..Vec$LT$T$GT$$u20$as$u20$core..ops..index..IndexMut$LT$core..ops..range..RangeFull$GT$$GT$9index_mut17h7f7b576609f30262E"(%"alloc::vec::Vec<u8>"* dereferenceable(24)) unnamed_addr #0 {
start:
  ...
```

cc https://github.com/integer32llc/rust-playground/issues/15
2017-07-01 05:52:08 +00:00
Stepan Koltsov
b62bdaafe0 When writing LLVM IR output demangled fn name in comments
`--emit=llvm-ir` looks like this now:

```
; <alloc::vec::Vec<T> as core::ops::index::IndexMut<core::ops::range::RangeFull>>::index_mut
; Function Attrs: inlinehint uwtable
define internal { i8*, i64 } @"_ZN106_$LT$alloc..vec..Vec$LT$T$GT$$u20$as$u20$core..ops..index..IndexMut$LT$core..ops..range..RangeFull$GT$$GT$9index_mut17h7f7b576609f30262E"(%"alloc::vec::Vec<u8>"* dereferenceable(24)) unnamed_addr #0 {
start:
  ...
```

cc https://github.com/integer32llc/rust-playground/issues/15
2017-07-01 03:16:43 +03:00
Venkata Giri Reddy
401614b75a rustc_llvm: re-run build script when env var LLVM_CONFIG changes 2017-06-30 16:55:32 +00:00
bors
380100c568 Auto merge of #42571 - tlively:wasm-dev, r=alexcrichton
Enable wasm LLVM backend

Enables compilation to WebAssembly with the LLVM backend using the target triple "wasm32-unknown-unknown". This is the beginning of my work on #38804.

**edit:** The new new target is now wasm32-experimental-emscripten instead of wasm32-unknown-unknown.
2017-06-20 09:44:40 +00:00
Alex Crichton
be7ebdd512 Bump version and stage0 compiler 2017-06-19 22:25:05 -07:00
Thomas Lively
a1981a64a2 Add target to use LLVM wasm backend
The new target is wasm32-experimental-emscripten. Adds a new
configuration option to opt in to building experimental LLVM backends
such as the WebAssembly backend. The target name was chosen to be
similar to the existing wasm32-unknown-emscripten target so that the
build and tests would work with minimal other code changes. When/if the
new target replaces the old target, simply renaming it should just work.
2017-06-16 15:43:43 -07:00
bors
dfa7e21e4e Auto merge of #42433 - marco-c:profiling, r=alexcrichton
Build instruction profiler runtime as part of compiler-rt

r? @alexcrichton

This is #38608 with some fixes.

Still missing:
- [x] testing with profiler enabled on some builders (on which ones? Should I add the option to some of the already existing configurations, or create a new configuration?);
- [x] enabling distribution (on which builders?);
- [x] documentation.
2017-06-14 08:46:14 +00:00
Venkata Giri Reddy
40f8536449 rustc_llvm: re-run build script if config.toml changes 2017-06-04 18:35:57 +00:00
Marco Castelluccio
ecba8d6a23 Merge branch 'profiling' of github.com:whitequark/rust into profiling 2017-06-04 15:54:39 +01:00
Brian Anderson
da100fe0bb Support VS 2017
Fixes #38584
2017-06-01 20:41:38 +00:00
Corey Farwell
2451f65c5c Rollup merge of #42224 - brson:lockfile, r=nikomatsakis
Remove stray lockfile
2017-05-26 10:20:27 -04:00
Brian Anderson
435e1cec9e Remove stray lockfile 2017-05-25 18:48:21 +00:00
Nathan Froyd
9a2e2450f9 add thiscall calling convention support
This support is needed for bindgen to work well on 32-bit Windows, and
also enables people to begin experimenting with C++ FFI support on that
platform.

Fixes #42044.
2017-05-24 16:40:03 -04:00
Segev Finer
2e0043ad61 Fix: "warning: redundant linker flag specified for library ole32"
llvm-config seems to output this library name correctly now, removing
the need for the hack in "librustc_llvm/build.rs".
2017-05-20 13:57:41 +03:00
Alex Crichton
ab54f4b226 rustc: Remove #![unstable] annotation
These are now no longer necessary with `-Z force-unstable-if-unmarked`
2017-05-11 16:03:05 -07:00
bors
4cb396c680 Auto merge of #41560 - alevy:rwpi-ropi, r=eddyb
Add RWPI/ROPI relocation model support

This PR adds support for using LLVM 4's ROPI and RWPI relocation models for ARM.

ROPI (Read-Only Position Independence) and RWPI (Read-Write Position Independence) are two new relocation models in LLVM for the ARM backend ([LLVM changset](https://reviews.llvm.org/rL278015)). The motivation is that these are the specific strategies we use in userspace [Tock](https://www.tockos.org) apps, so supporting this is an important step (perhaps the final step, but can't confirm yet) in enabling userspace Rust processes.

## Explanation

ROPI makes all code and immutable accesses PC relative, but not assumed to be overriden at runtime (so for example, jumps are always relative).

RWPI uses a base register (`r9`) that stores the addresses of the GOT in memory so the runtime (e.g. a kernel) only adjusts r9 tell running code where the GOT is.

## Complications adding support in Rust

While this landed in LLVM master back in August, the header files in `llvm-c` have not been updated yet to reflect it. Rust replicates that header file's version of the `LLVMRelocMode` enum as the Rust enum `llvm::RelocMode` and uses an implicit cast in the ffi to translate from Rust's notion of the relocation model to the LLVM library's notion.

My workaround for this currently is to replace the `LLVMRelocMode` argument to `LLVMTargetMachineRef` with an int and using the hardcoded int representation of the `RelocMode` enum. This is A Bad Idea(tm), but I think very nearly the right thing.

Would a better alternative be to patch rust-llvm to support these enum variants (also a fairly trivial change)?
2017-05-01 17:23:09 +00:00
whitequark
42754ce710 Add profiling support, through the rustc -Z profile flag.
When -Z profile is passed, the GCDAProfiling LLVM pass is added
to the pipeline, which uses debug information to instrument the IR.
After compiling with -Z profile, the $(OUT_DIR)/$(CRATE_NAME).gcno
file is created, containing initial profiling information.
After running the program built, the $(OUT_DIR)/$(CRATE_NAME).gcda
file is created, containing branch counters.

The created *.gcno and *.gcda files can be processed using
the "llvm-cov gcov" and "lcov" tools. The profiling data LLVM
generates does not faithfully follow the GCC's format for *.gcno
and *.gcda files, and so it will probably not work with other tools
(such as gcov itself) that consume these files.
2017-05-01 09:16:20 +00:00
Amit Aryeh Levy
0f00f27e0d Added LLVMRustRelocMode
Replaces the llvm-c exposed LLVMRelocMode, which does not include all
relocation model variants, with a LLVMRustRelocMode modeled after
LLVMRustCodeMode.
2017-04-28 17:33:56 -05:00
Amit Aryeh Levy
32b92669e4 Add RWPI/ROPI relocation model support
Adds support for using LLVM 4's ROPI and RWPI relocation models for ARM
2017-04-26 16:25:14 -04:00
Michael Wu
32aeb22f54 Avoid the hexagon backend on old versions of LLVM 2017-04-25 22:59:31 -04:00
Michael Wu
c558a2ae37 Add Hexagon support
This requires an updated LLVM with D31999 and D32000 to build libcore.

A basic hello world builds and runs successfully on the hexagon simulator.
2017-04-25 01:56:44 -04:00
bors
0777c757a6 Auto merge of #40123 - TimNN:llvm40, r=alexcrichton
LLVM 4.0 Upgrade

Since nobody has done this yet, I decided to get things started:

**Todo:**

* [x] push the relevant commits to `rust-lang/llvm` and `rust-lang/compiler-rt`
* [x] cleanup `.gitmodules`
* [x] Verify if there are any other commits from `rust-lang/llvm` which need backporting
* [x] Investigate / fix debuginfo ("`<optimized out>`") failures
* [x] Use correct emscripten version in docker image

---

Closes #37609.

---

**Test results:**

Everything is green 🎉
2017-04-24 22:18:16 +00:00
Tim Neumann
8994277657 FIN: windows-gnu: statically link gcc_s, pthread with llvm 2017-04-23 22:00:03 +02:00
A.J. Gardner
9240054b3e Expose LLVM appendModuleInlineAsm 2017-04-12 19:12:49 -05:00
Simonas Kazlauskas
aeab73c938 Specify type libraries for llvm-config --ldflags
This matters on systems where static libraries and dynamic libraries reside in
different location
2017-04-08 17:53:16 +03:00
Vadim Chugunov
0f87203e2e Make sure that -lole32 ends up *after* LLVM libs on the linker command line. 2017-03-30 16:31:46 -07:00
Oliver Schneider
eb447f4ef4
Fix various useless derefs and slicings 2017-03-27 08:58:00 +02:00
Tim Neumann
43a51b78b8 link agains relocatable libstdc++ 2017-03-21 20:37:50 +01:00
Tim Neumann
1f65610675 ci/netbsd: use the "official" cross compiler 2017-03-21 20:37:50 +01:00
Vadim Petrochenkov
f2187093f8 Add/remove rerun-if-changed when necessary 2017-03-04 21:38:26 +03:00
Philipp Oppermann
b44805875e Add support for x86-interrupt calling convention
Tracking issue: https://github.com/rust-lang/rust/issues/40180

This calling convention can be used for definining interrupt handlers on
32-bit and 64-bit x86 targets. The compiler then uses `iret` instead of
`ret` for returning and ensures that all registers are restored to their
original values.

Usage:

```
extern "x86-interrupt" fn handler(stack_frame: &ExceptionStackFrame) {…}
```

for interrupts and exceptions without error code and

```
extern "x86-interrupt" fn page_fault_handler(stack_frame: &ExceptionStackFrame,
                                             error_code: u64) {…}
```

for exceptions that push an error code (e.g., page faults or general
protection faults). The programmer must ensure that the correct version
is used for each interrupt.

For more details see the [LLVM PR][1] and the corresponding [proposal][2].

[1]: https://reviews.llvm.org/D15567
[2]: http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html
2017-03-02 19:01:15 +01:00
bors
05a7f25cc4 Auto merge of #39456 - nagisa:mir-switchint-everywhere, r=nikomatsakis
[MIR] SwitchInt Everywhere

Something I've been meaning to do for a very long while. This PR essentially gets rid of 3 kinds of conditional branching and only keeps the most general one - `SwitchInt`. Primary benefits are such that dealing with MIR now does not involve dealing with 3 different ways to do conditional control flow. On the other hand, constructing a `SwitchInt` currently requires more code than what previously was necessary to build an equivalent `If` terminator. Something trivially "fixable" with some constructor methods somewhere (MIR needs stuff like that badly in general).

Some timings (tl;dr: slightly faster^1 (unexpected), but also uses slightly more memory at peak (expected)):

^1: Not sure if the speed benefits are because of LLVM liking the generated code better or the compiler itself getting compiled better. Either way, its a net benefit. The CORE and SYNTAX timings done for compilation without optimisation.

```
AFTER:
Building stage1 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 31.50 secs
    Finished release [optimized] target(s) in 31.42 secs
Building stage1 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 439.56 secs
    Finished release [optimized] target(s) in 435.15 secs

CORE: 99% (24.81 real, 0.13 kernel, 24.57 user); 358536k resident
CORE: 99% (24.56 real, 0.15 kernel, 24.36 user); 359168k resident
SYNTAX: 99% (49.98 real, 0.48 kernel, 49.42 user); 653416k resident
SYNTAX: 99% (50.07 real, 0.58 kernel, 49.43 user); 653604k resident

BEFORE:
Building stage1 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 31.84 secs
Building stage1 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 451.17 secs

CORE: 99% (24.66 real, 0.20 kernel, 24.38 user); 351096k resident
CORE: 99% (24.36 real, 0.17 kernel, 24.18 user); 352284k resident
SYNTAX: 99% (52.24 real, 0.56 kernel, 51.66 user); 645544k resident
SYNTAX: 99% (51.55 real, 0.48 kernel, 50.99 user); 646428k resident
```

cc @nikomatsakis @eddyb
2017-02-13 02:32:09 +00:00
Matt Ickstadt
68fff62542 [LLVM 4.0] Fix CreateCompileUnit 2017-02-11 15:15:28 -06:00
Simonas Kazlauskas
f3bd723101 Fix intcast, use it where appropriate 2017-02-10 19:47:09 +02:00
bors
4053276354 Auto merge of #38109 - tromey:main-subprogram, r=michaelwoerister
Emit DW_AT_main_subprogram

This changes rustc to emit DW_AT_main_subprogram on the "main" program.
This lets gdb suitably stop at the user's main in response to
"start" (rather than the library's main, which is what happens
currently).

Fixes #32620
r? michaelwoerister
2017-02-09 17:09:50 +00:00
Corey Farwell
3053494a9a Rollup merge of #38699 - japaric:lsan, r=alexcrichton
LeakSanitizer, ThreadSanitizer, AddressSanitizer and MemorySanitizer support

```
$ cargo new --bin leak && cd $_

$ edit Cargo.toml && tail -n3 $_
```

``` toml
[profile.dev]
opt-level = 1
```

```
$ edit src/main.rs && cat $_
```

``` rust
use std::mem;

fn main() {
    let xs = vec![0, 1, 2, 3];
    mem::forget(xs);
}
```

```
$ RUSTFLAGS="-Z sanitizer=leak" cargo run --target x86_64-unknown-linux-gnu; echo $?
    Finished dev [optimized + debuginfo] target(s) in 0.0 secs
     Running `target/debug/leak`

=================================================================
==10848==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 16 byte(s) in 1 object(s) allocated from:
    #0 0x557c3488db1f in __interceptor_malloc /shared/rust/checkouts/lsan/src/compiler-rt/lib/lsan/lsan_interceptors.cc:55
    #1 0x557c34888aaa in alloc::heap::exchange_malloc::h68f3f8b376a0da42 /shared/rust/checkouts/lsan/src/liballoc/heap.rs:138
    #2 0x557c34888afc in leak::main::hc56ab767de6d653a $PWD/src/main.rs:4
    #3 0x557c348c0806 in __rust_maybe_catch_panic ($PWD/target/debug/leak+0x3d806)

SUMMARY: LeakSanitizer: 16 byte(s) leaked in 1 allocation(s).
23
```

```
$ cargo new --bin racy && cd $_

$ edit src/main.rs && cat $_
```

``` rust
use std::thread;

static mut ANSWER: i32 = 0;

fn main() {
    let t1 = thread::spawn(|| unsafe { ANSWER = 42 });
    unsafe {
        ANSWER = 24;
    }
    t1.join().ok();
}
```

```
$ RUSTFLAGS="-Z sanitizer=thread" cargo run --target x86_64-unknown-linux-gnu; echo $?
==================
WARNING: ThreadSanitizer: data race (pid=12019)
  Write of size 4 at 0x562105989bb4 by thread T1:
    #0 racy::main::_$u7b$$u7b$closure$u7d$$u7d$::hbe13ea9e8ac73f7e $PWD/src/main.rs:6 (racy+0x000000010e3f)
    #1 _$LT$std..panic..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..FnOnce$LT$$LP$$RP$$GT$$GT$::call_once::h2e466a92accacc78 /shared/rust/checkouts/lsan/src/libstd/panic.rs:296 (racy+0x000000010cc5)
    #2 std::panicking::try::do_call::h7f4d2b38069e4042 /shared/rust/checkouts/lsan/src/libstd/panicking.rs:460 (racy+0x00000000c8f2)
    #3 __rust_maybe_catch_panic <null> (racy+0x0000000b4e56)
    #4 std::panic::catch_unwind::h31ca45621ad66d5a /shared/rust/checkouts/lsan/src/libstd/panic.rs:361 (racy+0x00000000b517)
    #5 std:🧵:Builder::spawn::_$u7b$$u7b$closure$u7d$$u7d$::hccfc37175dea0b01 /shared/rust/checkouts/lsan/src/libstd/thread/mod.rs:357 (racy+0x00000000c226)
    #6 _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::hd880bbf91561e033 /shared/rust/checkouts/lsan/src/liballoc/boxed.rs:605 (racy+0x00000000f27e)
    #7 std::sys:👿🧵:Thread:🆕:thread_start::hebdfc4b3d17afc85 <null> (racy+0x0000000abd40)

  Previous write of size 4 at 0x562105989bb4 by main thread:
    #0 racy::main::h23e6e5ca46d085c3 $PWD/src/main.rs:8 (racy+0x000000010d7c)
    #1 __rust_maybe_catch_panic <null> (racy+0x0000000b4e56)
    #2 __libc_start_main <null> (libc.so.6+0x000000020290)

  Location is global 'racy::ANSWER::h543d2b139f819b19' of size 4 at 0x562105989bb4 (racy+0x0000002f8bb4)

  Thread T1 (tid=12028, running) created by main thread at:
    #0 pthread_create /shared/rust/checkouts/lsan/src/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:902 (racy+0x00000001aedb)
    #1 std::sys:👿🧵:Thread:🆕:hce44187bf4a36222 <null> (racy+0x0000000ab9ae)
    #2 std:🧵:spawn::he382608373eb667e /shared/rust/checkouts/lsan/src/libstd/thread/mod.rs:412 (racy+0x00000000b5aa)
    #3 racy::main::h23e6e5ca46d085c3 $PWD/src/main.rs:6 (racy+0x000000010d5c)
    #4 __rust_maybe_catch_panic <null> (racy+0x0000000b4e56)
    #5 __libc_start_main <null> (libc.so.6+0x000000020290)

SUMMARY: ThreadSanitizer: data race $PWD/src/main.rs:6 in racy::main::_$u7b$$u7b$closure$u7d$$u7d$::hbe13ea9e8ac73f7e
==================
ThreadSanitizer: reported 1 warnings
66
```

```
$ cargo new --bin oob && cd $_

$ edit src/main.rs && cat $_
```

``` rust
fn main() {
    let xs = [0, 1, 2, 3];
    let y = unsafe { *xs.as_ptr().offset(4) };
}
```

```
$ RUSTFLAGS="-Z sanitizer=address" cargo run --target x86_64-unknown-linux-gnu; echo $?
=================================================================
==13328==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff29f3ecd0 at pc 0x55802dc6bf7e bp 0x7fff29f3ec90 sp 0x7fff29f3ec88
READ of size 4 at 0x7fff29f3ecd0 thread T0
    #0 0x55802dc6bf7d in oob::main::h0adc7b67e5feb2e7 $PWD/src/main.rs:3
    #1 0x55802dd60426 in __rust_maybe_catch_panic ($PWD/target/debug/oob+0xfe426)
    #2 0x55802dd58dd9 in std::rt::lang_start::hb2951fc8a59d62a7 ($PWD/target/debug/oob+0xf6dd9)
    #3 0x55802dc6c002 in main ($PWD/target/debug/oob+0xa002)
    #4 0x7fad8c3b3290 in __libc_start_main (/usr/lib/libc.so.6+0x20290)
    #5 0x55802dc6b719 in _start ($PWD/target/debug/oob+0x9719)

Address 0x7fff29f3ecd0 is located in stack of thread T0 at offset 48 in frame
    #0 0x55802dc6bd5f in oob::main::h0adc7b67e5feb2e7 $PWD/src/main.rs:1

  This frame has 1 object(s):
    [32, 48) 'xs' <== Memory access at offset 48 overflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow $PWD/src/main.rs:3 in oob::main::h0adc7b67e5feb2e7
Shadow bytes around the buggy address:
  0x1000653dfd40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000653dfd50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000653dfd60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000653dfd70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000653dfd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x1000653dfd90: 00 00 00 00 f1 f1 f1 f1 00 00[f3]f3 00 00 00 00
  0x1000653dfda0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000653dfdb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000653dfdc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000653dfdd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000653dfde0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==13328==ABORTING
1
```

```
$ cargo new --bin uninit && cd $_

$ edit src/main.rs && cat $_
```

``` rust
use std::mem;

fn main() {
    let xs: [u8; 4] = unsafe { mem::uninitialized() };
    let y = xs[0] + xs[1];
}
```

```
$ RUSTFLAGS="-Z sanitizer=memory" cargo run; echo $?
==30198==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x563f4b6867da in uninit::main::hc2731cd4f2ed48f8 $PWD/src/main.rs:5
    #1 0x563f4b7033b6 in __rust_maybe_catch_panic ($PWD/target/debug/uninit+0x873b6)
    #2 0x563f4b6fbd69 in std::rt::lang_start::hb2951fc8a59d62a7 ($PWD/target/debug/uninit+0x7fd69)
    #3 0x563f4b6868a9 in main ($PWD/target/debug/uninit+0xa8a9)
    #4 0x7fe844354290 in __libc_start_main (/usr/lib/libc.so.6+0x20290)
    #5 0x563f4b6864f9 in _start ($PWD/target/debug/uninit+0xa4f9)

SUMMARY: MemorySanitizer: use-of-uninitialized-value $PWD/src/main.rs:5 in uninit::main::hc2731cd4f2ed48f8
Exiting
77
```
2017-02-08 23:55:43 -05:00
Jorge Aparicio
775a93646c build/test the sanitizers only when --enable-sanitizers is used 2017-02-08 18:51:43 -05:00
Jorge Aparicio
9af6aa3889 sanitizer support 2017-02-08 18:51:43 -05:00
Corey Farwell
7709c4d2b9 Rollup merge of #39529 - dylanmckay:llvm-4.0-align32, r=alexcrichton
[LLVM 4.0] Use 32-bits for alignment

LLVM 4.0 changes this. This change is fine to make for LLVM 3.9 as we
won't have alignments greater than 2^32-1.
2017-02-08 10:19:49 -05:00
Alex Crichton
77c3bfa742 std: Remove cfg(cargobuild) annotations
These are all now no longer needed that we've only got rustbuild in tree.
2017-02-06 08:42:54 -08:00
Tom Tromey
b037c5211b Emit DW_AT_main_subprogram
This changes rustc to emit DW_AT_main_subprogram on the "main" program.
This lets gdb suitably stop at the user's main in response to
"start" (rather than the library's main, which is what happens
currently).

Fixes #32620
r? michaelwoerister
2017-02-04 23:19:39 -07:00
Dylan McKay
b4e6f70eda [llvm] Use 32-bits for alignment
LLVM 4.0 changes this. This change is fine to make for LLVM 3.9 as we
won't have alignments greater than 2^32-1.
2017-02-04 23:51:10 +13:00
Dylan McKay
768c6c081e Support a debug info API change for LLVM 4.0
Instead of directly creating a 'DIGlobalVariable', we now have to create
a 'DIGlobalVariableExpression' which itself contains a reference to a
'DIGlobalVariable'.

This is a straightforward change.

In the future, we should rename 'DIGlobalVariable' in the FFI
bindings, assuming we will only refer to 'DIGlobalVariableExpression'
and not 'DIGlobalVariable'.
2017-02-04 23:22:05 +13:00
Simonas Kazlauskas
1363cdaec9 Remove unnecessary LLVMRustPersonalityFn binding
LLVM Core C bindings provide this function for all the versions back to what we support (3.7), and
helps to avoid this unnecessary builder->function transition every time. Also a negative diff.
2017-01-26 23:49:17 +02:00
Jorge Aparicio
6296d52ba6 calling convention for MSP430 interrupts
This calling convention is used to define interrup handlers on MSP430
microcontrollers. Usage looks like this:

``` rust
#[no_mangle]
#[link_section = "__interrupt_vector_10"]
pub static TIM0_VECTOR: unsafe extern "msp430-interrupt" fn() = tim0;

unsafe extern "msp430-interrupt" fn tim0() {
  P1OUT.write(0x00);
}
```

which generates the following assembly:

``` asm
Disassembly of section __interrupt_vector_10:

0000fff2 <TIM0_VECTOR>:
    fff2:       10 c0           interrupt service routine at 0xc010

Disassembly of section .text:

0000c010 <_ZN3msp4tim017h3193b957fd6a4fd4E>:
    c010:       c2 43 21 00     mov.b   #0,     &0x0021 ;r3 As==00
    c014:       00 13           reti
        ...
```
2017-01-18 20:42:54 -05:00
bors
7ac9d337dc Auto merge of #38679 - alexcrichton:always-deny-warnings, r=nrc
Remove not(stage0) from deny(warnings)

Historically this was done to accommodate bugs in lints, but there hasn't been a
bug in a lint since this feature was added which the warnings affected. Let's
completely purge warnings from all our stages by denying warnings in all stages.
This will also assist in tracking down `stage0` code to be removed whenever
we're updating the bootstrap compiler.
2017-01-08 08:22:06 +00:00
bors
ac5cd3bd43 Auto merge of #38745 - CannedYerins:llvm-code-style, r=rkruppe
Improve naming style in rustllvm.

As per the LLVM style guide, use CamelCase for all locals and classes,
and camelCase for all non-FFI functions.
Also, make names of variables of commonly used types more consistent.

Fixes #38688.

r? @rkruppe
2017-01-01 11:58:02 +00:00
Ian Kerins
e6f97114ca Improve naming style in rustllvm.
As per the LLVM style guide, use CamelCase for all locals and classes,
and camelCase for all non-FFI functions.
Also, make names of variables of commonly used types more consistent.

Fixes #38688.
2016-12-31 13:20:30 -05:00
Simonas Kazlauskas
ee69cd7925 Calculate discriminant bounds within 64 bits
Since discriminants do not support i128 yet, lets just calculate the boundaries within the 64 bits
that are supported. This also avoids an issue with bootstrapping on 32 bit systems due to #38727.
2016-12-31 04:55:29 +02:00
Simonas Kazlauskas
9aad2d551e Add a way to retrieve constant value in 128 bits
Fixes rebase fallout, makes code correct in presence of 128-bit constants.

This commit includes manual merge conflict resolution changes from a rebase by @est31.
2016-12-30 15:17:26 +01:00
Simonas Kazlauskas
d9eb756cbf Wrapping<i128> and attempt at LLVM 3.7 compat
This commit includes manual merge conflict resolution changes from a rebase by @est31.
2016-12-30 15:17:26 +01:00
Simonas Kazlauskas
b0e55a83a8 Such large. Very 128. Much bits.
This commit introduces 128-bit integers. Stage 2 builds and produces a working compiler which
understands and supports 128-bit integers throughout.

The general strategy used is to have rustc_i128 module which provides aliases for iu128, equal to
iu64 in stage9 and iu128 later. Since nowhere in rustc we rely on large numbers being supported,
this strategy is good enough to get past the first bootstrap stages to end up with a fully working
128-bit capable compiler.

In order for this strategy to work, number of locations had to be changed to use associated
max_value/min_value instead of MAX/MIN constants as well as the min_value (or was it max_value?)
had to be changed to use xor instead of shift so both 64-bit and 128-bit based consteval works
(former not necessarily producing the right results in stage1).

This commit includes manual merge conflict resolution changes from a rebase by @est31.
2016-12-30 15:15:44 +01:00
Alex Crichton
9b0b5b45db Remove not(stage0) from deny(warnings)
Historically this was done to accommodate bugs in lints, but there hasn't been a
bug in a lint since this feature was added which the warnings affected. Let's
completely purge warnings from all our stages by denying warnings in all stages.
This will also assist in tracking down `stage0` code to be removed whenever
we're updating the bootstrap compiler.
2016-12-29 21:07:20 -08:00
Alex Crichton
bcfd504744 Rollup merge of #38559 - japaric:ptx2, r=alexcrichton
PTX support, take 2

- You can generate PTX using `--emit=asm` and the right (custom) target. Which
  then you can run on a NVIDIA GPU.

- You can compile `core` to PTX. [Xargo] also works and it can compile some
  other crates like `collections` (but I doubt all of those make sense on a GPU)

[Xargo]: https://github.com/japaric/xargo

- You can create "global" functions, which can be "called" by the host, using
  the `"ptx-kernel"` ABI, e.g. `extern "ptx-kernel" fn kernel() { .. }`. Every
  other function is a "device" function and can only be called by the GPU.

- Intrinsics like `__syncthreads()` and `blockIdx.x` are available as
  `"platform-intrinsics"`. These intrinsics are *not* in the `core` crate but
  any Rust user can create "bindings" to them using an `extern
  "platform-intrinsics"` block. See example at the end.

- Trying to emit PTX with `-g` (debuginfo); you get an LLVM error. But I don't
  think PTX can contain debuginfo anyway so `-g` should be ignored and a warning
  should be printed ("`-g` doesn't work with this target" or something).

- "Single source" support. You *can't* write a single source file that contains
  both host and device code. I think that should be possible to implement that
  outside the compiler using compiler plugins / build scripts.

- The equivalent to CUDA `__shared__` which it's used to declare memory that's
  shared between the threads of the same block. This could be implemented using
  attributes: `#[shared] static mut SCRATCH_MEMORY: [f32; 64]` but hasn't been
  implemented yet.

- Built-in targets. This PR doesn't add targets to the compiler just yet but one
  can create custom targets to be able to emit PTX code (see the example at the
  end). The idea is to have people experiment with this feature before
  committing to it (built-in targets are "insta-stable")

- All functions must be "inlined". IOW, the `.rlib` must always contain the LLVM
  bitcode of all the functions of the crate it was produced from. Otherwise, you
  end with "undefined references" in the final PTX code but you won't get *any*
  linker error because no linker is involved. IOW, you'll hit a runtime error
  when loading the PTX into the GPU. The workaround is to use `#[inline]` on
  non-generic functions and to never use `#[inline(never)]` but this may not
  always be possible because e.g. you could be relying on third party code.

- Should `--emit=asm` generate a `.ptx` file instead of a `.s` file?

TL;DR Use Xargo to turn a crate into a PTX module (a `.s` file). Then pass that
PTX module, as a string, to the GPU and run it.

The full code is in [this repository]. This section gives an overview of how to
run Rust code on a NVIDIA GPU.

[this repository]: https://github.com/japaric/cuda

- Create a custom target. Here's the 64-bit NVPTX target (NOTE: the comments
  are not valid because this is supposed to be a JSON file; remove them before
  you use this file):

``` js
// nvptx64-nvidia-cuda.json
{
  "arch": "nvptx64",  // matches LLVM
  "cpu": "sm_20",  // "oldest" compute capability supported by LLVM
  "data-layout": "e-i64:64-v16:16-v32:32-n16:32:64",
  "llvm-target": "nvptx64-nvidia-cuda",
  "max-atomic-width": 0,  // LLVM errors with any other value :-(
  "os": "cuda",  // matches LLVM
  "panic-strategy": "abort",
  "target-endian": "little",
  "target-pointer-width": "64",
  "target-vendor": "nvidia",  // matches LLVM -- not required
}
```

(There's a 32-bit target specification in the linked repository)

- Write a kernel

``` rust

extern "platform-intrinsic" {
    fn nvptx_block_dim_x() -> i32;
    fn nvptx_block_idx_x() -> i32;
    fn nvptx_thread_idx_x() -> i32;
}

/// Copies an array of `n` floating point numbers from `src` to `dst`
pub unsafe extern "ptx-kernel" fn memcpy(dst: *mut f32,
                                         src: *const f32,
                                         n: usize) {
    let i = (nvptx_block_dim_x() as isize)
        .wrapping_mul(nvptx_block_idx_x() as isize)
        .wrapping_add(nvptx_thread_idx_x() as isize);

    if (i as usize) < n {
        *dst.offset(i) = *src.offset(i);
    }
}
```

- Emit PTX code

```
$ xargo rustc --target nvptx64-nvidia-cuda --release -- --emit=asm
   Compiling core v0.0.0 (file://..)
   (..)
   Compiling nvptx-builtins v0.1.0 (https://github.com/japaric/nvptx-builtins)
   Compiling kernel v0.1.0

$ cat target/nvptx64-nvidia-cuda/release/deps/kernel-*.s
//
// Generated by LLVM NVPTX Back-End
//

.version 3.2
.target sm_20
.address_size 64

        // .globl       memcpy

.visible .entry memcpy(
        .param .u64 memcpy_param_0,
        .param .u64 memcpy_param_1,
        .param .u64 memcpy_param_2
)
{
        .reg .pred      %p<2>;
        .reg .s32       %r<5>;
        .reg .s64       %rd<12>;

        ld.param.u64    %rd7, [memcpy_param_2];
        mov.u32 %r1, %ntid.x;
        mov.u32 %r2, %ctaid.x;
        mul.wide.s32    %rd8, %r2, %r1;
        mov.u32 %r3, %tid.x;
        cvt.s64.s32     %rd9, %r3;
        add.s64         %rd10, %rd9, %rd8;
        setp.ge.u64     %p1, %rd10, %rd7;
        @%p1 bra        LBB0_2;
        ld.param.u64    %rd3, [memcpy_param_0];
        ld.param.u64    %rd4, [memcpy_param_1];
        cvta.to.global.u64      %rd5, %rd4;
        cvta.to.global.u64      %rd6, %rd3;
        shl.b64         %rd11, %rd10, 2;
        add.s64         %rd1, %rd6, %rd11;
        add.s64         %rd2, %rd5, %rd11;
        ld.global.u32   %r4, [%rd2];
        st.global.u32   [%rd1], %r4;
LBB0_2:
        ret;
}
```

- Run it on the GPU

``` rust
// `kernel.ptx` is the `*.s` file we got in the previous step
const KERNEL: &'static str = include_str!("kernel.ptx");

driver::initialize()?;

let device = Device(0)?;
let ctx = device.create_context()?;
let module = ctx.load_module(KERNEL)?;
let kernel = module.function("memcpy")?;

let h_a: Vec<f32> = /* create some random data */;
let h_b = vec![0.; N];

let d_a = driver::allocate(bytes)?;
let d_b = driver::allocate(bytes)?;

// Copy from host to GPU
driver::copy(h_a, d_a)?;

// Run `memcpy` on the GPU
kernel.launch(d_b, d_a, N)?;

// Copy from GPU to host
driver::copy(d_b, h_b)?;

// Verify
assert_eq!(h_a, h_b);

// `d_a`, `d_b`, `h_a`, `h_b` are dropped/freed here
```

---

cc @alexcrichton @brson @rkruppe

> What has changed since #34195?

- `core` now can be compiled into PTX. Which makes it very easy to turn `no_std`
  crates into "kernels" with the help of Xargo.

- There's now a way, the `"ptx-kernel"` ABI, to generate "global" functions. The
  old PR required a manual step (it was hack) to "convert" "device" functions
  into "global" functions. (Only "global" functions can be launched by the host)

- Everything is unstable. There are not "insta stable" built-in targets this
  time (\*). The users have to use a custom target to experiment with this
  feature. Also, PTX instrinsics, like `__syncthreads` and `blockIdx.x`, are now
  implemented as `"platform-intrinsics"` so they no longer live in the `core`
  crate.

(\*) I'd actually like to have in-tree targets because that makes this target
more discoverable, removes the need to lug around .json files, etc.

However, bundling a target with the compiler immediately puts it in the path
towards stabilization. Which gives us just two cycles to find and fix any
problem with the target specification. Afterwards, it becomes hard to tweak
the specification because that could be a breaking change.

A possible solution could be "unstable built-in targets". Basically, to use an
unstable target, you'll have to also pass `-Z unstable-options` to the compiler.
And unstable targets, being unstable, wouldn't be available on stable.

> Why should this be merged?

- To let people experiment with the feature out of tree. Having easy access to
  the feature (in every nightly) allows this. I also think that, as it is, it
  should be possible to start prototyping type-safe single source support using
  build scripts, macros and/or plugins.

- It's a straightforward implementation. No different that adding support for
  any other architecture.
2016-12-29 17:26:15 -08:00
Alex Crichton
03bc2cf35a Fallout from updating bootstrap Cargo 2016-12-29 08:47:26 -08:00
Jorge Aparicio
18d49288d5 PTX support
- `--emit=asm --target=nvptx64-nvidia-cuda` can be used to turn a crate
  into a PTX module (a `.s` file).

- intrinsics like `__syncthreads` and `blockIdx.x` are exposed as
  `"platform-intrinsics"`.

- "cabi" has been implemented for the nvptx and nvptx64 architectures.
  i.e. `extern "C"` works.

- a new ABI, `"ptx-kernel"`. That can be used to generate "global"
  functions. Example: `extern "ptx-kernel" fn kernel() { .. }`. All
  other functions are "device" functions.
2016-12-26 21:06:23 -05:00
bors
b7e5148bbd Auto merge of #38314 - japaric:do-not-delete-enable-llvm-backend, r=alexcrichton
initial SPARC support

### UPDATE

Can now compile `no_std` executables with:

```
$ cargo new --bin app && cd $_

$ edit Cargo.toml && tail -n2 $_
[dependencies]
core = { path = "/path/to/rust/src/libcore" }

$ edit src/main.rs && cat $_
#![feature(lang_items)]
#![no_std]
#![no_main]

#[no_mangle]
pub fn _start() -> ! {
    loop {}
}

#[lang = "panic_fmt"]
fn panic_fmt() -> ! {
    loop {}
}

$ edit sparc-none-elf.json && cat $_
{
  "arch": "sparc",
  "data-layout": "E-m:e-p:32:32-i64:64-f128:64-n32-S64",
  "executables": true,
  "llvm-target": "sparc",
  "os": "none",
  "panic-strategy": "abort",
  "target-endian": "big",
  "target-pointer-width": "32"
}

$ cargo rustc --target sparc-none-elf -- -C linker=sparc-unknown-elf-gcc -C link-args=-nostartfiles

$ file target/sparc-none-elf/debug/app
app: ELF 32-bit MSB executable, SPARC, version 1 (SYSV), statically linked, not stripped

$ sparc-unknown-elf-readelf -h target/sparc-none-elf/debug/app
ELF Header:
  Magic:   7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, big endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Sparc
  Version:                           0x1
  Entry point address:               0x10074
  Start of program headers:          52 (bytes into file)
  Start of section headers:          1188 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         2
  Size of section headers:           40 (bytes)
  Number of section headers:         14
  Section header string table index: 11

$ sparc-unknown-elf-objdump -Cd target/sparc-none-elf/debug/app

target/sparc-none-elf/debug/app:     file format elf32-sparc

Disassembly of section .text:

00010074 <_start>:
   10074:       9d e3 bf 98     save  %sp, -104, %sp
   10078:       10 80 00 02     b  10080 <_start+0xc>
   1007c:       01 00 00 00     nop
   10080:       10 80 00 02     b  10088 <_start+0x14>
   10084:       01 00 00 00     nop
   10088:       10 80 00 00     b  10088 <_start+0x14>
   1008c:       01 00 00 00     nop
```

---

Someone wants to attempt launching some Rust [into space](https://www.reddit.com/r/rust/comments/5h76oa/c_interop/) but their platform is based on the SPARCv8 architecture. Let's not block them by enabling LLVM's SPARC backend.

Something very important that they'll also need is the "cabi" stuff as they'll be embedding some Rust code into a bigger C application (i.e. heavy use of `extern "C"`). The question there is what name(s) should we use for "target_arch" as the "cabi" implementation [varies according to that parameter](https://github.com/rust-lang/rust/blob/1.13.0/src/librustc_trans/abi.rs#L498-L523).

AFAICT, SPARCv8 is a 32-bit architecture and SPARCv9 is a 64-bit architecture. And, LLVM uses `sparc`, `sparcv9` and `sparcel` for [the architecture triple](ac1c94226e/include/llvm/ADT/Triple.h (L67-L69)) so perhaps we should use `target_arch = "sparc"` (32-bit) and `target_arch = "sparcv9"` (64-bit) as well.

r? @alexcrichton This PR only enables this LLVM backend when rustbuild is used. Do I also need to implement this for the old Makefile-based build system? Or are all our nightlies now being generated using rustbuild?

cc @brson
2016-12-26 20:48:43 +00:00
bors
f536d90c78 Auto merge of #38542 - YaLTeR:fastcall-fix, r=pnkfelix
Fix fastcall not applying inreg attributes to arguments

Fixes https://github.com/rust-lang/rust/issues/18086
2016-12-26 17:23:42 +00:00
Mark Simulacrum
afc2dcd0ca Make drop glue for unsized value pass two arguments instead of *(data, meta) 2016-12-21 12:02:09 -07:00
Ivan Molodetskikh
c461cdfdf6
Fixed fastcall not applying inreg attributes to arguments like the C/C++ fastcall. 2016-12-21 21:44:40 +03:00
Mark-Simulacrum
cbbdb73eb0 Remove FunctionContext::cleanup, replacing it with a Drop impl.
Move alloca and initial entry block creation into FunctionContext::new.
2016-12-20 20:03:27 -07:00
Jorge Aparicio
3ae912ac5d fix tidy 2016-12-19 12:23:56 -05:00
Jorge Aparicio
bea6ab23f9 enable LLVM's SPARC backend 2016-12-19 12:23:37 -05:00
Sébastien Marie
2c39ee12a9 OpenBSD has two stdc++ libraries: use the newer
stdc++ is from base, and is an old library (GCC 4.2)
estdc++ is from ports, and is a recent library (GCC 4.9 currently)

as LLVM requires the newer version, use it if under OpenBSD.
2016-12-18 18:43:05 +01:00
Jake Goulding
5bce12c95f [LLVM 4.0] Move debuginfo alignment argument
Alignment was removed from createBasicType and moved to

- createGlobalVariable
- createAutoVariable
- createStaticMemberType (unused in Rust)
- createTempGlobalVariableFwdDecl (unused in Rust)

e69c459a6e
2016-12-12 09:00:04 -05:00
bors
1692c0b587 Auto merge of #37973 - vadimcn:dllimport, r=alexcrichton
Implement RFC 1717

Implement the first two points from #37403.

r? @alexcrichton
2016-12-06 10:54:45 +00:00
Michael Woerister
d1a6d47f94 Make LLVM symbol visibility FFI types more stable. 2016-12-05 11:05:25 -05:00
bors
125474de07 Auto merge of #37857 - shepmaster:llvm-4.0-dinodes, r=michaelwoerister
[LLVM 4.0] Handle new DIFlags enum
2016-12-04 02:30:23 +00:00
bors
2cdbd5eb42 Auto merge of #38079 - BurntSushi:attrtarget, r=alexcrichton
Add new #[target_feature = "..."] attribute.

This commit adds a new attribute that instructs the compiler to emit
target specific code for a single function. For example, the following
function is permitted to use instructions that are part of SSE 4.2:

    #[target_feature = "+sse4.2"]
    fn foo() { ... }

In particular, use of this attribute does not require setting the
-C target-feature or -C target-cpu options on rustc.

This attribute does not have any protections built into it. For example,
nothing stops one from calling the above `foo` function on hosts without
SSE 4.2 support. Doing so may result in a SIGILL.

I've also expanded the x86 target feature whitelist.
2016-12-03 17:41:14 +00:00
bors
08faff49c3 Auto merge of #38055 - rkruppe:rm-unused-llvm-ffi, r=alexcrichton
Remove unused functions from rustc_llvm
2016-12-03 03:57:57 +00:00
Jake Goulding
dbdd60e6d7 [LLVM] Introduce a stable representation of DIFlags
In LLVM 4.0, this enum becomes an actual type-safe enum, which breaks
all of the interfaces. Introduce our own copy of the bitflags that we
can then safely convert to the LLVM one.
2016-12-02 21:13:31 -05:00
Vadim Chugunov
a9a6f8c8ed Remove the "linked_from" feature. 2016-12-01 16:56:49 -08:00
bors
908dba0c94 Auto merge of #38048 - rkruppe:llvm-stringref-fixes, r=alexcrichton
[LLVM 4.0] Don't assume llvm::StringRef is null terminated

StringRefs have a length and their contents are not usually null-terminated. The solution is to either copy the string data (in `rustc_llvm::diagnostic`) or take the size into account (in LLVMRustPrintPasses).

I couldn't trigger a bug caused by this (apparently all the strings returned in practice are actually null-terminated) but this is more correct and more future-proof.

cc #37609
2016-12-01 15:21:11 +00:00
Alex Crichton
2186660b51 Update the bootstrap compiler
Now that we've got a beta build, let's use it!
2016-11-30 10:38:08 -08:00
Andrew Gallant
80ef1dbf2d Add new #[target_feature = "..."] attribute.
This commit adds a new attribute that instructs the compiler to emit
target specific code for a single function. For example, the following
function is permitted to use instructions that are part of SSE 4.2:

    #[target_feature = "+sse4.2"]
    fn foo() { ... }

In particular, use of this attribute does not require setting the
-C target-feature or -C target-cpu options on rustc.

This attribute does not have any protections built into it. For example,
nothing stops one from calling the above `foo` function on hosts without
SSE 4.2 support. Doing so may result in a SIGILL.

This commit also expands the target feature whitelist to include lzcnt,
popcnt and sse4a. Namely, lzcnt and popcnt have their own CPUID bits,
but were introduced with SSE4.
2016-11-29 20:32:14 -05:00
Robin Kruppe
6e35cc94de Remove unused functions from rustc_llvm 2016-11-28 21:59:26 +01:00
Robin Kruppe
85dc08e525 Don't assume llvm::StringRef is null terminated
StringRefs have a length and their contents are not usually null-terminated.
The solution is to either copy the string data (in rustc_llvm::diagnostic) or take the size into account (in LLVMRustPrintPasses).
I couldn't trigger a bug caused by this (apparently all the strings returned in practice are actually null-terminated) but this is more correct and more future-proof.
2016-11-28 17:33:13 +01:00
Robin Kruppe
730400167a Support LLVM 4.0 in OptimizationDiagnostic FFI
- getMsg() changed to return std::string by-value. Fix: copy the data to a rust String during unpacking.
- getPassName() changed to return StringRef
2016-11-24 17:33:47 +01:00
Seo Sanghyeon
c45f3dee10 Restore compatibility with LLVM 3.7 and 3.8 2016-11-21 20:30:05 +09:00
bors
0bd2ce62b2 Auto merge of #37831 - rkruppe:llvm-attr-fwdcompat, r=eddyb
[LLVM 4.0] Use llvm::Attribute APIs instead of "raw value" APIs

The latter will be removed in LLVM 4.0 (see 4a6fc8bacf).

The librustc_llvm API remains mostly unchanged, except that llvm::Attribute is no longer a bitflag but represents only a *single* attribute.
The ability to store many attributes in a small number of bits and modify them without interacting with LLVM is only used in rustc_trans::abi and closely related modules, and only attributes for function arguments are considered there.
Thus rustc_trans::abi now has its own bit-packed representation of argument attributes, which are translated to rustc_llvm::Attribute when applying the attributes.

cc #37609
2016-11-19 16:39:25 -06:00
bors
b1da18fe9b Auto merge of #37822 - cuviper:llvm-link-shared, r=alexcrichton
rustbuild: allow dynamically linking LLVM

The makefiles and `mklldeps.py` called `llvm-config --shared-mode` to
find out if LLVM defaulted to shared or static libraries, and just went
with that.  But under rustbuild, `librustc_llvm/build.rs` was assuming
that LLVM should be static, and even forcing `--link-static` for 3.9+.

Now that build script also uses `--shared-mode` to learn the default,
which should work better for pre-3.9 configured for dynamic linking, as
it wasn't possible back then to choose differently via `llvm-config`.

Further, the configure script now has a new `--enable-llvm-link-shared`
option, which allows one to manually override `--link-shared` on 3.9+
instead of forcing static.

Update: There are now four static/shared scenarios that can happen
for the supported LLVM versions:

- 3.9+: By default use `llvm-config --link-static`
- 3.9+ and `--enable-llvm-link-shared`: Use `--link-shared` instead.
- 3.8: Use `llvm-config --shared-mode` and go with its answer.
- 3.7: Just assume static, maintaining the status quo.
2016-11-19 08:08:26 -08:00
Josh Stone
f3240377e6 rustbuild: update the llvm link logic further
There are now four static/shared scenarios that can happen for the
supported LLVM versions:

- 3.9+: By default use `llvm-config --link-static`
- 3.9+ and `--enable-llvm-link-shared`: Use `--link-shared` instead.
- 3.8: Use `llvm-config --shared-mode` and go with its answer.
- 3.7: Just assume static, maintaining the status quo.
2016-11-17 21:50:59 -08:00
Robin Kruppe
30daedf603 Use llvm::Attribute API instead of "raw value" APIs, which will be removed in LLVM 4.0.
The librustc_llvm API remains mostly unchanged, except that llvm::Attribute is no longer a bitflag but represents only a *single* attribute.
The ability to store many attributes in a small number of bits and modify them without interacting with LLVM is only used in rustc_trans::abi and closely related modules, and only attributes for function arguments are considered there.
Thus rustc_trans::abi now has its own bit-packed representation of argument attributes, which are translated to rustc_llvm::Attribute when applying the attributes.
2016-11-17 21:12:26 +01:00
Josh Stone
f13391a603 rustbuild: allow dynamically linking LLVM
The makefiles and `mklldeps.py` called `llvm-config --shared-mode` to
find out if LLVM defaulted to shared or static libraries, and just went
with that.  But under rustbuild, `librustc_llvm/build.rs` was assuming
that LLVM should be static, and even forcing `--link-static` for 3.9+.

Now that build script also uses `--shared-mode` to learn the default,
which should work better for pre-3.9 configured for dynamic linking, as
it wasn't possible back then to choose differently via `llvm-config`.

Further, the configure script now has a new `--enable-llvm-link-shared`
option, which allows one to manually override `--link-shared` on 3.9+
instead of forcing static.
2016-11-16 23:28:14 -08:00
Jorge Aparicio
456ceba137 fix extern "aapcs" fn
to actually use the AAPCS calling convention

closes #37810

This is technically a [breaking-change] because it changes the ABI of
`extern "aapcs"` functions that (a) involve `f32`/`f64` arguments/return
values and (b) are compiled for arm-eabihf targets from
"aapcs-vfp" (wrong) to "aapcs" (correct).

Appendix:

What these ABIs mean?

- In the "aapcs-vfp" ABI or "hard float" calling convention: Floating
point values are passed/returned through FPU registers (s0, s1, d0, etc.)

- Whereas, in the "aapcs" ABI or "soft float" calling convention:
Floating point values are passed/returned through general purpose
registers (r0, r1, etc.)

Mixing these ABIs can cause problems if the caller assumes that the
routine is using one of these ABIs but it's actually using the other
one.
2016-11-16 18:38:32 -05:00
Robin Kruppe
5887ee5018 Rebuild rustc_llvm when the rustllvm source files change 2016-11-16 23:34:15 +01:00
bors
30857ae8f6 Auto merge of #37714 - alexcrichton:builtins-hidden, r=nikomatsakis
rustc: Flag all builtins functions as hidden

When compiling compiler-rt you typically compile with `-fvisibility=hidden`
which to ensure that all symbols are hidden in shared objects and don't show up
in symbol tables. This is important for these intrinsics being linked in every
crate to ensure that we're not unnecessarily bloating the public ABI of Rust
crates.

This should help allow the compiler-builtins project with Rust-defined builtins
start landing in-tree as well.
2016-11-15 04:42:28 -08:00
Jorge Aparicio
f5a05adb25 enable the MSP430 LLVM backend
to let people experiment with this target out of tree.

The MSP430 architecture is used in 16-bit microcontrollers commonly used
in Digital Signal Processing applications.
2016-11-12 17:33:35 -05:00
Alex Crichton
88b46460fa rustc: Flag all builtins functions as hidden
When compiling compiler-rt you typically compile with `-fvisibility=hidden`
which to ensure that all symbols are hidden in shared objects and don't show up
in symbol tables. This is important for these intrinsics being linked in every
crate to ensure that we're not unnecessarily bloating the public ABI of Rust
crates.

This should help allow the compiler-builtins project with Rust-defined builtins
start landing in-tree as well.
2016-11-12 10:46:15 -08:00
Jeffrey Seyfried
dd0781ea25 Register and stability check #[no_link] crates. 2016-11-10 09:21:29 +00:00
Alex Crichton
cc2c812701 rustc_llvm: Require 3.9 for --link-static
Apparently stock Ubuntu 16.04 includes LLVM 3.8 which doesn't have this flag.
2016-11-09 09:12:38 -08:00
pweyck
bcfbbd8645 Force static linking of LLVM
Run llvm-config with "--link-static" if available, to force static linking of LLVM.
This option was added in LLVM 3.8.

Fixes #36854
See also: #36996
2016-11-06 16:33:34 +01:00
Srinivas Reddy Thatiparthy
9972d17ecf
run rustfmt on librustc_llvm folder 2016-10-22 18:37:35 +05:30
Michael Woerister
db4a9b3446 debuginfo: Remove some outdated stuff from LLVM DIBuilder binding. 2016-10-14 14:56:33 -04:00
Brian Anderson
37abec06e5 Tidy 2016-09-30 14:02:51 -07:00
Jan-Erik Rediger
cb3f5799f4 Make the jsbackend an optional component 2016-09-30 14:02:41 -07:00
Jan-Erik Rediger
939bd47339 Configure LLVM to use js backend
Initialize the asmjs backend for LLVM
2016-09-30 14:02:39 -07:00
Jake Goulding
cc8727e675 Report which required build-time environment variable is not set 2016-09-25 12:18:09 -04:00
Matt Ickstadt
b9a8c1a063 Fix incorrect LLVM Linkage enum
The `Linkage` enum in librustc_llvm got out of sync with the version in LLVM and it caused two variants of the #[linkage=""] attribute to break.

This adds the functions `LLVMRustGetLinkage` and `LLVMRustSetLinkage` which convert between the Rust Linkage enum and the LLVM one, which should stop this from breaking every time LLVM changes it.

Fixes #33992
2016-09-04 16:12:01 -05:00
CensoredUsername
516519ee9a Allow specification of the system V AMD64 ABI constraint.
This can be specified using `extern sysV64 fn` on all platforms
2016-08-30 16:01:40 +02:00
Jorge Aparicio
027eab2f87 initial support for s390x
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.
2016-08-26 21:05:50 -05:00
Vadim Chugunov
cf6461168f Fix debug line info for macro expansions.
Macro expansions produce code tagged with debug locations that are completely different from the surrounding expressions.  This wrecks havoc on debugger's ability the step over source lines.

In order to have a good line stepping behavior in debugger, we overwrite debug locations of macro expansions with that of the outermost expansion site.
2016-08-25 00:40:42 -07:00
Cameron Hart
cbb88faad7 Merge branch 'master' into issue-30961 2016-08-06 15:50:48 +10:00
Ariel Ben-Yehuda
3041a97b1a finish type-auditing rustllvm 2016-08-03 15:08:47 +03:00
Ariel Ben-Yehuda
24874170b4 split the FFI part of rustc_llvm to rustc_llvm::ffi 2016-08-03 15:08:47 +03:00
Ariel Ben-Yehuda
d091ef802f begin auditing the C++ types in RustWrapper 2016-08-03 15:08:47 +03:00
Ariel Ben-Yehuda
696691e3c4 audit LLVM C++ types in ArchiveWrapper and PassWrapper 2016-08-03 15:08:47 +03:00
Ariel Ben-Yehuda
81df89fc2d remove the ExecutionEngine binding
the code has no tests and will just bitrot by itself.

this is a [breaking-change]
2016-08-03 15:08:47 +03:00
bors
2c1612c62a Auto merge of #34743 - badboy:llvm-upgrade, r=eddyb
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
2016-08-01 04:47:48 -07:00
Timon Van Overveldt
57cad5722d Update gcc crate dependency to 0.3.27.
This is to pull in changes to support ARM MUSL targets.

This change also commits a couple of other cargo-generated changes
to other dependencies in the various Cargo.toml files.
2016-07-30 15:39:13 -05:00
Cameron Hart
fc210a8994 Make rust build pass LLVM_RUSTLLVM to C++ compiler 2016-07-29 23:09:32 +10:00
Alex Crichton
2492d24baa llvm: Remove no longer existent LLVMAddTargetData binding 2016-07-29 10:29:59 +02:00
Alex Crichton
0509be1f6b Update parsing llvm-config output
Now it prints full paths on MSVC, but we're only interested in path names
2016-07-29 10:29:59 +02:00
Jan-Erik Rediger
9e706f90cb [LLVM-3.9] Configure PIE at the module level instead of compilation unit level
This was deleted here[1] which appears to be replaced by this[2]
which is a new setPIELevel function on the LLVM module itself.

[1]: http://reviews.llvm.org/D19753
[2]: http://reviews.llvm.org/D19671
2016-07-29 10:29:44 +02:00
Jan-Erik Rediger
7420874a97 [LLVM-3.9] Rename custom methods to Rust-specific ones 2016-07-29 10:29:44 +02:00
Cameron Hart
e1efa324ec Add help for target CPUs, features, relocation and code models. 2016-07-11 00:22:13 +10:00
Zack M. Davis
d37edef9dd prefer if let to match with None => {} arm in some places
This is a spiritual succesor to #34268/8531d581, in which we replaced a
number of matches of None to the unit value with `if let` conditionals
where it was judged that this made for clearer/simpler code (as would be
recommended by Manishearth/rust-clippy's `single_match` lint). The same
rationale applies to matches of None to the empty block.
2016-07-03 16:27:02 -07:00
Jake Goulding
3f36f7a980 Remove linking with AR
Since we only support LLVM 3.7 and above, we will never need to use the
AR linker. Remove the possibility of calling it and all the now-dead
code.
2016-06-10 18:26:42 -04:00
Srinivas Reddy Thatiparthy
593e1567ca run rustfmt on librustc_llvm folder 2016-05-29 14:57:34 +05:30
Brandon Edens
b1337d309a Add opt-level options for optimizing for size and minimum size. This attempts
to mimic the behavior of clang's options Os and Oz.
2016-04-28 23:08:30 -07:00
Michael Woerister
0fc9f9a200 Make the codegen unit partitioner also emit item declarations. 2016-04-28 16:53:00 -04:00
bors
92e3fb3ebe Auto merge of #31709 - ranma42:target_feature-from-llvm, r=alexcrichton
Compute `target_feature` from LLVM

This is a work-in-progress fix for #31662.

The logic that computes the target features from the command line has been replaced with queries to the `TargetMachine`.
2016-04-20 09:57:57 -07:00
Michael Woerister
e8441b6784 Add initial version of codegen unit partitioning for incremental compilation. 2016-04-15 10:05:53 -04:00
Andrea Canciani
c883463e94 Implement feature extraction from TargetMachine
Add the `LLVMRustHasFeature` function to check whether a
`TargetMachine` has a given feature.
2016-04-09 00:39:04 +02:00
Björn Steinbrink
22f4587586 Use weak_odr linkage when reusing definitions across codegen units
When reuing a definition across codegen units, we obviously cannot use
internal linkage, but using external linkage means that we can end up
with multiple conflicting definitions of a single symbol across
multiple crates. Since the definitions should all be equal
semantically, we can use weak_odr linkage to resolve the situation.

Fixes #32518
2016-03-29 16:44:54 +02:00
Björn Steinbrink
95697a8395 Fix removal of function attributes on ARM
We use a 64bit integer to pass the set of attributes that is to be
removed, but the called C function expects a 32bit integer. On most
platforms this doesn't cause any problems other than being unable to
unset some attributes, but on  ARM even the lower 32bit aren't handled
correctly because the 64bit value is passed in different registers, so
the C function actually sees random garbage.

So we need to fix the relevant functions to use 32bit integers instead.
Additionally we need an implementation that actually accepts 64bit
integers because some attributes can only be unset that way.

Fixes #32360
2016-03-26 13:02:54 +01:00
Ulrik Sverdrup
2dbac1fb8e Add intrinsics for float arithmetic with fast flag enabled
`fast` a.k.a UnsafeAlgebra is the flag for enabling all "unsafe"
(according to llvm) float optimizations.

See LangRef for more information http://llvm.org/docs/LangRef.html#fast-math-flags

Providing these operations with less precise associativity rules (for
example) is useful to numerical applications.

For example, the summation loop:

    let sum = 0.;
    for element in data {
        sum += *element;
    }

Using the default floating point semantics, this loop expresses the
floats must be added in a sequence, one after another. This constraint
is usually completely unintended, and it means that no autovectorization
is possible.
2016-03-18 17:31:41 +01:00
Eduard Burtescu
77f3484148 trans: Apply all attributes through FnType. 2016-03-17 21:51:51 +02:00