LLVM Weekly - #47, Nov 24th 2014 =============================== If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/47>. Welcome to the forty-seventh issue of LLVM Weekly, a weekly newsletter (published every Monday) covering developments in LLVM, Clang, and related projects. LLVM Weekly is brought to you by [Alex Bradbury](http://asbradbury.org). Subscribe to future issues at <http://llvmweekly.org> and pass it on to anyone else you think may be interested. Please send any tips or feedback to <asb at asbradbury.org>, or @llvmweekly or @asbradbury on Twitter. ## News and articles from around the web Version 3.0 of the Capstone disassembly framework [has been released](http://capstone-engine.org/Version-3.0.html). Python bindings have been updated to support Python 3, and this release also adds support for Sparc, SystemZ and XCore. It also has performance improvements. Herb Sutter has penned a [trip report](https://isocpp.org/blog/2014/11/trip-report-fall) of the recent ISO C++ meeting. Emscripten has [updated to use LLVM 3.4 from the PNaCl team](https://groups.google.com/forum/#!topic/emscripten-discuss/y1_efkXYIQM). There's more work to be done to rebase on top of 3.5. Woboq has written a blog post [detailing C++14 features of interest to Qt programmers](http://woboq.com/blog/cpp14-in-qt.html), though I suspect the article has a wider potential audience than that. Recent Clang of course has [good support](http://clang.llvm.org/cxx_status.html#cxx14) for the new C++14 features. There is going to be an LLVM Devroom at FOSDEM 2015, and the [submission deadline for presentations/talks/tutorials is on Dec 1st](http://article.gmane.org/gmane.comp.debugging.lldb.devel/5757). Apple's LLVM Source Tools and Program Analysis teams are [looking for interns for Summer 2015](http://article.gmane.org/gmane.comp.compilers.clang.devel/39769). ## On the mailing lists * If you're wondering how the process of adding OpenMP support to Clang is going, the [answer](http://article.gmane.org/gmane.comp.compilers.clang.devel/39749) is that it's still ongoing and there's hope it will be done by the 3.6 release, depending on the speed of code reviews. * Siva Chandra kicked off a discussion on the mailing list about [how to better manage breakages caused by LLVM or Clang API changes](http://article.gmane.org/gmane.comp.debugging.lldb.devel/5765). Siva suggests LLDB should be developed against a known-good version of LLVM/Clang that gets periodically bumped. Vince Harron says that he is [looking to add a continuous build on curated versions of Clang/LLVM](http://article.gmane.org/gmane.comp.debugging.lldb.devel/5780) in addition to a continuous build on top of tree for everything. This should help improve the signal to noise ratio and make it easier for LLDB developers to tell when a breaking change is due to their addition or a change elsewhere. Reid Kleckner [suggests lldb should be treated part of the same project as Clang/LLDB](http://article.gmane.org/gmane.comp.debugging.lldb.devel/5783) and more pressure should be put on developers to fix breakages, presumably in the same way that API changes in LLVM almost always come with an associated patch to fix Clang. * Peter Collingbourne has proposed [adding the llgo frontend to the LLVM project](http://article.gmane.org/gmane.comp.compilers.llvm.devel/78981). Chris Lattner is [in favour of this](http://article.gmane.org/gmane.comp.compilers.llvm.devel/78982), but would like to see the GPLv3+runtime exception dependencies rewritten before being checked in. Some people in the thread expressed concern that the existing base of LLVM/Clang reviewers know C++ and may not be able to review patches in Go, though it looks like a non-zero of existing LLVM reviewers are appropriately multilingual. * Brett Simmers is working on HHVM and [is interested if there are ways to control where a BasicBlock ends up in memory](http://article.gmane.org/gmane.comp.compilers.llvm.devel/78971), with the motivation to make best of the instruction cache by keeping frequently executed pieces of code closer together. There's general agreement this would be a great feature to have, but it doesn't sound like this is easily supported in LLVM right now. ## LLVM commits * A small doc fix has the honour of being [commit 222222](http://reviews.llvm.org/rL222222). * A nice little optimisation has been committed which replaces a switch table with a mul and add if there is a linear mapping between index and output. [r222121](http://reviews.llvm.org/rL222121). * The SeparateConstOffsetFromGEP, EarlyCSE, and LICM passes have been enabled on AArch64. This has [measurable gains for some SPEC benchmarks](http://reviews.llvm.org/D5864). [r222331](http://reviews.llvm.org/rL222331). * The description of the noalias attribute has been clarified. [r222497](http://reviews.llvm.org/rL222497). * MDNode is being split into two classes, GenericMDNode and MDNodeFwdDecl. [r222205](http://reviews.llvm.org/rL222205). * The LLVM CMake-based build system learned to support `LLVM_USE_SANITIZER=Thread`. [r222258](http://reviews.llvm.org/rL222258). * The R600 backend gained the SIFoldOperands pass which attempts to fold source operands of mov and copy instructions into their uses. [r222581](http://reviews.llvm.org/rL222581). ## Clang commits * Clang now distinguishes between `-fpic` and `-fPIC`. [r222227](http://reviews.llvm.org/rL222227). * The `-Wuninitialized` warning will now trigger when accessing an uninitialized base class in a constructor. [r222503](http://reviews.llvm.org/rL222503). ## Other project commits * LLDB can now perform basic debugging operations on Windows. [r222474](http://reviews.llvm.org/rL222474). * LLDB's line editing support was been completely rewritten. [r222163](http://reviews.llvm.org/rL222163). * MemorySanitizer gained support for MIPS64. [r222388](http://reviews.llvm.org/rL222388). * A sample tool was added to lldb to extract and dump unwind information from Darwin's compact unwind section. [r222127](http://reviews.llvm.org/rL222127).