clang/LLVM

Support lifecycle for Clang/LLVM, Go, and Rust in Red Hat Enterprise Linux 8

Support lifecycle for Clang/LLVM, Go, and Rust in Red Hat Enterprise Linux 8

Red Hat Enterprise Linux (RHEL) 8.1.0 includes updates to our llvm-toolset, go-toolset, and rust-toolset application streams, which provide developers with up-to-date versions of these compiler toolchains. The upstream projects for these streams move very quickly with new feature releases every six months for LLVM and Go, and every six weeks (!) for Rust. The communities around these toolchains encourage users to users to always stay up-to-date with the latest releases, which is why we try to get new versions into Red Hat Enterprise Linux as quickly as we can.

From a support perspective, we will continue to support these application streams for the entire life of RHEL 8. We will provide new features and bug fixes within the stream by updating to newer upstream releases on a regular basis. For llvm-toolset and go-toolset, you can expect stream updates every six months, and for rust-toolset you can expect updates every three months.

Continue reading “Support lifecycle for Clang/LLVM, Go, and Rust in Red Hat Enterprise Linux 8”

Share
How to debug where a function returns using LLDB from the command line

How to debug where a function returns using LLDB from the command line

I often find myself in a situation when I want to know where a function returns. There’s no need to know the return value, as this may be the same for multiple code paths (e.g., nullptr if something went wrong). It is embarrassing, but I sometimes have put fprintf(stderr, "T1"); in my code just to follow which path the execution took. Needless to say, this behavior requires manual editing and recompilation and should be avoided if possible.

Here’s a way to elegantly debug where a function returns using lldb from the command line.

Continue reading “How to debug where a function returns using LLDB from the command line”

Share
Customize the compilation process with Clang: Making compromises

Customize the compilation process with Clang: Making compromises

In this two-part series, we’re looking at the Clang compiler and various ways of customizing the compilation process. These articles are an expanded version of the presentation, called Merci le Compilo, which was given at CPPP in June.

In part one, we looked at specific options for customization. And, in this article, we’ll look at some examples of compromises and tradeoffs involved in different approaches.

Continue reading “Customize the compilation process with Clang: Making compromises”

Share
Customize the compilation process with Clang: Optimization options

Customize the compilation process with Clang: Optimization options

When using C++, developers generally aim to keep a high level of abstraction without sacrificing performance. That’s the famous motto “costless abstractions.” Yet the C++ language actually doesn’t give a lot of guarantees to developers in terms of performance. You can have the guarantee of copy-elision or compile-time evaluation, but key optimizations like inlining, unrolling, constant propagation or, dare I say, tail call elimination are subject to the goodwill of the standard’s best friend: the compiler.

This article focuses on the Clang compiler and the various flags it offers to customize the compilation process. I’ve tried to keep this from being a boring list, and it certainly is not an exhaustive one.

Continue reading “Customize the compilation process with Clang: Optimization options”

Share
2 tips to make your C++ projects compile 3 times faster

2 tips to make your C++ projects compile 3 times faster

In this article, I will demonstrate how to speed up your compilation times by distributing compilation load using a distcc server container.  Specifically, I’ll show how to set up and use containers running a distcc server to distribute the compilation load over a heterogeneous cluster of nodes (development laptop, old desktop PC, and a Mac). To improve the speed of recompilation, I will use ccache.

Continue reading “2 tips to make your C++ projects compile 3 times faster”

Share
A look at LLVM Advanced Data Types and trivially copyable types

A look at LLVM Advanced Data Types and trivially copyable types

A few bugs have been lurking in the LLVM Bugzilla for a long time, namely #39427 and #35978, which are related to a custom implementation of the is_trivially_copyable data type, and they have a bad impact on the Application Binary Interface (ABI) of LLVM libraries. In this article, I will take a closer look at these issues and describe potential workarounds.

The LLVM compiler infrastructure relies on several Advanced Data Types (ADT) to provide different speed/size trade-offs than the containers from the Standard Template Library (STL). Additionally, this ADT library provides features from future standard versions, but implemented in the C++ version (currently C++11) that LLVM supports as a code base. Finally, these ADTs must be compatible with the compiler requirements of the LLVM code base; basically, GCC version >= 4.8 and Clang version >= 3.1. (If you are interested in LLVM ADTs, Chandler Carruth did a nice talk on the subject at CppCon 2016.)

Continue reading “A look at LLVM Advanced Data Types and trivially copyable types”

Share
Red Hat Enterprise Linux compiler toolset updates: Clang/LLVM 7.0, Go 1.11, Rust 1.31

Red Hat Enterprise Linux compiler toolset updates: Clang/LLVM 7.0, Go 1.11, Rust 1.31

We are pleased to announce the general availability of these three compiler toolsets for Red Hat Enterprise Linux 7:

  • Clang/LLVM 7.0
  • Go 1.11
  • Rust 1.31

These toolsets can be installed from the Red Hat Enterprise Linux 7 Devtools channel. See the “Compiler toolset details” section of this article to learn about the new features.

These toolsets became officially supported Red Hat offerings as of the previous release.

Continue reading “Red Hat Enterprise Linux compiler toolset updates: Clang/LLVM 7.0, Go 1.11, Rust 1.31”

Share
Introduction to using libFuzzer with llvm-toolset

Introduction to using libFuzzer with llvm-toolset

“Fuzzing” an application is a great way to find bugs that may be missed by other testing methods. Fuzzers test programs by generating random string inputs and feeding them into an application. Any program that accepts arbitrary inputs from its users is a good candidate for fuzzing. This includes compilers, interpreters, web applications, JSON or YAML parsers, and many more types of programs.

libFuzzer is a library to assist with the fuzzing of applications and libraries. It is integrated into the Clang C compiler and can be enabled for your application with the addition of a compile flag and by adding a fuzzing target to your code. libFuzzer has been used successfully to find bugs in many programs, and in this article, I will show how you can integrate libFuzzer into your own applications.

Continue reading “Introduction to using libFuzzer with llvm-toolset”

Share
How to install GCC 8 and Clang/LLVM 6 on Red Hat Enterprise Linux 7

How to install GCC 8 and Clang/LLVM 6 on Red Hat Enterprise Linux 7

There has been a lot of work to improve C/C++ compilers in recent years. A number of articles have been posted by Red Hat engineers working on the compilers themselves covering usability improvements, features to detect possible bugs, and security issues in your code.

Red Hat Enterprise Linux 8 Beta ships with GCC 8 as the default compiler. This article shows you how to install GCC 8 as well as Clang/LLVM 6 on Red Hat Enterprise Linux 7. You’ll be able to use the same updated (and supported) compilers from Red Hat on both RHEL 7 and 8.

If you want your default gcc to always be GCC 8, or you want clang to always be in your path, this article shows how to permanently enable a software collection by adding it to the profile (dot files) for your user account. A number of common questions about software collections are also answered.

Continue reading “How to install GCC 8 and Clang/LLVM 6 on Red Hat Enterprise Linux 7”

Share