Welcome to the twelfth 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. 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.

Ceemple , an LLVM-based product for technical computing, has been released. It's marketed as offering a number of advantages over Python or MATLAB in this space.

Meeting C++ have written up a list of things likely to make their way in to C++14 .

The 'Mystical Programming blog' has an amusing article on non-terminating C++ template computations along with information on how GCC and Clang handle each example.

The LLVM backend for the HiPE Erlang compiler has been merged in to the Erlang/OTP master branch.

musl libc 1.0.0 has been released . It is an MIT-licensed libc aiming to compete with glibc. "musl is a new general-purpose implementation of the C library. It is lightweight, fast, simple, free, and aims to be correct in the sense of standards-conformance and safety."

You may recall my previous coverage of efforts by Philip Reames and others to introduce necessary changes to LLVM to support a precise relocating garbage collector. Previously he described the issues of using the llvm.gcroot intrinsic . True to his word, he's followed up that post with a description of ' late safepoint placement ', which is the approach Philip and his colleagues are working on to address the problem. More updates are promised over the next few weeks.

David Given is working on an architecture that uses integer registers to store floating point values, and asks for advice on how to represent this in tablegen without being stopped dead by "cannot infer all types in pattern" errors.

Renato Golin has kicked off another thread on unwinding and exception handling and function attributes. He's done a fantastic job of summarising the issues and proposal on moving forward which means I don't have to feel lazy by suggesting you just go read the thread if you're interested.

Arch Robinson asks the list for advice on improving the SLPVectorizer in order to help with Julia code he's looking at. The response from Arnold Schwaighofer is worth a read for anyone interested in hacking in this area.

Discussion about a binary format for instrumentation-based profiling data has continued, with the suggestion that the format written out by instrumentation need not be the same as the format read back by the compiler (it could be transformed by other tools). Justin Bogner has detailed proposed requirements for these formats.

Tim Hill started an interesting discussion by sharing his experiences from switching to Clang. Among the positives were excellent errors, the static analyzer, compatibility, and quality of generated code. The main negative is the lack of documentation for many compiler options. There's general agreement in the responses that this is a problem that should be fixed in the (hopefully not too distant) future.