[LLVMdev] LLVM Weekly - #35, Sep 1st 2014

Tue Sep 2 05:05:48 PDT 2014

> * 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.

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Alex Bradbury
Sent: den 1 september 2014 19:47
To: LLVM Developers Mailing List
Subject: [LLVMdev] 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 at 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).

* I linked last week to the mailing list thread on removing static
initializers for command line options and regrettably was unable to summarise
the extensive discussion. The bad news is discussion has continued at a rapid
pace, but thankfully Chandler Carruth has rather helpfully [sumarised the main
outcomes of the
discussion](http://article.gmane.org/gmane.comp.compilers.llvm.devel/76279).
It's also worth reading [this
thread](http://article.gmane.org/gmane.comp.compilers.llvm.devel/76382) for an
idea of what the new infrastructure might look like.

## LLVM commits

* The AArch64 backend learned about v4f16 and v8f16 operations,
[r216555](http://reviews.llvm.org/rL216555).

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

## Clang commits

* The `-fdevirtualize` and `-fdevirtualize-speculatively` flags are now
recognised (and ignored) for compatibility with GCC.
[r216477](http://reviews.llvm.org/rL216477).

* Some Google Summer of Code work has started to land. In particular, the
Clang static analyzer gained initial infrastructure to support for
synthesizing function implementations from external model files. See the
commit message for full details on the intent of this feature.
[r216550](http://reviews.llvm.org/rL216550).

* Support was added for capturing variable length arrays in C++11 lambda
expressions. [r216649](http://reviews.llvm.org/rL216649).

## Other project commits

* LLDB gained documentation on its internal register numbering scheme.
[r216372](http://reviews.llvm.org/rL216372).

* LLDB is making progress towards AArch64 support.
[r216736](http://reviews.llvm.org/rL216737).

_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev