i128 and u128 support #37900
Closed
i128 and u128 support #37900
Commits on Dec 15, 2016
-
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.
-
-
Feature gate the 128 bit types
Dangling a carrot in front of a donkey. This commit includes manual merge conflict resolution changes from a rebase by @est31.
-
-
Fix LEB128 to work with the stage1
Stage 1 can’t really handle negative 128-bit literals, but an equivalent bit-not is fine
-
This commit includes manual merge conflict resolution changes from a rebase by @est31.
-
Makefiles support for rustc_i128 crate
This commit includes manual merge conflict resolution changes from a rebase by @est31.
-
Wrapping<i128> and attempt at LLVM 3.7 compat
This commit includes manual merge conflict resolution changes from a rebase by @est31.
-
-
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.
-
Implement emit_iu128 for json serialiser
Causes ICEs otherwise while trying to dump AST
-
-
This commit includes manual merge conflict resolution changes from a rebase by @est31.
-
-
-
Use LLVMRustConstInt128Get on stage1 too
llvm::LLVMConstIntGetZExtValue doesn't accept values with more than 64 bits. This fixes an LLVM assertion error when compiling libcore with stage1: src/llvm/include/llvm/ADT/APInt.h:1336: uint64_t llvm::APInt::getZExtValue() const: Assertion `getActiveBits() <= 64 && "Too many bits for uint64_t"' failed.
-
-
Make rustdoc aware of the primitive i128 type
Many thanks to ollie27 for spotting all the places.
-
-
-
-
-
UGLY hack around an ICE bc of stage0
Current stage0 with version "1.14.0-beta.1 (d4aea2d 2016-11-15)" suffers from issue 37686. You can confirm this on master by running ./x.py test --stage 0 src/test/run-pass --test-args 37686 Add this workaround until there is a fix. No idea how it works, but it does work.
-
Always use Rust based intrinsics on Windows
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). -
* 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...)
-
libcompiler_builtins: don't codegen dead code call to eh_personality
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. -
-
Port to wrapping_* and unchecked_* operations
Otherwise, we codegen panic calls which create problems with debug assertions turned on.
-
intrinsics: try to return everything via {u,i}128ret to match LLVM
on suggestion by nagisa.
-
Fix another windows ABI mistake
...this time with the float intrinsics.
-
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.