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).
On Mon, Sep 1, 2014 at 10:46 AM, Alex Bradbury <asb at asbradbury.org> wrote:> 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). >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.> > * 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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140901/38961be2/attachment.html>
> * 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