activate LLVM37

[vtjnash]

this is an umbrella issue for tracking known issues with switching to LLVM35 as default. please edit this post or add a comment below. close when someone edits deps/Versions.make to 3.6.0 3.7.0

current known issues:

• requires editing deps/Versions.make - Upgrade to LLVM 3.7.1 and switch over CI #14623
• LLVM 3.5 is missing backtraces #7910 (upstream patch committed to 3.7 -- only an issue on Mac)
• figure out performance regression (perhaps only run passes once (requires writing a TargetMachine wrapper and overloading addPassesToEmitMC) (requires changes to LLVM to expose passes))
• requires leaving behind LLVM33
• would eliminate content from the "fixed in LLVM 3.5" issue label
• code_native does not work with llvm 3.5.0rc3 #8137
• Assertion failure on LLVM >= 3.5 #8999
• backtraces broken (probable LLVM-svn/LLDB problem) #9280
• __chkstk function (LLVM36) #9339 (LLVM36-only issue)
• llvm35 doesn't like generational GC #9967 (fixed in LLVM36)
• LLVM 3.6 giving incorrectly signed zeros #10377
• llvmcall test failure with LLVM 3.6.0 on Win64 #10394
• Win64 LLVM 3.6.0 segfaults in umfzl_scale during linalg/arnoldi test #11085 linalg/arnoldi test on win64
• Win32 std::bad_alloc during make testall1 #11083
• Valgrind warning on LLVM 3.6 and 3.7 #10806 (afaict, this is a non-fatal issue in valgrind. jwn)
• Invalid read on 32-bits introduced by tupocolypse #11003
• Loop vectorizer not working with LLVM 3.7? #13106 (this issue is a non-fatal performance regression. jwn)
• re-disable FPO

related:

• coverage flags are broken with LLVM 3.5 on master #7779 coverage flags are broken with LLVM 3.5 on master

@Keno

[tkelman]

Also good to note that 3.5.1 just entered rc phase: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-December/079673.html

[EDIT: Removed checklist as it was moved to the list above - @Keno]

[Keno]

We won't have backtraces on 3.5, isn't that pretty much a nogo?

[vtjnash]

ok, with my new commits, that pretty much covers tkelman's issues

[timholy]

Really cool

[tkelman]

I am still getting the numbers test failure on latest master, win64. #7728 (comment)

[vtjnash]

that might be platform dependent. also, have you done a full rebuild of the sysimg? (fwiw, the numbers test seems to just hang for me)

[tkelman]

Was on a sandy bridge, and I did make cleanall beforehand. I'm recompiling LLVM 3.5.0 from scratch now in case our compile flags have changed in some way.

[vtjnash]

they haven't (afaics), i just wanted to make sure you weren't pulling in any cached sys.dll code that might have been affected by the llvm copyprop bug

[tkelman]

I'm going to guess 04893a1 or something similar may have fixed the numbers test failure with LLVM 3.5.0, but I'm getting linalg failures now - https://gist.github.com/tkelman/8c409a7083531765027c

[vtjnash]

i messed up the alignment in ca15a28, and some other stuff too. it was probably the cause of that failure. fixed in 8cea71e

[tkelman]

I was wondering why the numbers test looked broken again, thought I was going a little nuts.