summary refs log tree commit diff
path: root/src/libcompiler_builtins
AgeCommit message (Collapse)AuthorLines
2018-03-27Update compiler-rt with fix for 32bit iOS ARMTim Neumann-0/+0
2018-03-26did i get it right now?Mark Mansi-0/+0
2018-03-26Update to master of libcompiler_builtinsMark Mansi-0/+0
2018-02-13Update compiler-builtins to latest master.Paolo Teti-0/+0
- Rebase compiler-rt to LLVM 6 - New VFP intrinsics on ARM - Add generic conversion from a narrower to a wider FP type (f32->f64) - Fixes minor issues on _subsf3, __subdf3 and __aeabi_fcmple - Split test suite to a separate crate
2018-02-09rustc: Upgrade to LLVM 6Alex Crichton-0/+0
The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening, but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed, notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch, but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container, I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch), but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies, but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome, along with scrutiny of the "missing patches" like a [change to pass manager order](rust-lang/llvm@27174447533), [another change to pass manager order](rust-lang/llvm@c782febb7b9), some [compile fixes for sparc](rust-lang/llvm@1a83de63c42), and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons, notably: * This'll allow us to keep up with the upstream wasm backend, picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors, especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend, but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction, but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3
2018-01-24Update compiler-builtins submoduleAlex Crichton-0/+0
No sense of urgency, just wanted to make sure we don't lag too far behind!
2017-12-26Update compiler_builtinsMarco A L Barbosa-0/+0
2017-12-23Update compiler_builtinsSam Green-0/+0
2017-12-20Update compiler_builtinsMarco A L Barbosa-0/+0
Fixes https://github.com/rust-lang/rust/issues/46822 (https://github.com/rust-lang-nursery/compiler-builtins/pull/218)
2017-12-02Update compiler-builtins and use it the 128-bit lowering MIR testScott McMurray-0/+0
2017-11-24rustbuild: Update LLVM and enable ThinLTOAlex Crichton-0/+0
This commit updates LLVM to fix #45511 (https://reviews.llvm.org/D39981) and also reenables ThinLTO for libtest now that we shouldn't hit #45768. This also opportunistically enables ThinLTO for libstd which was previously blocked (#45661) on test failures related to debuginfo with a presumed cause of #45511. Closes #45511
2017-11-15Update the compiler-builtins to latest master.Dan Gohman-0/+0
2017-09-30Update the libcompiler_builtins submoduleest31-0/+0
2017-09-13Update compiler-builtinsTamir Duberstein-0/+0
Picks up the removal of the rustbuild feature, which is still used in our local shim, along with a comment update explaining the usage.
2017-09-07Update the libcompiler_builins submoduleest31-0/+0
Pulls in https://github.com/rust-lang-nursery/compiler-builtins/pull/187 for nicer build output :)
2017-08-18Update the compiler_builtins submoduleDylan McKay-0/+0
Fixes #43411
2017-07-07Update compiler_builtins submodule for probestack fixAlex Crichton-0/+0
Closes #43102
2017-07-06rustc: Implement stack probes for x86Alex Crichton-0/+0
This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.
2017-07-05Switch to rust-lang-nursery/compiler-builtinsAlex Crichton-1163/+0
This commit migrates the in-tree `libcompiler_builtins` to the upstream version at https://github.com/rust-lang-nursery/compiler-builtins. The upstream version has a number of intrinsics written in Rust and serves as an in-progress rewrite of compiler-rt into Rust. Additionally it also contains all the existing intrinsics defined in `libcompiler_builtins` for 128-bit integers. It's been the intention since the beginning to make this transition but previously it just lacked the manpower to get done. As this PR likely shows it wasn't a trivial integration! Some highlight changes are: * The PR rust-lang-nursery/compiler-builtins#166 contains a number of fixes across platforms and also some refactorings to make the intrinsics easier to read. The additional testing added there also fixed a number of integration issues when pulling the repository into this tree. * LTO with the compiler-builtins crate was fixed to link in the entire crate after the LTO process as these intrinsics are excluded from LTO. * Treatment of hidden symbols was updated as previously the `#![compiler_builtins]` crate would mark all symbol *imports* as hidden whereas it was only intended to mark *exports* as hidden.
2017-06-01Support VS 2017Brian Anderson-1/+1
Fixes #38584
2017-04-24Auto merge of #40123 - TimNN:llvm40, r=alexcrichtonbors-0/+6
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-23FIN: build comiler-rt wihout Thumb on armTim Neumann-0/+6
2017-04-13Fixed invalid 128-bit division on 32-bit target. Fixed issue #41228.kennytm-1/+1
Added test cases to cover all special-cased branches of udivmodti4.
2017-03-15make shift builtins panic-free with new unchecked_sh* intrinsicsTim Neumann-9/+9
Also update some 128 bit builtins to be panic-free without relying on the const evaluator.
2017-03-08Rollup merge of #40254 - nagisa:compiler-builtin-no-panic, r=alexcrichtonAriel Ben-Yehuda-4/+5
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
2017-03-04Automate timestamp creation and build skipping for native librariesVadim Petrochenkov-9/+6
Add comments
2017-03-04Build compiler-rt and sanitizers only onceVadim Petrochenkov-4/+12
2017-03-04Add/remove `rerun-if-changed` when necessaryVadim Petrochenkov-0/+5
2017-03-04Fix personality_fn within the compiler_builtinsSimonas Kazlauskas-4/+5
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...
2017-02-16add solaris sparcv9 supportShawn Walker-Salas-1/+9
* 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
2017-02-05Rollup merge of #39519 - nagisa:more-snap, r=alexcrichtonCorey Farwell-4/+2
More snap cleanup r? @alexcrichton
2017-02-05Rollup merge of #39472 - est31:unadjusted_only_for_win, r=nagisaCorey Farwell-3/+3
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
2017-02-04Auto merge of #39425 - jakllsch:netbsd-a, r=alexcrichtonbors-1/+1
Don't build gcc_personality_v0.c on NetBSD either
2017-02-04More snap cleanupSimonas Kazlauskas-4/+2
2017-02-04Don't use "unadjusted" ABI on non windows platformsest31-3/+3
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
2017-02-03Bump version, upgrade bootstrapAlex Crichton-136/+57
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.
2017-01-31Don't build gcc_personality_v0.c on NetBSD eitherJonathan A. Kollasch-1/+1
2017-01-16travis: Expand the `cross` linux imageAlex Crichton-1/+0
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.
2017-01-16Fix endian bugs in i128 intrinsic implsSimonas Kazlauskas-5/+4
2017-01-13Rollup merge of #38877 - jdub:patch-1, r=sanxiynGuillaume Gomez-4/+0
libcompiler_builtins: Don't build emutls.c Rather than improving the check, let's ditch emutls.c entirely.
2017-01-10Rollup merge of #38623 - alexcrichton:less-osx-warnings, r=aturonSeo Sanghyeon-6/+0
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.
2017-01-08libcompiler_builtins: Don't build emutls.cJeff Waugh-4/+0
Rather than improving the check, let's ditch emutls.c entirely.
2016-12-31Auto merge of #38482 - est31:i128, r=eddybbors-1/+784
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)
2016-12-31Fix iabs and add some more testsest31-4/+13
2016-12-30std: Don't build docs for misc facade cratesAlex Crichton-0/+1
Retain the same behavior as stable. Closes #38319
2016-12-30Fix warning when compiling on 64 bit Linuxest31-7/+3
Code is much simpler now as well.
2016-12-30Further and hopefully final Windows fixesSimonas Kazlauskas-177/+148
2016-12-30More windows fixesest31-7/+15
2016-12-30Fix buildest31-7/+9
2016-12-30The windows special-cases only apply to x64Simonas Kazlauskas-31/+39