compilers

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
Understanding GCC warnings, Part 2

Understanding GCC warnings, Part 2

In part 1, I shed light on trade-offs involved in the GCC implementation choices for various types of front-end warnings, such as preprocessor warnings, lexical warnings, type-safety warnings, and other warnings.

As useful as front-end warnings are, those based on the flow of control or data through the program have rather inconvenient limitations. To overcome them, flow-based warnings have increasingly been implemented in what GCC calls the “middle end.” Middle-end warnings are the focus of this article.

Continue reading “Understanding GCC warnings, Part 2”

Share
Understanding GCC warnings

Understanding GCC warnings

Most of us appreciate when our compiler lets us know we made a mistake. Finding coding errors early lets us correct them before they embarrass us in a code review or, worse, turn into bugs that impact our customers. Besides the compulsory errors, many projects enable additional diagnostics by using the -Wall and -Wextra command-line options. For this reason, some projects even turn them into errors via -Werror as their first line of defense. But not every instance of a warning necessarily means the code is buggy. Conversely, the absence of warnings for a piece of code is no guarantee that there are no bugs lurking in it.

In this article, I would like to shed more light on trade-offs involved in the GCC implementation choices. Besides illuminating underlying issues for GCC contributors interested in implementing new warnings or improving existing ones, I hope it will help calibrate expectations for GCC users about what kinds of problems can be expected to be detected and with what efficacy. Having a better understanding of the challenges should also reduce the frustration the limitations of the available solutions can sometimes cause. (See part 2 to learn more about middle-end warnings.)

The article isn’t specific to any GCC version, but some command-line options it refers to are more recent than others. Most are in GCC 4 that ships with Red Hat Enterprise Linux (RHEL), but some are as recent as GCC 7. The output of the compiler shown in the examples may vary between GCC versions. See How to install GCC 8 on RHEL if you’d like to use the latest GCC.

Continue reading “Understanding GCC warnings”

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
Support Lifecycle for Clang/LLVM, Go, and Rust

Support Lifecycle for Clang/LLVM, Go, and Rust

On the heels of our recently announcement, General Availability of Clang/LLVM 6.0, Go 1.10, and Rust 1.29, I want to share how we’ll be supporting them going forward. Previously, these packages had been in “Technology Preview” status, which means that they were provided for “you to test functionality and provide feedback during the development process”, and were “not fully supported under Red Hat Subscription Level Agreements, may not be functionally complete, and are not intended for production use”.

So now that we’ve promoted them to fully supported status, what does that mean? In the simplest terms, General Availability (GA) means that these packages have officially entered the “Full Support Phase” of their lifecycle:

Continue reading “Support Lifecycle for Clang/LLVM, Go, and Rust”

Share
Clang/LLVM 6.0, Go 1.10, and Rust 1.29 now in beta for Red Hat Enterprise Linux

Clang/LLVM 6.0, Go 1.10, and Rust 1.29 now in beta for Red Hat Enterprise Linux

We are pleased to announce the immediate availability of these three compiler toolsets now in beta for Red Hat Enterprise Linux 7.  Upon the GA release, these versions will become officially supported Red Hat offerings:

  • Clang/LLVM 6.0
  • Go 1.10
  • Rust 1.29

These toolsets can be installed from the Red Hat Enterprise Linux 7 Devtools channel.  See the “New compiler details” below to learn about the new features.

Continue reading “Clang/LLVM 6.0, Go 1.10, and Rust 1.29 now in beta for Red Hat Enterprise Linux”

Share
How to install Clang/LLVM 5 and GCC 7 on RHEL

How to install Clang/LLVM 5 and GCC 7 on RHEL

A newer version of this article is available:  How to install GCC 8 and Clang/LLVM 6 on Red Hat Enterprise Linux 7.

If you are developing with C/C++, Clang tools and newer versions of GCC can be quite helpful for checking your code and giving you better warnings and error messages to help avoid bugs. The newer compilers have better optimizations and code generation.

You can easily install the latest-supported Clang and GCC compilers for C, C++, Objective-C, and FORTRAN using yum on Red Hat Enterprise Linux.  These compilers are available as software collections that are typically updated twice a year. The May 2018 update included Clang/LLVM 5 and GCC 7.3, as well as Go and Rust.

If you want your default gcc to always be GCC 7, 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 Clang/LLVM 5 and GCC 7 on RHEL”

Share
GNU Toolchain Update – Spring 2018

GNU Toolchain Update – Spring 2018

The GNU Toolchain is a collection of programming tools produced by the GNU Project. The tools are often packaged together due to their common use for developing software applications, operating systems, and low-level software for embedded systems.

This blog is part of a series (see: Fall 2017 Update) covering the latest changes and improvements in the components that make up this Toolchain. Apart from the announcement of new releases, the features described here are at the bleeding edge of software development in the tools. This means that it may be awhile before they make it into production releases, and they might not be fully functional yet. But anyone who is interested in experimenting with them can build their own copy of the Toolchain and then try them out.

Continue reading “GNU Toolchain Update – Spring 2018”

Share
Towards The Ruby 3×3 Performance Goal

Towards The Ruby 3×3 Performance Goal

This blog post is about my work to improve CRuby performance by introducing new virtual machine instructions and a JIT. It is loosely based on my presentation at RubyKaigi 2017 in Hiroshima, Japan.

As many Ruby people know, the author of Ruby, Yukihiro Matsumoto (Matz), set up a very ambitious goal for performance of CRuby version 3. Version 3 should be 3 times faster than version 2.

Koichi Sasada did a great job improving the performance of CRuby version 2 by about 3 times over version 1, by introducing a byte code virtual machine (VM). So I guess it is symbolic to set up the same goal for CRuby version 3.

Continue reading “Towards The Ruby 3×3 Performance Goal”

Share