about summary refs log tree commit diff
path: root/src/rustllvm/RustWrapper.cpp
AgeCommit message (Collapse)AuthorLines
2017-04-12Expose LLVM appendModuleInlineAsmA.J. Gardner-0/+4
2017-03-16add missing global metadataTim Neumann-3/+8
2017-03-16clang-formatTim Neumann-5/+2
2017-03-16isolate llvm 4.0 code pathTim Neumann-12/+6
2017-02-13Auto merge of #39456 - nagisa:mir-switchint-everywhere, r=nikomatsakisbors-0/+6
[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-3/+11
2017-02-10Fix intcast, use it where appropriateSimonas Kazlauskas-0/+6
2017-02-09Auto merge of #38109 - tromey:main-subprogram, r=michaelwoeristerbors-0/+6
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/+6
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-08sanitizer supportJorge Aparicio-0/+6
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-04Emit DW_AT_main_subprogramTom Tromey-0/+6
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/+4
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-8/+0
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-14Fix covered-switch-default warnings in RustWrapperRuud van Asseldonk-10/+4
These switch statements cover all possible values, so the default case is dead code (it contains an llvm_unreachable anyway), triggering a -Wcovered-switch-default warning. Moving the unreachable after the switch resolves these warnings. This keeps the build output clean.
2017-01-01Auto merge of #38745 - CannedYerins:llvm-code-style, r=rkruppebors-261/+262
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-31Auto merge of #38482 - est31:i128, r=eddybbors-0/+17
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-31Improve naming style in rustllvm.Ian Kerins-261/+262
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-30Switching from NULL to nullptr in src/rustllvm.karpinski-11/+11
2016-12-30Ran clang-format on src/rustllvm with llvm as the coding style.karpinski-1004/+793
2016-12-30Fix rebase falloutSimonas Kazlauskas-0/+1
This commit includes manual merge conflict resolution changes from a rebase by @est31.
2016-12-30Add a way to retrieve constant value in 128 bitsSimonas Kazlauskas-0/+16
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-21Fixed fastcall not applying inreg attributes to arguments like the C/C++ ↵Ivan Molodetskikh-0/+2
fastcall.
2016-12-14Update LLVM global variable debug info API for 4.0Dylan McKay-5/+20
This teaches Rust about an LLVM 4.0 API change for creating debug info for global variables. This change was made in upstream LLVM patch https://reviews.llvm.org/D20147 This is almost 1:1 copy of how clang did it in http://reviews.llvm.org/D20415
2016-12-12[LLVM 4.0] Move debuginfo alignment argumentJake Goulding-8/+29
Alignment was removed from createBasicType and moved to - createGlobalVariable - createAutoVariable - createStaticMemberType (unused in Rust) - createTempGlobalVariableFwdDecl (unused in Rust) https://github.com/llvm-mirror/llvm/commit/e69c459a6e9756ca1ff3acb1dcfc434843aee80f
2016-12-08Auto merge of #38156 - shepmaster:llvm-4.0-bitcode-reader-writer, r=alexcrichtonbors-1/+16
[LLVM 4.0] New bitcode headers and API /cc @michaelwoerister @rkruppe
2016-12-05Make LLVM symbol visibility FFI types more stable.Michael Woerister-0/+42
2016-12-04[LLVM 4.0] New bitcode headers and APIJake Goulding-1/+16
2016-12-02[LLVM 4.0] Support new DIFlags enumJake Goulding-0/+5
2016-12-02[LLVM] Introduce a stable representation of DIFlagsJake Goulding-13/+93
In LLVM 4.0, this enum becomes an actual type-safe enum, which breaks all of the interfaces. Introduce our own copy of the bitflags that we can then safely convert to the LLVM one.
2016-11-28Don't assume llvm::StringRef is null terminatedRobin Kruppe-8/+5
StringRefs have a length and their contents are not usually null-terminated. The solution is to either copy the string data (in rustc_llvm::diagnostic) or take the size into account (in LLVMRustPrintPasses). I couldn't trigger a bug caused by this (apparently all the strings returned in practice are actually null-terminated) but this is more correct and more future-proof.
2016-11-25Auto merge of #38000 - rkruppe:llvm-dinamespace-fwdcompat, r=alexcrichtonbors-1/+5
[LLVM 4.0] Pass new argument ExportSymbol to DIBuilder::createNameSpace cc #37609
2016-11-25Pass new argument ExportSymbol to DIBuilder::createNameSpaceRobin Kruppe-1/+5
2016-11-24Support LLVM 4.0 in OptimizationDiagnostic FFIRobin Kruppe-2/+7
- getMsg() changed to return std::string by-value. Fix: copy the data to a rust String during unpacking. - getPassName() changed to return StringRef
2016-11-21Restore compatibility with LLVM 3.7 and 3.8Seo Sanghyeon-10/+9
2016-11-17Use llvm::Attribute API instead of "raw value" APIs, which will be removed ↵Robin Kruppe-45/+70
in LLVM 4.0. The librustc_llvm API remains mostly unchanged, except that llvm::Attribute is no longer a bitflag but represents only a *single* attribute. The ability to store many attributes in a small number of bits and modify them without interacting with LLVM is only used in rustc_trans::abi and closely related modules, and only attributes for function arguments are considered there. Thus rustc_trans::abi now has its own bit-packed representation of argument attributes, which are translated to rustc_llvm::Attribute when applying the attributes.
2016-10-14debuginfo: Remove some outdated stuff from LLVM DIBuilder binding.Michael Woerister-20/+1
2016-09-26Extend preprocessor LLVM version checks to support LLVM 4.xJake Goulding-15/+15
This doesn't actually do anything for LLVM 4.x yet, but sets the stage.
2016-09-04Fix incorrect LLVM Linkage enumMatt Ickstadt-0/+80
The `Linkage` enum in librustc_llvm got out of sync with the version in LLVM and it caused two variants of the #[linkage=""] attribute to break. This adds the functions `LLVMRustGetLinkage` and `LLVMRustSetLinkage` which convert between the Rust Linkage enum and the LLVM one, which should stop this from breaking every time LLVM changes it. Fixes #33992
2016-08-25Fix debug line info for macro expansions. Vadim Chugunov-0/+9
Macro expansions produce code tagged with debug locations that are completely different from the surrounding expressions. This wrecks havoc on debugger's ability the step over source lines. In order to have a good line stepping behavior in debugger, we overwrite debug locations of macro expansions with that of the outermost expansion site.
2016-08-03finish type-auditing rustllvmAriel Ben-Yehuda-36/+66
2016-08-03begin auditing the C++ types in RustWrapperAriel Ben-Yehuda-194/+322
2016-07-29[LLVM-3.9] Rename custom methods to Rust-specific onesJan-Erik Rediger-2/+2
2016-06-09Reflect supporting only LLVM 3.7+ in the LLVM wrappersJake Goulding-140/+3
2016-03-29Use weak_odr linkage when reusing definitions across codegen unitsBjörn Steinbrink-0/+13
When reuing a definition across codegen units, we obviously cannot use internal linkage, but using external linkage means that we can end up with multiple conflicting definitions of a single symbol across multiple crates. Since the definitions should all be equal semantically, we can use weak_odr linkage to resolve the situation. Fixes #32518
2016-03-26Fix removal of function attributes on ARMBjörn Steinbrink-0/+10
We use a 64bit integer to pass the set of attributes that is to be removed, but the called C function expects a 32bit integer. On most platforms this doesn't cause any problems other than being unable to unset some attributes, but on ARM even the lower 32bit aren't handled correctly because the 64bit value is passed in different registers, so the C function actually sees random garbage. So we need to fix the relevant functions to use 32bit integers instead. Additionally we need an implementation that actually accepts 64bit integers because some attributes can only be unset that way. Fixes #32360
2016-03-19Fix LLVMRustSetHasUnsafeAlgebra to only have effect on instructionsUlrik Sverdrup-2/+4
2016-03-18Add intrinsics for float arithmetic with `fast` flag enabledUlrik Sverdrup-0/+5
`fast` a.k.a UnsafeAlgebra is the flag for enabling all "unsafe" (according to llvm) float optimizations. See LangRef for more information http://llvm.org/docs/LangRef.html#fast-math-flags Providing these operations with less precise associativity rules (for example) is useful to numerical applications. For example, the summation loop: let sum = 0.; for element in data { sum += *element; } Using the default floating point semantics, this loop expresses the floats must be added in a sequence, one after another. This constraint is usually completely unintended, and it means that no autovectorization is possible.
2016-02-24Implement filling drop in MIRSimonas Kazlauskas-0/+5
Hopefully the author caught all the cases. For the mir_dynamic_drops_3 test case the ratio of memsets to other instructions is 12%. On the other hand we actually do not double drop for at least the test cases provided anymore in MIR.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-20 05:59:09 +0000