https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.9.0 2016-01-25T05:15:39+00:00 2016-01-25T05:15:39+00:00 Corey Farwell coreyf@rwell.org 2016-01-25T01:22:24+00:00 urn:sha1:d9426210b197cb0be1db9838342349f38db135e3 LLVM was upgraded to a new version in this commit: https://github.com/rust-lang/rust/commit/f9d4149c29e8b989fa3624993be379f380e48dcf which was part of this pull request: https://github.com/rust-lang/rust/issues/26025 Consider the following two lines from that commit: https://github.com/rust-lang/rust/commit/f9d4149c29e8b989fa3624993be379f380e48dcf#diff-a3b24dbe2ea7c1981f9ac79f9745f40aL462 https://github.com/rust-lang/rust/commit/f9d4149c29e8b989fa3624993be379f380e48dcf#diff-a3b24dbe2ea7c1981f9ac79f9745f40aL469 The purpose of these lines is to register LLVM passes. Prior to the that commit, the passes being handled were assumed to be ModulePasses (a specific type of LLVM pass) since they were being added to a ModulePass manager. After that commit, both lines were refactored (presumably in an attempt to DRY out the code), but the ModulePasses were changed to be registered to a FunctionPass manager. This change resulted in ModulePasses being run, but a Function object was being passed as a parameter to the pass instead of a Module, which resulted in segmentation faults. In this commit, I changed relevant sections of the code to check the type of the passes being added and register them to the appropriate pass manager. Closes https://github.com/rust-lang/rust/issues/31067 2015-11-20T00:58:23+00:00 Brian Anderson banderson@mozilla.com 2015-11-19T19:32:16+00:00 urn:sha1:99741700e54ce98c12eb754b60917de21c75c2f4 2015-10-24T09:42:23+00:00 Seo Sanghyeon sanxiyn@gmail.com 2015-10-24T09:42:23+00:00 urn:sha1:b285f9202590050a7b480a99a074673630b11f4f 2015-10-13T06:11:59+00:00 Seo Sanghyeon sanxiyn@gmail.com 2015-10-13T06:11:59+00:00 urn:sha1:22dc40821770db567915250af3f8c2fdb0c1ab81 2015-10-08T18:49:31+00:00 Cristi Cobzarenco cristi.cobzarenco@gmail.com 2015-10-07T22:11:25+00:00 urn:sha1:4b308b44e1d8204702f6912dda4dfc404aa2a87d 2015-07-17T03:25:52+00:00 Alex Crichton alex@alexcrichton.com 2015-07-16T22:48:16+00:00 urn:sha1:958d5638254958ea42652de7444b63f2e67e7fe3 Turns out for OSX our data layout was subtly wrong and the LLVM update must have exposed this. Instead of fixing this I've removed all data layouts from the compiler to just use the defaults that LLVM provides for all targets. All data layouts (and a number of dead modules) are removed from the compiler here. Custom target specifications can still provide a custom data layout, but it is now an optional key as the default will be used if one isn't specified. 2015-06-17T05:56:42+00:00 Alex Crichton alex@alexcrichton.com 2015-05-14T19:10:43+00:00 urn:sha1:f9d4149c29e8b989fa3624993be379f380e48dcf This commit updates the LLVM submodule in use to the current HEAD of the LLVM repository. This is primarily being done to start picking up unwinding support for MSVC, which is currently unimplemented in the revision of LLVM we are using. Along the way a few changes had to be made: * As usual, lots of C++ debuginfo bindings in LLVM changed, so there were some significant changes to our RustWrapper.cpp * As usual, some pass management changed in LLVM, so clang was re-scrutinized to ensure that we're doing the same thing as clang. * Some optimization options are now passed directly into the `PassManagerBuilder` instead of through CLI switches to LLVM. * The `NoFramePointerElim` option was removed from LLVM, favoring instead the `no-frame-pointer-elim` function attribute instead. Additionally, LLVM has picked up some new optimizations which required fixing an existing soundness hole in the IR we generate. It appears that the current LLVM we use does not expose this hole. When an enum is moved, the previous slot in memory is overwritten with a bit pattern corresponding to "dropped". When the drop glue for this slot is run, however, the switch on the discriminant can often start executing the `unreachable` block of the switch due to the discriminant now being outside the normal range. This was patched over locally for now by having the `unreachable` block just change to a `ret void`. 2015-04-21T14:20:48+00:00 Tamir Duberstein tamird@gmail.com 2015-04-20T17:19:02+00:00 urn:sha1:ba276adab596bafe48a27dc02dcc5867446a52b5 2015-03-10T00:56:51+00:00 Julian Orth ju.orth@gmail.com 2015-03-10T00:46:45+00:00 urn:sha1:660b48fae5f54c4a4994b8c23550f580927775ab 2014-10-12T13:18:14+00:00 Daniel Micay danielmicay@gmail.com 2014-08-09T16:43:45+00:00 urn:sha1:4deb4bcba590e707e23670d8b40bc5520c5ab7fe Position independent code has fewer requirements in executables, so pass the appropriate flag to LLVM in order to allow more optimization. At the moment this means faster thread-local storage.