LLVM Weekly - #35, Sep 1st 2014

LLVM Weekly - #35, Sep 1st 2014

LLVM Weekly - #35, Sep 1st 2014

If you prefer, you can read a HTML version of this email at

Welcome to the thirty-fifth 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@asbradbury.org>, or
@llvmweekly or @asbradbury on Twitter.

As I mentioned in a previous issue, I am involved in the
[lowRISC](http://lowrisc.org) projects to produce a fully open-source SoC.
Just a quick reminder that [we are
hiring](http://www.jobs.cam.ac.uk/job/4665/), and you have just over a
week to
get your application in.

## News and articles from around the web

LLVM/Clang 3.5 is inching ever closer to release. The fourth and hopefully
final release candidate is [available for

Quarks Lab have published a [preview of
a Source Code Analysis Framework built on Clang. It promises a release

The [VMKit project website](http://vmkit.llvm.org/) has this week been
[updated](http://reviews.llvm.org/rL216831) to mark the project as
VMKit was a project to implement virtual machines such as a JVM on top of
LLVM. People interested in restarting the project are encouraged to get in
touch with Gaël Thomas.

AMD and Microsoft have [released a C++ AMP compiler targeting version 1.2
the specification](
The C++ AMP (Accelerated Massive Parallelism) compiler is of course based
LLVM and Clang, and can be [found

## On the mailing lists

* Manuel Klimek has provided a [quick run-down of the state of his work on
Clang C++ refactoring
reports there are a number of standalone, single-use refacotring tools but
more work needs to be done on generalising and integrating them. The plan
to push more of these tools to tools-extra (where clang-rename lives), make
them integratable as a library, integrate them into libclang and then
integrate them into projects like [ycmd](https://github.com/Valloric/ycmd

* Robin Morisset has been working on optimisations for lowering of atomics
has [asked for input on a fence elimination
he's been thinking about. He has outlined two possible implementation
he would like feedback on.

* A discussion about [improving
kicked off by Steve King, makes an interesting read. I'm looking forward
to a
future with a more featureful llvm-objdump that prints symbols of branch
targets by default.

* David Blaikie has started a discussion about [supporting -gmlt in
Vital to having any chance of understanding this thread is to know that
refers to debug info containing 'minimal line tables', a feature that [was
added to GCC a while

Sorry, yeah - I might've assumed a fair bit of specific context there.
Actually Alexey already previously implemented -gmlt, but -gfission sort of
breaks users who really want to find at least backtrace-necessary data in
the original binary, rather than in side-files (dwo/dwp). To address that
I'll be moving the logic for implementing -gmlt down from the frontend
(clang) to LLVM.

In doing so, once it's in the backend, it can be more selective (rather
than simpler debug info describing /every/ function - we can just describe
the functions with inlined functions within them) & reduce even the normal
-gmlt a bit.

* The LLVM CMake build system now includes support for building with
UndefinedBehaviourSanitizer. [r216701](http://reviews.llvm.org/rL216701).

This is good news! Is there any recommended compiler/libc++ combination for trying this on Linux?

I tried with clang-3.5rc2 with libstdc++ from gcc-4.9.1 on Linux, and got the error shown below. Should I draw the conclusion that libstdc++ is not supported, and libc++ is required?

/Patrik Hägglund

ninja: Entering directory `build-all'
[2/1288] Building Opts.inc...
FAILED: cd /repo/uabpath/llvm/build-all/unittests/Option && /repo/uabpath/llvm/build-all/bin/llvm-tblgen -gen-opt-parser-defs -I /repo/uabpath/llvm/unittests/Option -I /repo/uabpath/llvm/lib/Target -I /repo/uabpath/llvm/include /repo/uabpath/llvm/unittests/Option/Opts.td -o /repo/uabpath/llvm/build-all/unittests/Option/Opts.inc.tmp
/repo/app/clang/3.5.0rc2/lib64/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../include/c++/4.9.1/bits/stl_tree.h:741:25: runtime error: downcast of address 0x7fff6be43b18 with insufficient space for an object of type '_Rb_tree_node<std::pair<const llvm::SmallVector<llvm::SmallString<2>, 2>, std::basic_string<char> > >'
0x7fff6be43b18: note: pointer points here
ff 7f 00 00 00 00 00 00 00 00 00 00 00 52 3a 01 00 00 00 00 70 51 3a 01 00 00 00 00 80 53 3a 01
[2/1288] Building Intrinsics.gen...
FAILED: cd /repo/uabpath/llvm/build-all/include/llvm/IR && /repo/uabpath/llvm/build-all/bin/llvm-tblgen -gen-intrinsic -I /repo/uabpath/llvm/include/llvm/IR -I /repo/uabpath/llvm/lib/Target -I /repo/uabpath/llvm/include /repo/uabpath/llvm/include/llvm/IR/Intrinsics.td -o /repo/uabpath/llvm/build-all/include/llvm/IR/Intrinsics.gen.tmp
/repo/app/clang/3.5.0rc2/lib64/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../include/c++/4.9.1/bits/stl_tree.h:741:25: runtime error: downcast of address 0x7fffc43e5650 with insufficient space for an object of type '_Rb_tree_node<std::pair<const char, std::vector<unsigned int, std::allocator<unsigned int> > > >'
0x7fffc43e5650: note: pointer points here
00 00 00 00 00 00 00 00 00 00 00 00 90 d3 bd 01 00 00 00 00 40 d0 bd 01 00 00 00 00 b0 fe bd 01
ninja: build stopped: cannot make progress due to previous errors.