The LLVM compiler infrastructure and the Clang C/C++ compiler front-end are being ported to the GNU/Hurd operating system.
Version 0.7 of POCL, the Portable OpenCL implementation targeting OpenCL 1.2 compliance, has been officially released.
While C++11 is an ISO standard and the Clang C/C++ compiler front-end to LLVM has been supporting C++11, developers behind the LLVM compiler infrastructure are still deciding whether to allow C++11 language features within their code-base.
Since publishing LLVM/Clang 3.2 benchmarks a few days ago that showed the Clang C/C++ compiler competing with -- and in some cases outperforming -- the GCC compiler on Intel x86_64, several Phoronix readers have been asking how things compare on the ARM side.
One of the features sadly not found in the recent release of LLVM/Clang 3.2 is OpenMP support.
While just released on Friday, FreeBSD has already pulled LLVM/Clang 3.2 into its "head" repository and will be pushing it into the FreeBSD 9/Stable series in the weeks ahead.
While the features of LLVM 3.2 and its Clang C/C++ compiler front-end have been talked about in numerous Phoronix articles over the past few months, here's an overview of the new features for this open-source compiler infrastructure update that was released on Friday.
It's a few days late, but LLVM 3.2 has been officially released.
In preparing for the imminent release of LLVM 3.2, another worthwhile feature to go over is the NVPTX back-end that's been merged for this forthcoming open-source compiler infrastructure release. The NVPTX LLVM back-end is what's used by NVIDIA's closed-source driver for its CUDA and OpenCL compiler.
The soon-to-be-released LLVM 3.2 compiler infrastructure will expand upon its coverage of processor support and CPU capabilities.
Premiering with LLVM 3.2, which will debut later this month, is an automatic loop vectorizer. I've already delivered benchmarks of LLVM's new automatic loop vectorizer, but here's more details on this new LLVM compiler feature.
The videos from last month's LLVM Developers' Meeting in San Jose, California have now been uploaded to the Internet.
An Intel developer has proposed a migration tool based upon LLVM's Clang tooling library to auto-convert C++ code to take advantage of new C++11 features in an automated manner.
While an open industry standard, the leading open-source compilers still lack support for the OpenACC parallel programming standard.
To complement the recent compiler benchmarking on the ARM Cortex-A15 as found in the Samsung Exynos 5 Dual with the Samsung Chromebook, here's some compiler tuning benchmark results from the speedy low-power ARM system.
A software research project being funded by the United States' Defense Advanced Research Projects Agency (DARPA) with its Cyber Fast Track program is looking at ways for providing a flexible and integrated security infrastructure by using LLVM for dynamic and static security tasks.
The second release candidates of LLVM 3.2 -- along with related components like Clang and DragonEgg -- are now available for testing.
While born originally at Google as projects for LLVM, AddressSanitizer and ThreadSanitizer have been ported to GCC and will be part of the forthcoming GCC 4.8 compiler release. Back at Google, they're onto developing MemorySanitizer for LLVM.
Clang UPC has been announced, which is a Unified Parallel C implementation targeting the LLVM/Clang compiler stack. Unified Parallel C is a C99 extension targeting high-performance computing on parallel machines.
The LLVM compiler infrastructure is frequently talked about on Phoronix whether it be about its Clang C/C++ compiler or one of the innovative use-cases for LLVM such as with the LLVMpipe Gallium3D driver or as a JIT engine within some free software projects like Mono. However, for those that don't understand much of the internals of LLVM, here's a brief overview.
There's just a few weeks to go until the release of LLVM 3.2, but AMD is still trying to get its "R600" GPU back-end merged into this next compiler infrastructure release.
In addition to featuring an auto-vectorizer, Polly optimizations, and countless other improvements, the forthcoming release of LLVM 3.2 brings numerous improvements to its PowerPC back-end.
Another interesting session from this month's LLVM Developers' Meeting in San Jose was about how Google manages to collect and utilize Clang diagnostics internally for software they develop at the company.
ARM's AArch64 back-end for LLVM to handle the 64-bit ARMv8 architecture is working, but there's still more work ahead of the hardware's general availability in about one year's time.
While the LLVM compiler infrastructure is primarily developed around Subversion, a poll was recently conducted that found LLVM developers overwhelmingly prefer Git over SVN for version control.
Earlier this week when writing about the state of the Tiny C Compiler, I learned more about QCC. QCC is a new initiative to pair a forked version of the Tiny C Compiler (TCC) with QEMU's code generator.
Aside from why LLVM/Clang was ported to one of the fastest super computer's in the world and using Clang to implement Microsoft's C++ AMP, another interesting session at this month's LLVM Developers' Conference in San Jose was about using Clang to analyze code comments.
Most often whenever writing about LLVM and its Clang C/C++ compiler front-end on Phoronix, within the forums is a flurry of comments from those in support of and against this modular compiler infrastructure. Some are against LLVM/Clang simply because its BSD-licensed and sponsored by Apple rather than the GPLv3-licensed GCC backed by the FSF. Others, meanwhile, see LLVM as presenting unique advantages and benefits. What reasons would a leading US national laboratory have for deploying LLVM/Clang to their leading super-computer? Here's an explanation from them.
699 Compiler news articles published on Phoronix.