New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LLVM upgrade #34743

Merged
merged 33 commits into from Aug 1, 2016

Conversation

Projects
None yet
@badboy
Member

badboy commented Jul 9, 2016

As discussed in https://internals.rust-lang.org/t/need-help-with-emscripten-port/3154/46 I'm trying to update the used LLVM checkout in Rust.

I basically took @shepmaster's code and applied it on top (though I did the commits manually, the original commits have better descriptions.

With these changes I was able to build rustc. make check throws one last error on run-pass/issue-28950.rs. Output: https://gist.github.com/badboy/bcdd3bbde260860b6159aa49070a9052

I took the metadata changes as is and they seem to work, though it now uses the module in another step. I'm not sure if this is the best and correct way.

Things to do:

  • Make run-pass/issue-28950.rs pass unrelated
  • Find out how the PositionIndependentExecutable setting is now used
  • Is the llvm::legacy still the right way to do these things?

cc @brson @alexcrichton

@rust-highfive

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Jul 9, 2016

Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @pnkfelix (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

Collaborator

rust-highfive commented Jul 9, 2016

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @pnkfelix (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@badboy

This comment has been minimized.

Show comment
Hide comment
@badboy

badboy Jul 9, 2016

Member

Ah, forgot to mention that I am using a LLVM checkout of http://llvm.org/git/llvm.git

Member

badboy commented Jul 9, 2016

Ah, forgot to mention that I am using a LLVM checkout of http://llvm.org/git/llvm.git

@@ -267,7 +267,7 @@ LLVMRustAddLibraryInfo(LLVMPassManagerRef PMB,
// similar code in clang's BackendUtil.cpp file.
extern "C" void
LLVMRustRunFunctionPassManager(LLVMPassManagerRef PM, LLVMModuleRef M) {
FunctionPassManager *P = unwrap<FunctionPassManager>(PM);
llvm::legacy::FunctionPassManager *P = unwrap<llvm::legacy::FunctionPassManager>(PM);

This comment has been minimized.

@frewsxcv

frewsxcv Jul 9, 2016

Member

llvm::legacy::FunctionPassManager

Tangential comment to this pull request: Does anyone know what this got replaced with since it's presumably legacy now?

@frewsxcv

frewsxcv Jul 9, 2016

Member

llvm::legacy::FunctionPassManager

Tangential comment to this pull request: Does anyone know what this got replaced with since it's presumably legacy now?

This comment has been minimized.

@eefriedman

eefriedman Jul 9, 2016

Contributor

LLVM pass manager infrastructure is currently getting rewritten to be more flexible. See https://github.com/llvm-mirror/llvm/blob/d1aa4ea020d932ffc6a3c3e4d1bbab659391c725/tools/opt/NewPMDriver.cpp#L50 for a usage example for the new API. That said, the rewrite isn't complete yet.

@eefriedman

eefriedman Jul 9, 2016

Contributor

LLVM pass manager infrastructure is currently getting rewritten to be more flexible. See https://github.com/llvm-mirror/llvm/blob/d1aa4ea020d932ffc6a3c3e4d1bbab659391c725/tools/opt/NewPMDriver.cpp#L50 for a usage example for the new API. That said, the rewrite isn't complete yet.

This comment has been minimized.

@alexcrichton

alexcrichton Jul 10, 2016

Member

Looks like clang is also still using this, so we probably don't need to update just yet until they do at least.

@alexcrichton

alexcrichton Jul 10, 2016

Member

Looks like clang is also still using this, so we probably don't need to update just yet until they do at least.

@shepmaster

This comment has been minimized.

Show comment
Hide comment
@shepmaster

shepmaster Jul 9, 2016

Member

I'm no core contributor, but I don't see the value in commit X introducing less-than-great variable names and then commit X+1 improving them. I'd just squash those two together.

Member

shepmaster commented Jul 9, 2016

I'm no core contributor, but I don't see the value in commit X introducing less-than-great variable names and then commit X+1 improving them. I'd just squash those two together.

@badboy

This comment has been minimized.

Show comment
Hide comment
@badboy

badboy Jul 9, 2016

Member

@shepmaster yes, I should have squashed them beforehand. I can still do this.

Member

badboy commented Jul 9, 2016

@shepmaster yes, I should have squashed them beforehand. I can still do this.

return false;
};
passes.add(llvm::createInternalizePass(PreserveFunctions));

This comment has been minimized.

@alexcrichton

alexcrichton Jul 10, 2016

Member

Can you wrap this in a #if to only execute this new part on LLVM version >= 9 and keep the old code around for 8 and below? That should help us keep compiling against older versions of LLVM.

Come to think of that, can you also ensure that the llvm::legacy:: above compiles on LLVM 3.7 and 3.8?

@alexcrichton

alexcrichton Jul 10, 2016

Member

Can you wrap this in a #if to only execute this new part on LLVM version >= 9 and keep the old code around for 8 and below? That should help us keep compiling against older versions of LLVM.

Come to think of that, can you also ensure that the llvm::legacy:: above compiles on LLVM 3.7 and 3.8?

Show outdated Hide outdated src/llvm
@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jul 10, 2016

Member

A failure on issue-28950 looks like it may be specific to your system or something like that, I doubt that the LLVM changes would cause it to fail. Are you sure that it succeeds before this PR on your local computer?

Member

alexcrichton commented Jul 10, 2016

A failure on issue-28950 looks like it may be specific to your system or something like that, I doubt that the LLVM changes would cause it to fail. Are you sure that it succeeds before this PR on your local computer?

@badboy

This comment has been minimized.

Show comment
Hide comment
@badboy

badboy Jul 10, 2016

Member

@alexcrichton Indeed, with a fresh checkout of rust-lang/rust I see the same error on issue-28950

Member

badboy commented Jul 10, 2016

@alexcrichton Indeed, with a fresh checkout of rust-lang/rust I see the same error on issue-28950

@alexbool

This comment has been minimized.

Show comment
Hide comment
@alexbool

alexbool Jul 11, 2016

Contributor

This is supposed to fix #34119 ?

Contributor

alexbool commented Jul 11, 2016

This is supposed to fix #34119 ?

@badboy

This comment has been minimized.

Show comment
Hide comment
@badboy

badboy Jul 11, 2016

Member

@alexbool If it is fixed by something in LLVM upstream, then yes

Member

badboy commented Jul 11, 2016

@alexbool If it is fixed by something in LLVM upstream, then yes

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jul 11, 2016

Contributor

cc @kripken Here's Rust's LLVM upgrade.

Contributor

brson commented Jul 11, 2016

cc @kripken Here's Rust's LLVM upgrade.

@kripken

This comment has been minimized.

Show comment
Hide comment
@kripken

kripken Jul 11, 2016

@brson: cool, emscripten's merges of that same LLVM commit are in https://github.com/kripken/emscripten-fastcomp/tree/next-merge and https://github.com/kripken/emscripten-fastcomp-clang/tree/next-merge .

The tracking issue is kripken/emscripten#4430. Looks like only some SIMD issues block it, which probably wouldn't be a problem for rust, so it could be usable for testing already.

kripken commented Jul 11, 2016

@brson: cool, emscripten's merges of that same LLVM commit are in https://github.com/kripken/emscripten-fastcomp/tree/next-merge and https://github.com/kripken/emscripten-fastcomp-clang/tree/next-merge .

The tracking issue is kripken/emscripten#4430. Looks like only some SIMD issues block it, which probably wouldn't be a problem for rust, so it could be usable for testing already.

@shepmaster

This comment has been minimized.

Show comment
Hide comment
@shepmaster

shepmaster Jul 11, 2016

Member

I'd strongly encourage having links to the original LLVM issues / commits that are forcing these changes. These links should be in the commit message that modifies the relevant aspect of the code. That should make it much easier for people in the future to track down the why.

Member

shepmaster commented Jul 11, 2016

I'd strongly encourage having links to the original LLVM issues / commits that are forcing these changes. These links should be in the commit message that modifies the relevant aspect of the code. That should make it much easier for people in the future to track down the why.

@shepmaster

This comment has been minimized.

Show comment
Hide comment
@shepmaster

shepmaster Jul 11, 2016

Member

That should make it much easier for people in the future to track down the why.

I say this having been one of those people to track down such information in the past.

Member

shepmaster commented Jul 11, 2016

That should make it much easier for people in the future to track down the why.

I say this having been one of those people to track down such information in the past.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jul 11, 2016

Member

@shepmaster to clarify, you mean the changes to LLVM bindings and why they're changing? (e.g. this)

Member

alexcrichton commented Jul 11, 2016

@shepmaster to clarify, you mean the changes to LLVM bindings and why they're changing? (e.g. this)

@shepmaster

This comment has been minimized.

Show comment
Hide comment
@shepmaster

shepmaster Jul 11, 2016

Member

you mean the changes to LLVM bindings and why they're changing

Yeah; sorry to be unclear. Having the commit message be something like

[LLVM 3.9] Configure PIE at the module level instead of compilation unit level

This was deleted here[linky] which appears to be replaced by this[linky] which is a new setPIELevel function on the LLVM module itself.

would make that commit 💯 in my book. Otherwise the commit is like "moving some functions around!"

Again, I stress that I hold no power to enforce these suggestions; I just would have found commits like this to be useful when I was digging into the existing code to make these kind of changes. 🌴

Member

shepmaster commented Jul 11, 2016

you mean the changes to LLVM bindings and why they're changing

Yeah; sorry to be unclear. Having the commit message be something like

[LLVM 3.9] Configure PIE at the module level instead of compilation unit level

This was deleted here[linky] which appears to be replaced by this[linky] which is a new setPIELevel function on the LLVM module itself.

would make that commit 💯 in my book. Otherwise the commit is like "moving some functions around!"

Again, I stress that I hold no power to enforce these suggestions; I just would have found commits like this to be useful when I was digging into the existing code to make these kind of changes. 🌴

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jul 12, 2016

Member

Sounds like a good plan to me!

Member

alexcrichton commented Jul 12, 2016

Sounds like a good plan to me!

@badboy

This comment has been minimized.

Show comment
Hide comment
@badboy

badboy Jul 12, 2016

Member

I will rebase the commits and change accordingly (force-push incoming!)

@shepmaster Thanks for mentioning this, it's indeed a good idea, especially in the long run

Member

badboy commented Jul 12, 2016

I will rebase the commits and change accordingly (force-push incoming!)

@shepmaster Thanks for mentioning this, it's indeed a good idea, especially in the long run

@solson

This comment has been minimized.

Show comment
Hide comment
@solson

solson Jul 13, 2016

Member

@alexcrichton @eddyb Can this PR also be placed under the "Launch MIR into Orbit" milestone, since it's blocking #34119?

Member

solson commented Jul 13, 2016

@alexcrichton @eddyb Can this PR also be placed under the "Launch MIR into Orbit" milestone, since it's blocking #34119?

@alexcrichton alexcrichton added this to the Launch MIR into Orbit milestone Jul 13, 2016

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton
Member

alexcrichton commented Jul 13, 2016

@solson sure!

@badboy

This comment has been minimized.

Show comment
Hide comment
@badboy

badboy Jul 14, 2016

Member

I just force-pushed with the new commits

  • Reorganized all commits into logical blocks, including proper descriptions and links
  • I had to upgrade compiler-rt as well to get it to compile, this is not yet reflected here
  • I had to re-enable the std::thread thing in LLVM to get it to compile at least once. We probably need to find a proper workaround first.
  • When choosing anything other than Default in ffc5a8608f1418f6a52f754232ba5edb90427370 I get the following error on compile:
error: linking with `cc` failed: exit code: 1
note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/jer/src/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/jer/src/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/debug/deps/std-b8d6c224bdd7e5ff.0.o" "/home/jer/src/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/debug/deps/std-b8d6c224bdd7e5ff.1.o" "/home/jer/src/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/debug/deps/std-b8d6c224bdd7e5ff.2.o" "/home/jer/src/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/debug/deps/std-b8d6c224bdd7e5ff.3.o" "-o" "/home/jer/src/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/debug/deps/libstd-b8d6c224bdd7e5ff.so" "/home/jer/src/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/debug/deps/std-b8d6c224bdd7e5ff.metadata.o" "-nodefaultlibs" "-L" "/home/jer/src/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/debug/deps" "-L" "/home/jer/src/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/debug/deps" "-L" "/home/jer/src/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/debug/build/std-26167b16044fc6c3/out/.libs" "-L" "/home/jer/src/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/debug/build/alloc_jemalloc-0986af1f8480d6ae/out/lib" "-L" "/home/jer/src/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "-Wl,--whole-archive" "-l" "backtrace" "-Wl,--no-whole-archive" "-Wl,-Bdynamic" "-l" "dl" "-l" "rt" "-l" "pthread" "-Wl,--whole-archive" "/tmp/rustc.FqfLoqjnVH7z/libcollections-af9a9d510058b25a.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustc.FqfLoqjnVH7z/libpanic_unwind-17c382f05cff5951.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustc.FqfLoqjnVH7z/liballoc-3e8adf33e113f98f.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustc.FqfLoqjnVH7z/liballoc_jemalloc-565df9f061d73123.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustc.FqfLoqjnVH7z/librustc_unicode-f4dd78d2f1b9c500.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustc.FqfLoqjnVH7z/libunwind-f70560ece060458e.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustc.FqfLoqjnVH7z/liblibc-b8c0e2a7b980b655.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustc.FqfLoqjnVH7z/librand-f0667cf9d06dbb0e.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustc.FqfLoqjnVH7z/libcore-d7d9994298ae504c.rlib" "-Wl,--no-whole-archive" "-l" "pthread" "-l" "gcc_s" "-l" "c" "-l" "m" "-l" "rt" "-l" "util" "-shared" "-Wl,-rpath,$ORIGIN/../lib" "-l" "compiler-rt"
note: /usr/bin/ld: /home/jer/src/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/debug/deps/std-b8d6c224bdd7e5ff.0.o: relocation R_X86_64_TPOFF32 against `_ZN3std11collections4hash3map11RandomState3new4KEYS7__getit5__KEY17hc8a582c36b9a9c3eE' can not be used when making a shared object; recompile with -fPIC
/home/jer/src/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/debug/deps/std-b8d6c224bdd7e5ff.0.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status

error: aborting due to previous error
error: Could not compile `std`.

It seems something is not compiled correctly with -fPIC, but I'm not sure what to do here.

Member

badboy commented Jul 14, 2016

I just force-pushed with the new commits

  • Reorganized all commits into logical blocks, including proper descriptions and links
  • I had to upgrade compiler-rt as well to get it to compile, this is not yet reflected here
  • I had to re-enable the std::thread thing in LLVM to get it to compile at least once. We probably need to find a proper workaround first.
  • When choosing anything other than Default in ffc5a8608f1418f6a52f754232ba5edb90427370 I get the following error on compile:
error: linking with `cc` failed: exit code: 1
note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/jer/src/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/jer/src/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/debug/deps/std-b8d6c224bdd7e5ff.0.o" "/home/jer/src/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/debug/deps/std-b8d6c224bdd7e5ff.1.o" "/home/jer/src/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/debug/deps/std-b8d6c224bdd7e5ff.2.o" "/home/jer/src/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/debug/deps/std-b8d6c224bdd7e5ff.3.o" "-o" "/home/jer/src/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/debug/deps/libstd-b8d6c224bdd7e5ff.so" "/home/jer/src/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/debug/deps/std-b8d6c224bdd7e5ff.metadata.o" "-nodefaultlibs" "-L" "/home/jer/src/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/debug/deps" "-L" "/home/jer/src/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/debug/deps" "-L" "/home/jer/src/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/debug/build/std-26167b16044fc6c3/out/.libs" "-L" "/home/jer/src/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/debug/build/alloc_jemalloc-0986af1f8480d6ae/out/lib" "-L" "/home/jer/src/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "-Wl,--whole-archive" "-l" "backtrace" "-Wl,--no-whole-archive" "-Wl,-Bdynamic" "-l" "dl" "-l" "rt" "-l" "pthread" "-Wl,--whole-archive" "/tmp/rustc.FqfLoqjnVH7z/libcollections-af9a9d510058b25a.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustc.FqfLoqjnVH7z/libpanic_unwind-17c382f05cff5951.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustc.FqfLoqjnVH7z/liballoc-3e8adf33e113f98f.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustc.FqfLoqjnVH7z/liballoc_jemalloc-565df9f061d73123.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustc.FqfLoqjnVH7z/librustc_unicode-f4dd78d2f1b9c500.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustc.FqfLoqjnVH7z/libunwind-f70560ece060458e.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustc.FqfLoqjnVH7z/liblibc-b8c0e2a7b980b655.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustc.FqfLoqjnVH7z/librand-f0667cf9d06dbb0e.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustc.FqfLoqjnVH7z/libcore-d7d9994298ae504c.rlib" "-Wl,--no-whole-archive" "-l" "pthread" "-l" "gcc_s" "-l" "c" "-l" "m" "-l" "rt" "-l" "util" "-shared" "-Wl,-rpath,$ORIGIN/../lib" "-l" "compiler-rt"
note: /usr/bin/ld: /home/jer/src/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/debug/deps/std-b8d6c224bdd7e5ff.0.o: relocation R_X86_64_TPOFF32 against `_ZN3std11collections4hash3map11RandomState3new4KEYS7__getit5__KEY17hc8a582c36b9a9c3eE' can not be used when making a shared object; recompile with -fPIC
/home/jer/src/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/debug/deps/std-b8d6c224bdd7e5ff.0.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status

error: aborting due to previous error
error: Could not compile `std`.

It seems something is not compiled correctly with -fPIC, but I'm not sure what to do here.

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jul 14, 2016

Contributor

Thanks @badboy. This is a great looking branch.

Contributor

brson commented Jul 14, 2016

Thanks @badboy. This is a great looking branch.

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Jul 31, 2016

Member

@tmiasko That's interesting. Do you have a backtrace? We couldn't get anything, reproduction seemed to need the concurrent builds, or a specific builder, to trigger.

Member

eddyb commented Jul 31, 2016

@tmiasko That's interesting. Do you have a backtrace? We couldn't get anything, reproduction seemed to need the concurrent builds, or a specific builder, to trigger.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Aug 1, 2016

Member

@tmiasko did some digging and discovered that https://reviews.llvm.org/D22858 may be relevant (stack trace gathered). I've updated our LLVM submodule with this commit (rebased on the llvm/release_39 branch) and now it's rust-lang/llvm@d1cc489. @badboy wanna try updating to that and give it a go? Builds in dev are running, but we can do in parallel hopefully :)

Member

alexcrichton commented Aug 1, 2016

@tmiasko did some digging and discovered that https://reviews.llvm.org/D22858 may be relevant (stack trace gathered). I've updated our LLVM submodule with this commit (rebased on the llvm/release_39 branch) and now it's rust-lang/llvm@d1cc489. @badboy wanna try updating to that and give it a go? Builds in dev are running, but we can do in parallel hopefully :)

Upgrade LLVM once more to get a bugfix
@tmiasko did some digging and discovered that
https://reviews.llvm.org/D22858 may be relevant.
@badboy

This comment has been minimized.

Show comment
Hide comment
@badboy

badboy Aug 1, 2016

Member

Done! Upgraded to d1cc489

Member

badboy commented Aug 1, 2016

Done! Upgraded to d1cc489

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Aug 1, 2016

Member

@bors r+

Member

eddyb commented Aug 1, 2016

@bors r+

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Aug 1, 2016

Contributor

📌 Commit 5d1d247 has been approved by eddyb

Contributor

bors commented Aug 1, 2016

📌 Commit 5d1d247 has been approved by eddyb

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Aug 1, 2016

Contributor

⌛️ Testing commit 5d1d247 with merge 2c1612c...

Contributor

bors commented Aug 1, 2016

⌛️ Testing commit 5d1d247 with merge 2c1612c...

bors added a commit that referenced this pull request Aug 1, 2016

Auto merge of #34743 - badboy:llvm-upgrade, r=eddyb
LLVM upgrade

As discussed in https://internals.rust-lang.org/t/need-help-with-emscripten-port/3154/46 I'm trying to update the used LLVM checkout in Rust.

I basically took @shepmaster's code and applied it on top (though I did the commits manually, the [original commits have better descriptions](master...avr-rust:avr-support).

With these changes I was able to build rustc. `make check` throws one last error on `run-pass/issue-28950.rs`. Output: https://gist.github.com/badboy/bcdd3bbde260860b6159aa49070a9052

I took the metadata changes as is and they seem to work, though it now uses the module in another step. I'm not sure if this is the best and correct way.

Things to do:

* [x] ~~Make `run-pass/issue-28950.rs` pass~~ unrelated
* [x] Find out how the `PositionIndependentExecutable` setting is now used
* [x] Is the `llvm::legacy` still the right way to do these things?

cc @brson @alexcrichton

@bors bors merged commit 5d1d247 into rust-lang:master Aug 1, 2016

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details
@badboy

This comment has been minimized.

Show comment
Hide comment
@badboy

badboy Aug 1, 2016

Member

Wuhu! 🎉

Member

badboy commented Aug 1, 2016

Wuhu! 🎉

@eminence

This comment has been minimized.

Show comment
Hide comment
@eminence

eminence Aug 1, 2016

Contributor

Outstanding work everyone!

Contributor

eminence commented Aug 1, 2016

Outstanding work everyone!

@michaelwoerister

This comment has been minimized.

Show comment
Hide comment
@michaelwoerister

michaelwoerister Aug 1, 2016

Contributor

Epic! :)

Contributor

michaelwoerister commented Aug 1, 2016

Epic! :)

@shepmaster

This comment has been minimized.

Show comment
Hide comment
@shepmaster

shepmaster Aug 1, 2016

Member

Hurrah! Now it's time to rebase the AVR and Emscripten forks and really give it a workout ;-)

Member

shepmaster commented Aug 1, 2016

Hurrah! Now it's time to rebase the AVR and Emscripten forks and really give it a workout ;-)

@badboy

This comment has been minimized.

Show comment
Hide comment
@badboy

badboy Aug 1, 2016

Member

@shepmaster: That's the next step and I'll try to work on it this week

Member

badboy commented Aug 1, 2016

@shepmaster: That's the next step and I'll try to work on it this week

@bstrie

This comment has been minimized.

Show comment
Hide comment
@bstrie

bstrie Aug 1, 2016

Contributor

Heroes, every one of you! On with MIR!

Contributor

bstrie commented Aug 1, 2016

Heroes, every one of you! On with MIR!

@whitequark

This comment has been minimized.

Show comment
Hide comment
@whitequark

whitequark Aug 13, 2016

Contributor

Looks like this missed the LLVM version check in configure, not sure why it didn't break bots:

--- .../rust/configure  Sat Aug 13 01:03:47 2016
+++ .../rust/configure  Sat Aug 13 01:03:50 2016
@@ -1013,7 +1013,7 @@
     LLVM_VERSION=$($LLVM_CONFIG --version)

     case $LLVM_VERSION in
-        (3.[7-8]*)
+        (3.[7-9]*)
             msg "found ok version of LLVM: $LLVM_VERSION"
             ;;
         (*)
Contributor

whitequark commented Aug 13, 2016

Looks like this missed the LLVM version check in configure, not sure why it didn't break bots:

--- .../rust/configure  Sat Aug 13 01:03:47 2016
+++ .../rust/configure  Sat Aug 13 01:03:50 2016
@@ -1013,7 +1013,7 @@
     LLVM_VERSION=$($LLVM_CONFIG --version)

     case $LLVM_VERSION in
-        (3.[7-8]*)
+        (3.[7-9]*)
             msg "found ok version of LLVM: $LLVM_VERSION"
             ;;
         (*)
@shepmaster

This comment has been minimized.

Show comment
Hide comment
@shepmaster

shepmaster Aug 13, 2016

Member

I have a PR out for that - #35594. No idea about the bots.

Member

shepmaster commented Aug 13, 2016

I have a PR out for that - #35594. No idea about the bots.

spladug added a commit to spladug/rust that referenced this pull request Aug 17, 2016

Update minimum CMake version in README
The minimum got bumped in the LLVM upgrade of #34743.

eddyb added a commit to eddyb/rust that referenced this pull request Aug 17, 2016

Rollup merge of #35742 - spladug:readme-cmake-version, r=nikomatsakis
Update minimum CMake version in README

The minimum got bumped in the LLVM upgrade of #34743.

eddyb added a commit to eddyb/rust that referenced this pull request Aug 18, 2016

Rollup merge of #35742 - spladug:readme-cmake-version, r=nikomatsakis
Update minimum CMake version in README

The minimum got bumped in the LLVM upgrade of #34743.

pmatos pushed a commit to LinkiTools/rust that referenced this pull request Sep 27, 2016

mk: Don't pass -msoft-float on mips-gnu
Soon the LLVM upgrade (#34743) will require an updated CMake installation, and
the easiest way to do this was to upgrade the Ubuntu version of the bots to
16.04. This in turn brings in a new MIPS compiler on the linux-cross builder,
which is now from the "official" ubuntu repositories. Unfortunately these
new compilers don't support compiling with the `-msoft-float` flag like we're
currently passing, causing compiles to fail.

This commit removes these flags as it's not clear *why* they're being passed, as
the mipsel targets also don't have it. At least if it's not supported by a
debian default compiler, perhaps it's not too relevant to support?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment