Blog Articles

Matt Newsome

Recent Posts

As always when we rebase GCC in Developer Toolset (as we announced yesterday) to a new major upstream release, there are a huge number of bugfixes, performance improvements, quality of implementation enhancements – the list goes on. In this article, however, I’d like to focus on four headline features and one new way of using the tools. Let’s dive in.

Fedora 22 will ship with GCC 5, which brings a whole host of enhancements, among which is a new default C++ ABI. In this article, we’ll cover how that ABI transition will work in Fedora.

Background – what’s an ABI, why is it changing, and what does this mean for developers?

Put simply, binary compatibility means applications that are compiled on a combination of an operating system and a particular hardware architecture will load and run similarly across different instances of the operating environment. Application binaries consist of executable files and Dynamic Shared Objects (DSOs – the formal name for shared libraries), and the level of compatibility is defined by a specific application binary interface (ABI).

The Red Hat toolchain team was well-represented at the Fall 2014 meeting of the standardization committee (JTC1/SC22/WG21) in Urbana-Champaign, IL, USA. In this article, Jason Merrill summarizes the main highlights and developments of interest to Red Hat Enterprise Linux developers. Stay tuned for separate articles summarizing the library and concurrency working group aspects.

The fall meeting of WG21 (the C++ standardization committee) this year was hosted by the CS department at the University of Illinois at Urbana-Champaign. This was the first meeting after ratification of the C++14 standard, and we weren’t changing the working paper while C++14 was out for voting ISO doesn’t allow changes to the working paper while there’s an open ballot, so there was a lot of leftover business from the last few meetings that was waiting to be voted on.

As usual, I spent the week in the Core Language Working Group. We spent the majority of the week reviewing papers for new language features.

That the “free lunch is over” may have become something of a cliche in the IT industry, but the fact is that lately, the increase in cycles per second has been mostly realized by adding more processing units rather than by other techniques. While multiprocessor mainframes and supercomputers existed essentially since the dawn of computing, this may be the first time ever that the only machines without multicore processors may be those in USB fridges and electric toothbrushes.

This changes the way that even ordinary programs need to be written. The parallelism inherent in the computation can no longer be extracted automatically from the instruction stream, but the programmer herself needs to make it explicit.

In this article, we’ll take a look at the OpenMP parallel programming extensions to C, C++ and Fortran – OpenMP 4.0. These are available out of the box in GCC v4.9.1, available to Red Hat Enterprise Linux developers via Red Hat Developer Toolset v3.0 (currently at beta release).

For a thorough backgrounder in parallelism and concurrency programming concepts, see Torvald Riegel’s earlier articles (part 1 and part 2). In this article, we’ll instead dig into the nuts and bolts of what OpenMP v4 provides to developers, and how it works in practice in GCC.

In June, Red Hat engineers Jason Merrill, Torvald Riegel and Jonathan Wakely attended the ISO C++ standards committee meeting, held in Rapperswil, Switzerland. This post contains reports on the core language work by Jason, and the library work by Jonathan. Torvald’s report out on Parallelism and Concurrency is here.

Debugging software is something akin to an art form but, regardless of the approach you prefer, having good information on what’s happening in your application is key. ltrace is one tool you may wish to add to your belt – a debugging tool that attaches to a running process, and prints to the terminal or a log file the library calls and/or system calls made by that process. In both its mode of operation and command line interface, ltrace is similar to strace. While strace only works for system calls, however, ltrace has no such restriction.

With the recent release of Red Hat Enterprise Linux 7, we have some great new features to pass along. In this post we walk through the core C, math, and thread libraries and see what is new for developers.

The GNU C Library

The GNU C Library, or “glibc” as we like to call it, is a core component of Red Hat Enterprise Linux 7 and provides several key OS components including the core ISO C functionality (including the math library), and both BSD and POSIX APIs (including the thread library). The project provides the vast majority of the low-level interfaces that developers use day in and day out with the Linux kernel. You might expect that not much would change, but actually Red Hat Enterprise Linux 7 glibc introduces a large number of changes and improvements. In this article we’ll walk through these.

Now that Red Hat Enterprise Linux 7 is publicly available, we thought RHEL application developers would be interested in seeing how the new C/C++ toolchain compares to the equivalent in Red Hat Enterprise Linux 6 in terms of raw performance. The numbers are pretty surprising so stay tuned. But first a little introduction to set the scene.

Red Hat has actively participated in the ISO group defining the C++ standard for many years, and continues to make a significant contribution. The Red Hat toolchain team was well-represented at the February 2014 meeting of the standardization committee (JTC1/SC22/WG21) in Issaquah, WA, USA. In this article, Jason Merrill summarizes the main highlights and developments of interest to Red Hat’s customers and partners: