about summary refs log tree commit diff
path: root/src/librustc_llvm
AgeCommit message (Collapse)AuthorLines
2017-06-30rustc_llvm: re-run build script when env var LLVM_CONFIG changesVenkata Giri Reddy-5/+1
2017-06-20Auto merge of #42571 - tlively:wasm-dev, r=alexcrichtonbors-1/+6
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-19Bump version and stage0 compilerAlex Crichton-4/+0
2017-06-16Add target to use LLVM wasm backendThomas Lively-1/+6
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-14Auto merge of #42433 - marco-c:profiling, r=alexcrichtonbors-0/+4
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-04rustc_llvm: re-run build script if config.toml changesVenkata Giri Reddy-0/+5
2017-06-04Merge branch 'profiling' of github.com:whitequark/rust into profilingMarco Castelluccio-0/+4
2017-06-01Support VS 2017Brian Anderson-1/+1
Fixes #38584
2017-05-26Rollup merge of #42224 - brson:lockfile, r=nikomatsakisCorey Farwell-22/+0
Remove stray lockfile
2017-05-25Remove stray lockfileBrian Anderson-22/+0
2017-05-24add thiscall calling convention supportNathan Froyd-0/+1
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-20Fix: "warning: redundant linker flag specified for library `ole32`"Segev Finer-4/+1
llvm-config seems to output this library name correctly now, removing the need for the hack in "librustc_llvm/build.rs".
2017-05-11rustc: Remove #![unstable] annotationAlex Crichton-3/+4
These are now no longer necessary with `-Z force-unstable-if-unmarked`
2017-05-01Auto merge of #41560 - alevy:rwpi-ropi, r=eddybbors-4/+7
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-01Add profiling support, through the rustc -Z profile flag.whitequark-0/+4
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-04-28Added LLVMRustRelocModeAmit Aryeh Levy-7/+7
Replaces the llvm-c exposed LLVMRelocMode, which does not include all relocation model variants, with a LLVMRustRelocMode modeled after LLVMRustCodeMode.
2017-04-26Add RWPI/ROPI relocation model supportAmit Aryeh Levy-0/+3
Adds support for using LLVM 4's ROPI and RWPI relocation models for ARM
2017-04-25Avoid the hexagon backend on old versions of LLVMMichael Wu-28/+38
2017-04-25Add Hexagon supportMichael Wu-1/+7
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-24Auto merge of #40123 - TimNN:llvm40, r=alexcrichtonbors-0/+5
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: windows-gnu: statically link gcc_s, pthread with llvmTim Neumann-0/+5
2017-04-12Expose LLVM appendModuleInlineAsmA.J. Gardner-0/+1
2017-04-08Specify type libraries for llvm-config --ldflagsSimonas Kazlauskas-0/+3
This matters on systems where static libraries and dynamic libraries reside in different location
2017-03-30Make sure that -lole32 ends up *after* LLVM libs on the linker command line.Vadim Chugunov-7/+6
2017-03-27Fix various useless derefs and slicingsOliver Schneider-2/+2
2017-03-21link agains relocatable libstdc++Tim Neumann-2/+7
2017-03-21ci/netbsd: use the "official" cross compilerTim Neumann-0/+6
2017-03-04Add/remove `rerun-if-changed` when necessaryVadim Petrochenkov-3/+1
2017-03-02Add support for x86-interrupt calling conventionPhilipp Oppermann-0/+1
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-02-13Auto merge of #39456 - nagisa:mir-switchint-everywhere, r=nikomatsakisbors-5/+5
[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-11[LLVM 4.0] Fix CreateCompileUnitMatt Ickstadt-2/+1
2017-02-10Fix intcast, use it where appropriateSimonas Kazlauskas-5/+5
2017-02-09Auto merge of #38109 - tromey:main-subprogram, r=michaelwoeristerbors-0/+1
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-08Rollup merge of #38699 - japaric:lsan, r=alexcrichtonCorey Farwell-0/+3
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::thread::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::imp::thread::Thread::new::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::imp::thread::Thread::new::hce44187bf4a36222 <null> (racy+0x0000000ab9ae) #2 std::thread::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-08build/test the sanitizers only when --enable-sanitizers is usedJorge Aparicio-1/+1
2017-02-08sanitizer supportJorge Aparicio-0/+3
2017-02-08Rollup merge of #39529 - dylanmckay:llvm-4.0-align32, r=alexcrichtonCorey Farwell-10/+10
[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-06std: Remove cfg(cargobuild) annotationsAlex Crichton-12/+0
These are all now no longer needed that we've only got rustbuild in tree.
2017-02-04Emit DW_AT_main_subprogramTom Tromey-0/+1
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[llvm] Use 32-bits for alignmentDylan McKay-10/+10
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-04Support a debug info API change for LLVM 4.0Dylan McKay-0/+6
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-01-26Remove unnecessary LLVMRustPersonalityFn bindingSimonas Kazlauskas-1/+1
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-18calling convention for MSP430 interruptsJorge Aparicio-0/+1
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-08Auto merge of #38679 - alexcrichton:always-deny-warnings, r=nrcbors-1/+1
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-01Auto merge of #38745 - CannedYerins:llvm-code-style, r=rkruppebors-4/+4
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
2016-12-31Improve naming style in rustllvm.Ian Kerins-4/+4
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-31Calculate discriminant bounds within 64 bitsSimonas Kazlauskas-1/+1
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-30Add a way to retrieve constant value in 128 bitsSimonas Kazlauskas-0/+2
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-30Wrapping<i128> and attempt at LLVM 3.7 compatSimonas Kazlauskas-1/+0
This commit includes manual merge conflict resolution changes from a rebase by @est31.
2016-12-30Such large. Very 128. Much bits.Simonas Kazlauskas-0/+2
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.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-08 04:11:52 +0000