Alex Bradbury via llvm-dev
2016-Sep-12 10:10 UTC
[llvm-dev] LLVM Weekly - #141, Sep 12th 2016
LLVM Weekly - #141, Sep 12th 2016 ================================ If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/141>. Welcome to the one hundred and forty-first 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. As well as having the LLVM Cauldron last week, it was also an [eventful weekend](https://twitter.com/MissPhilbin/status/774985421914796033) so please accept my apologies if I've missed anything important in this issue! ## News and articles from around the web Last Thursday we successfully held the inaugural [LLVM Cauldron](http://llvm.org/devmtg/2016-09/) in Hebden Bridge. I'd like to thank all the speakers, attendees, sponsors, and helpers who made the event such a success. Simon Cook from Embecosm very kindly recorded all the talks and has managed a crazy-fast turnaround time to get them all edited and uploaded ready for you to view. See [the video playlist here](https://www.youtube.com/playlist?list=PLOGTP9W1DX5X9dNzT02d-CP-OWOR4kKpq). Simon's been so fast I haven't even collected PDFs of the slides from all the speakers yet, but you can expect to find them linked to on the [LLVM Cauldron page](http://llvm.org/devmtg/2016-09/#schedule) in the next day or two. Neil Henning has written up [part two of his series on compiling a toy language using LLVM](http://www.duskborn.com/cleaning-up-the-parser-mpc-llvm-for-the-neil-language-2/). This post explains key concepts such as LLVM Values and Types, symbol tables, and type tables. [NLVM](https://github.com/arnetheduck/nlvm), a new LLVM-based compiler for the [Nim programming language](http://nim-lang.org/) has been [announced](http://lists.llvm.org/pipermail/llvm-dev/2016-September/104527.html). Currently it passes 90% of the upstream Nim test cases. ## On the mailing lists * The events of September 4th 2016 will be passed down through the generations of LLVM developers as the day the bots got lazy (or at least, the [day we noticed](http://lists.llvm.org/pipermail/llvm-dev/2016-September/104543.html)). A configuration change to Zorg introduced a bug which made all builds rebuild from the same revision, without including the latest changes. This did cause [some hassle](http://lists.llvm.org/pipermail/llvm-dev/2016-September/104564.html) when the configuration was fixed and new failures surfaced. The good news is the CIncident is now over and life can resume as normal. * MSVC2013 has had a stay of execution, the plan is now to [retire support for it until 15th October](http://lists.llvm.org/pipermail/llvm-dev/2016-September/104683.html). * Tom Stellard is managing the upcoming 3.9.1 stable release and has requested that [requests for merges now go through bugzilla rather than the mailing list](http://lists.llvm.org/pipermail/llvm-dev/2016-September/104587.html). As he explains, this workflow makes things much easier for him to keep track of. * Ever wondered what the difference is between LLVM's libunwind and 'nongnu' libunwind? David Chisnall [has the answer](http://lists.llvm.org/pipermail/cfe-dev/2016-September/050649.html). * Daniel Cederman is a software engineer at Cobham Gaisler working on toolchain support for LEON3/LEON4 (which implement SPARC). He has shared an [RFC on adding support for REX, their new 16-bit dense instruction encoding](http://lists.llvm.org/pipermail/llvm-dev/2016-September/104579.html). These shorter instructions overlap with the 32-bit encoding space, so require instructions to enter and exit REX mode. ## LLVM commits * In GlobalISel, type information is now stored in MachineRegisterInfo rather than in every MachineInstr. [r281035](http://reviews.llvm.org/rL281035). * LLVM's OCaml bindings can now be built out-of-tree. [r280642](http://reviews.llvm.org/rL280642). * The C++ Itanium demangler from libcxxabi has been imported in to LLVM. [r280732](http://reviews.llvm.org/rL280732). * A new field has been added to the Instruction TableGen class. AsmVariantName is used to indicate instructions that are only available in specific assembler variants. [r280952](http://reviews.llvm.org/rL280952). ## Clang commits * Work has started to support export declarations as specified in the C++ Modules TS. [r280999](http://reviews.llvm.org/rL280999). * A Visual Studio extension for clang-tidy has been added to the clang-tools-extra repository. For now it only supports graphically configuring clang-tidy settings. [r280840](http://reviews.llvm.org/rL280840). * The Microsoft pragma intrinsic extension (used to tell the compiler to use a builtin version of the function) is now supported, though is somewhat redundant in Clang as it will already use a builtin version of a function when possible by default. [r280825](http://reviews.llvm.org/rL280825). ## Other project commits * A new mechanism to improve crash info has landed in LLDB. Disassembly will be parsed in order to try to reconstruct the sequence of dereferences and offsets that were applied to a known variable to obtain an invalid pointer. It is exposed through a 'frame diagnose' command. [r280692](http://reviews.llvm.org/rL280692). * In a monster commit, LLDB has been completely reformatted to conform to clang-format's LLVM style. Python files have also been reformatted using autopep8. [r280751](http://reviews.llvm.org/rL280751). * Support for EfficiencySanitizer on MIPS64 has been added (with a few tests still be fixed). [r280795](http://reviews.llvm.org/rL280795). * LLDB has gained support for Intel's Memory Protection eXtensions (MPX). Specifically, it can now access the MPX registers. [r280668](http://reviews.llvm.org/rL280668). * libc++ can now be built against an external threading library other than pthreads. [r281179](http://reviews.llvm.org/rL281179).