gcc

Static analysis updates in GCC 11

Static analysis updates in GCC 11

The GNU logo.
I work at Red Hat on the GNU Compiler Collection (GCC). In GCC 10, I added the new -fanalyzer option, a static analysis pass for identifying various problems at compile-time, rather than at runtime. The initial implementation was aimed at early adopters, who found a few bugs, including a security vulnerability: CVE-2020-1967. Bernd Edlinger, who discovered the issue, had to wade through many false positives accompanying the real issue. Other users also managed to get the analyzer to crash on their code.

I’ve been rewriting the analyzer to address these issues in the next major release, GCC 11. In this article, I describe the steps I’m taking to reduce the number of false positives and make this static analysis tool more robust.

Continue reading “Static analysis updates in GCC 11”

Share
Building Red Hat Enterprise Linux 9 for the x86-64-v2 microarchitecture level

Building Red Hat Enterprise Linux 9 for the x86-64-v2 microarchitecture level

One of the most important early decisions when building a Linux distribution is the scope of supported hardware. The distribution’s default compiler flags are significant for hardware-platform compatibility. Programs that use newer CPU instructions might not run on older CPUs. In this article, I discuss a new approach to building the x86-64 variant of Red Hat Enterprise Linux (RHEL) 9 and share Red Hat’s recommendation for that build.

Continue reading Building Red Hat Enterprise Linux 9 for the x86-64-v2 microarchitecture level

Share
The joys and perils of aliasing in C and C++, Part 2

The joys and perils of aliasing in C and C++, Part 2

In the previous article, I discussed the benefits of C and C++ language restrictions in optimized code. In this second half, I present a variety of programming language exemptions and compiler extensions that developers can use to get around aliasing restrictions more or less safely. I will also discuss the common pitfalls of aliasing, both resulting from the extensions as well as from misuses of standard language constructs, and illustrate common problems these pitfalls might cause.

Continue reading “The joys and perils of aliasing in C and C++, Part 2”

Share
The joys and perils of C and C++ aliasing, Part 1

The joys and perils of C and C++ aliasing, Part 1

In C, C++, and some other programming languages, the term aliasing refers to a situation where two different expressions or symbols refer to the same object. When references access that object in different ways—as both reads and stores—there are consequences for the order in which these mixed accesses can happen. The value that is stored first is expected to be read by the subsequent access. In many instances, aliasing is harmless: It is common, safe, and usually optimally efficient to use two pointers of the same type to read, and even to write to the same object. But in some cases, using aliasing symbols for mixed accesses is less benign, and can adversely affect the correctness or efficiency of your code.

Although there are quite a few articles on this subject, most tend to focus on the rules and requirements outlined in the standards (such as the strict aliasing rule). In this article, I focus on the details of the C and C++ language restrictions, their challenges and pitfalls, and examples demonstrating the restrictions’ beneficial effects in optimized code. In Part 2, I will present exemptions from aliasing, which can help you get around the restrictions more or less safely. I also consider some of the common pitfalls of aliasing and mixed accesses, and the actual problems these pitfalls might cause.

Continue reading “The joys and perils of C and C++ aliasing, Part 1”

Share
Stack clash mitigation in GCC, Part 3

Stack clash mitigation in GCC, Part 3

In previous posts, Stack Clash Mitigation in GCC — Background and Stack Clash mitigation in GCC: Why -fstack-check is not the answer, I hopefully showed the basics of how stack clash attacks are structured and why GCC’s existing -fstack-check mechanism is insufficient for protection.

So, what should we do? Clearly we want something similar to -fstack-check, but without the fundamental problems. Enter a new option: -fstack-clash-protection.

The key principles for code generation to prevent a stack clash attack are:

Continue reading “Stack clash mitigation in GCC, Part 3”

Share
Report from the February 2020 ISO C++ meeting (Core Language Working Group)

Report from the February 2020 ISO C++ meeting (Core Language Working Group)

The first International Organization for Standardization (ISO) C++ meeting of 2020 happened in Prague, Czechia. It was our first time meeting in Prague, though I’ve been there a few times for the GNU Tools Cauldron. Two of us from Red Hat attended: Jonathan Wakely serves on the ISO C++ Standards Committee Library Working Group (LWG), and I am part of the Core Language Working Group (CWG). (You can see the ISO C++ committee structure here.)

Continue reading Report from the February 2020 ISO C++ meeting (Core Language Working Group)

Share
Static analysis in GCC 10

Static analysis in GCC 10

I work at Red Hat on GCC, the GNU Compiler Collection. For the next major release of GCC, GCC 10, I’ve been implementing a new -fanalyzer option: A static analysis pass to identify various problems at compile-time, rather than at runtime.

My thinking here is that it’s best to catch problems as early as possible as the code is written, using the compiler the code is written in as part of the compile-edit-debug cycle, rather than having static analysis as an extra tool “on the side” (perhaps proprietary). Hence, it seems worthwhile to have a static analyzer built into the compiler that can see exactly the same code as the compiler sees—because it is the compiler.

Continue reading “Static analysis in GCC 10”

Share
Toward _FORTIFY_SOURCE parity between Clang and GCC

Toward _FORTIFY_SOURCE parity between Clang and GCC

GCC combined with glibc can detect instances of buffer overflow by standard C library functions. When a user passes the -D_FORTIFY_SOURCE={1,2} preprocessor flag and an optimization level greater or equal to -O1, an alternate, fortified implementation of the function is used when calling, say, strcpy. Depending on the function and its inputs, this behavior may result in a compile-time error, or a runtime error triggered upon execution. (For more info on this feature, there’s an excellent blog post here on the subject).

Continue reading Toward _FORTIFY_SOURCE parity between Clang and GCC

Share
An upside-down approach to GCC optimizations

An upside-down approach to GCC optimizations

Many traditional optimizations in the compiler work from a top-down approach, which starts at the beginning of the program and works toward the bottom. This allows the optimization to see the definition of something before any uses of it, which simplifies most evaluations. It’s also the natural way we process things. In this article, we’ll look at a different approach and a new project called Ranger, which attempts to turn this problem upside down.

Continue reading “An upside-down approach to GCC optimizations”

Share
Python wheels, AI/ML, and ABI compatibility

Python wheels, AI/ML, and ABI compatibility

Python has become a popular programming language in the AI/ML world. Projects like TensorFlow and PyTorch have Python bindings as the primary interface used by data scientists to write machine learning code. However, distributing AI/ML-related Python packages and ensuring application binary interface (ABI) compatibility between various Python packages and system libraries presents a unique set of challenges.

The manylinux standard (e.g., manylinux2014) for Python wheels provides a practical solution to these challenges, but it also introduces new challenges that the Python community and developers need to consider. Before we delve into these additional challenges, we’ll briefly look at the Python ecosystem for packaging and distribution.

Continue reading “Python wheels, AI/ML, and ABI compatibility”

Share