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 🎉
Fix personality_fn within the compiler_builtins
compiler_builtins may not have any unwinding within it to link correctly. This is notoriously
finicky, and this small piece of change removes yet another case where personality function
happens to get introduced.
Side note: I do remember solving the exact same thing before. I wonder why it has reappered...
@cuviper, could you please try building beta with this patch applied? It should apply cleanly. If it works, I’ll nominate to land this into beta.
Fixes(?) https://github.com/rust-lang/rust/issues/40251
compiler_builtins may not have any unwinding within it to link correctly. This is notoriously
finicky, and this small piece of change removes yet another case where personality function
happens to get introduced.
Side note: I do remember solving the exact same thing before. I wonder why it has reappered...
* Update bootstrap to recognize the cputype 'sparcv9' (used on Solaris)
* Change to never use -fomit-frame-pointer on Solaris or for sparc
* Adds rust target sparcv9-sun-solaris
Fixes#39901
Don't use "unadjusted" ABI on non windows platforms
We introduced the unadjusted ABI to work around wrong
(buggy) ABI expectations by LLVM on Windows [1].
Therefore, it should be solely used on Windows and not
on other platforms, like right now is the case.
[1]: see this comment for details https://github.com/rust-lang/rust/pull/38482#issuecomment-269074031
We introduced the unadjusted ABI to work around wrong
(buggy) ABI expectations by LLVM on Windows [1].
Therefore, it should be solely used on Windows and not
on other platforms, like right now is the case.
[1]: see this comment for details https://github.com/rust-lang/rust/pull/38482#issuecomment-269074031
This commit updates the version number to 1.17.0 as we're not on that version of
the nightly compiler, and at the same time this updates src/stage0.txt to
bootstrap from freshly minted beta compiler and beta Cargo.
This expands the `cross` travis matrix entry with a few more targets that our
nightlies are building:
* x86_64-rumprun-netbsd
* arm-unknown-linux-musleabi
* arm-unknown-linux-musleabihf
* armv7-unknown-linux-musleabihf
* mips-unknown-linux-musl
* mipsel-unknown-linux-musl
This commit doesn't compile custom toolchains like our current cross-image does,
but instead compiles musl manually and then compiles libunwind manually (like
x86_64) for use for the ARM targets and just uses openwrt toolchains for the
mips targets.
std: Remove unused objects from compiler-builtins
We don't actually use trampoline_setup.c and all the `*tf3` business
seems related to f80/f128 business. Specifically this'll fix some
warnings showing up during builds on OSX.
i128 and u128 support
Brings i128 and u128 support to nightly rust, behind a feature flag. The goal of this PR is to do the bulk of the work for 128 bit integer support. Smaller but just as tricky features needed for stabilisation like 128 bit enum discriminants are left for future PRs.
Rebased version of #37900, which in turn was a rebase + improvement of #35954 . Sadly I couldn't reopen#37900 due to github. There goes my premium position in the homu queue...
[plugin-breaking-change]
cc #35118 (tracking issue)
There was a linker error on 32 bit platforms with optimisations turned off,
complaining that there was an undefined reference to "rust_eh_personality",
when compiling the rustc_const_math as stage1 artifact.
Apparently the compiler_builtins crate includes a call to "rust_eh_personality".
If compiled for 64 bits, this call doesn't appear, which explains why the linker
error only happens on 32 bit platforms, and optimisations will get it removed
on 32 bit as well.
There were two origins of the call:
1. A for loop where apparently the compiler wasn't sure
whether next() could panic or not, and therefore generated a landing
pad for the worst case. The minimal reproducible example is "for _ in 0..sr { }".
2. A default impl of uabs where the compiler apparently wasn't sure either
whether iabs() could panic or not. Many thanks to nagisa for
contributing the fix.
This commit also puts extern "C" to the intrinsics, as this is generally a
good thing to do.
* shift so that no panics are generated (otherwise results in linker error)
* no_std as insurance to not get into issues with errors like "cannot satisfy dependencies so `rustc_i128` only shows up once" (pure guessing here, but it doesn't hurt...)
The check inside compiler-rt file int_types.h to #define CRT_HAS_128BIT
looks like:
#if (defined(__LP64__) || defined(__wasm__)) && \
!(defined(__mips__) && defined(__clang__))
#define CRT_HAS_128BIT
#endif
Windows uses LLP64 instead of LP64, so it doesn't ship with the C based
intrinsics.
Also, add libcompiler_builtins to the list of crates that may have platform
specific checks (like the ones we just added).
We don't actually use trampoline_setup.c and all the `*tf3` business
seems related to f80/f128 business. Specifically this'll fix some
warnings showing up during builds on OSX.
Fix rustbuild on 32 bit Linux
This is cherry-picked from #37817 which seems to be stalled and currently needs to be rebased anyway.
r? @alexcrichton (who authored this change)
