C++

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
How C array sizes become part of the binary interface of a library

How C array sizes become part of the binary interface of a library

Most C compilers allow accessing an array declared extern, which has indeterminate bounds, like this:

extern int external_array[];

int
array_get (long int index)
{
  return external_array[index];
}

The definition of external_array could reside in a different translation unit and look like this:

int external_array[3] = { 1, 2, 3 };

The question is what happens if this separate definition is changed to this:

int external_array[4] = { 1, 2, 3, 4 };

Or this:

int external_array[2] = { 1, 2 };

Does either change preserve the binary interface (assuming that there is a mechanism that allows the application to determine the size of the array at run time)?

Curiously, the answer is that on many architectures, increasing the array size breaks binary interface (ABI) compatibility. Decreasing the array size may also cause compatibility problems. We’ll look more closely at ABI compatibility in this article and explain how to avoid problems.

Continue reading “How C array sizes become part of the binary interface of a library”

Share
Stack Clash mitigation in GCC: Why -fstack-check is not the answer

Stack Clash mitigation in GCC: Why -fstack-check is not the answer

In our previous article about Stack Clash, we covered the basics of the Stack Clash vulnerability. To summarize, an attacker first uses various means to bring the heap and stack close together. A large stack allocation is then used to “jump the stack guard.” Subsequent stores into the stack may modify objects in the heap or vice versa. This, in turn, can be used by attackers to gain control over applications.

GCC has a capability (-fstack-check), which looked promising for mitigating Stack Clash attacks. This article will cover how -fstack-check works and why it is insufficient for mitigating Stack Clash attacks.

Continue reading “Stack Clash mitigation in GCC: Why -fstack-check is not the answer”

Share
Red Hat Developer Toolset 8.1 Beta now available

Red Hat Developer Toolset 8.1 Beta now available

Red Hat Developer Toolset augments Red Hat Enterprise Linux with the latest, stable versions of GCC that install alongside the original base version. This version of Red Hat Developer Toolset 8.1 Beta includes the following new components:

  • GCC 8.2.1
  • GDB 8.2
  • binutils 2.30
  • elfutils 0.176
  • Valgrind 3.14.0

This Beta release is supported on Red Hat Enterprise Linux 6 and Red Hat Enterprise Linux 7 for AMD64 and Intel 64 architectures. It also supports the following architectures on Red Hat Enterprise Linux 7:  64-bit ARM, big- and little-endian variants of IBM POWER (), and IBM Z. See below for more information about each updated component.

Continue reading “Red Hat Developer Toolset 8.1 Beta now available”

Share
Understanding when not to std::move in C++

Understanding when not to std::move in C++

One of the most important concepts introduced in C++11 was move semantics. Move semantics is a way to avoid expensive deep copy operations and replace them with cheaper move operations. Essentially, you can think of it as turning a deep copy into a shallow copy.

Move semantics came along with several more or less related features, such as rvalue references, xvalues, forwarding  references, perfect forwarding, and so on. The standard C++ library gained a function template called std::move, which, despite its name, does not move anything. std::move merely casts its argument to an rvalue reference to allow moving it, but doesn’t guarantee a move operation. For example, we can write a more effective version of swap using std::move:

template<typename T>
void swap(T& a, T& b)
{
  T t(std::move (a));
  a = std::move (b);
  b = std::move (t);
}

This version of swap consists of one move construction and two move assignments and does not involve any deep copies. All is well. However, std::move must be used judiciously; using it blithely may lead to performance degradation, or simply be redundant, affecting readability of the code. Fortunately, the compiler can sometimes help with finding such wrong uses of std::move. In this article, I will introduce two new warnings I’ve implemented for GCC 9 that deal with incorrect usage of std::move.

Continue reading “Understanding when not to std::move in C++”

Share
Report from the February 2019 ISO C++ meeting (Core Language working group)

Report from the February 2019 ISO C++ meeting (Core Language working group)

The February 2019 ISO C++ meeting was held in Kailua-Kona, Hawaii. As usual, Red Hat sent three developers to the meeting: I attended in the Core Language working group, Jonathan Wakely in Library, and Thomas Rodgers in SG1 (parallelism and concurrency). The meeting went smoothly, although there was significant uncertainty at the beginning where we would end up. In the end, Modules and Coroutines were accepted into the C++20 draft, so now we have our work cut out for us nailing down the remaining loose corners. Here ar highlights from the meeting.

Continue reading “Report from the February 2019 ISO C++ meeting (Core Language working group)”

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
A platform interface for the GNU C Library

A platform interface for the GNU C Library

Application developers continue to need newer versions of libraries, including core runtimes like GNU C Library (glibc), for their applications. In this article, I’ll look at some issues related to upgrading glibc in an operating system (OS) distribution, and I also encourage you to read Florian Weimer’s excellent blog post on the topic.

The problem

Deciding between a library rebase or continued backporting of commits involves a complex set of risks and rewards. For some customers and users, it is important not to rebase the library (ensuring the lowest risk of impact by change); but for others, the rebase brings valuable bug fixes (lowest risk of impact from known issues). In other cases, the newer library may perform better, even if the interfaces haven’t changed, because it can take advantage of newer hardware or a newer Linux kernel (performance advantage to first mover).

There is no way to simultaneously satisfy all the requirements of slow-moving versus fast-moving development. The recent work in Fedora Modularity is aimed at solving the root of this problem, but there is a limit to this work. The further down the stack you go, the harder the problem becomes. The potential for breakage further up the stack increases. You can’t always arbitrarily change a component’s installed version without consequences, either at build time or at runtime.

Continue reading “A platform interface for the GNU C Library”

Share
What’s new in OpenMP 5.0

What’s new in OpenMP 5.0

A new version of the OpenMP standard, 5.0, was released in November 2018 and brings several new constructs to the users. OpenMP is an API consisting of compiler directives and library routines for high-level parallelism in C, C++, and Fortran programs. The upcoming version of GCC adds support for some parts of this newest version of the standard.

This article highlights some of the latest features, changes, and “gotchas” to look for in the OpenMP standard.

Continue reading “What’s new in OpenMP 5.0”

Share
A gentle introduction to jump threading optimizations

A gentle introduction to jump threading optimizations

As part of the GCC developers‘ on-demand range work for GCC 10, I’ve been playing with improving the backward jump threader so it can thread paths that are range-dependent. This, in turn, had me looking at the jump threader, which is a part of the compiler I’ve been carefully avoiding for years. If, like me, you’re curious about compiler optimizations, but are jump-threading-agnostic, perhaps you’ll be interested in this short introduction.

Continue reading “A gentle introduction to jump threading optimizations”

Share