summary refs log tree commit diff
path: root/src/libcompiler_builtins
AgeCommit message (Collapse)AuthorLines
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
2016-12-30Fix a return typeSimonas Kazlauskas-1/+1
2016-12-30Tidyest31-1/+2
2016-12-30Fix another windows ABI mistakeest31-4/+30
...this time with the float intrinsics.
2016-12-30intrinsics: try to return everything via {u,i}128ret to match LLVMest31-38/+99
on suggestion by nagisa.
2016-12-30Tidyest31-4/+8
2016-12-30Port to wrapping_* and unchecked_* operationsest31-78/+118
Otherwise, we codegen panic calls which create problems with debug assertions turned on.
2016-12-30Remove unimplemented() functionest31-8/+2
2016-12-30libcompiler_builtins: don't codegen dead code call to eh_personalityest31-24/+31
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.
2016-12-30Try to fix some thingsest31-2/+2
* 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...)
2016-12-30Always use Rust based intrinsics on Windowsest31-2/+4
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).
2016-12-30Fix warning on 64 bitest31-2/+2
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-04-24 21:03:16 +0000