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
<http://llvmweekly.org/issue/35>.

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
testing](http://article.gmane.org/gmane.comp.compilers.llvm.devel/76370).

Quarks Lab have published a [preview of
SCAF](
http://blog.quarkslab.com/scaf-source-code-analysis-framework-based-on-clang-pre-alpha-preview.html
),
a Source Code Analysis Framework built on Clang. It promises a release
soon.

The [VMKit project website](http://vmkit.llvm.org/) has this week been
[updated](http://reviews.llvm.org/rL216831) to mark the project as
retired.
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
of
the specification](
http://sdtimes.com/amd-announces-heterogeneous-c-amp-language-developers/
).
The C++ AMP (Accelerated Massive Parallelism) compiler is of course based
on
LLVM and Clang, and can be [found
here](https://bitbucket.org/multicoreware/cppamp-driver-ng/wiki/Home).

## On the mailing lists

* Manuel Klimek has provided a [quick run-down of the state of his work on
Clang C++ refactoring
tools](http://article.gmane.org/gmane.comp.compilers.clang.devel/38657).
He
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
is
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
and
has [asked for input on a fence elimination
algorithm](http://article.gmane.org/gmane.comp.compilers.llvm.devel/76400)
he's been thinking about. He has outlined two possible implementation
routes
he would like feedback on.

* A discussion about [improving
llvm-objdump](
http://article.gmane.org/gmane.comp.compilers.llvm.devel/76278),
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
LLVM/Clang](http://article.gmane.org/gmane.comp.compilers.llvm.devel/76341
).
Vital to having any chance of understanding this thread is to know that
gmlt
refers to debug info containing 'minimal line tables', a feature that [was
added to GCC a while
back](https://gcc.gnu.org/ml/gcc-patches/2011-04/msg02075.html).

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.