Programming Languages

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
RPM packaging: A simplified guide to creating your first RPM

RPM packaging: A simplified guide to creating your first RPM

The concept of RPM packaging can be overwhelming for first-timers because of the impression a steep learning curve is involved. In this article, I will demonstrate that building an RPM with minimal knowledge and experience is possible. Note that this article is meant as a starting point, not a complete guide to RPM packaging.

Continue reading “RPM packaging: A simplified guide to creating your first RPM”

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
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
Changes made to the Libabigail ABI change analysis framework in 2018

Changes made to the Libabigail ABI change analysis framework in 2018

This article is for people interested in the long-term maintenance of software systems that expose application binary interfaces (a.k.a. ABIs) to other systems. That long-term maintenance involves detecting and analyzing inevitable changes in the ABIs and assessing whether these changes allow the maintained systems to stay compatible with the components with which they interact.

In this article, I describe what happened to the ABI change analysis framework that I worked on during 2018: the Abigail library (Libabigail) and its associated set of tools. The goal is not to list the myriad changes that happened throughout releases 1.2, 1.3, 1.4, and 1.5 that occurred during that year, but I will walk you through the main changes that happened and put them in perspective.

Continue reading “Changes made to the Libabigail ABI change analysis framework in 2018”

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
Node.js for Red Hat OpenShift Application Runtimes wins a Devie award

Node.js for Red Hat OpenShift Application Runtimes wins a Devie award

For the past year and a half or so, Red Hat Middleware has provided a supported Node.js runtime on OpenShift as part of Red Hat OpenShift Application Runtimes (RHOAR). Our goal has been to provide rapid releases within a week or two of the upstream Node.js core project, booster applications to get developers up and running quickly, and, of course, provide world-class service and support for customers.

This past week at the DeveloperWeek 2019 conference in San Francisco, that focus and dedication paid off as Red Hat was awarded a “Devie” award in the category of “Code Frameworks and Libraries.” I couldn’t have been more thrilled to accept the award on behalf of our team.

Continue reading “Node.js for Red Hat OpenShift Application Runtimes wins a Devie award”

Share