llvm

Examples of errors that PVS-Studio found in LLVM 15.0

Compilers are evolving: they issue more and more warnings. Do developers still need to use static code analyzers like PVS-Studio? Yes, because analyzers are evolving too. In this article you'll see how PVS-Studio can find bugs even in a compiler.

Examples of errors that PVS-Studio found in LLVM 15.0

by Andrey Karpov

From the article:

It's a cool bug, although it's not scary. There is no semicolon after the return statement. As a result, the code does not work as it looks.

void FunctionLoweringInfo::ComputePHILiveOutRegInfo(const PHINode *PN) {
  ....
  Register DestReg = It->second;
  if (DestReg == 0)
    return
  assert(Register::isVirtualRegister(DestReg) &&
         "Expected a virtual reg");
  LiveOutRegInfo.grow(DestReg);
  ....
}

Detecting errors in the LLVM release 13.0.0

Commercial static analyzers perform deeper and fuller code analysis compared to compilers. Let's see what PVS-Studio found in the source code of the LLVM 13.0.0 project.

Detecting errors in the LLVM release 13.0.0

by Andrey Karpov

From the article:

It makes no sense to write different values one by one to the same variable. This is exactly what the analyzer warns us about. The code author made a typo, forgetting to add '|'. This code should create one 64-bit value from two 32-bit values. The correct code looks as follows: ....

PVS-Studio Team: Switching to Clang Improved PVS-Studio C++ Analyzer's Performance

Although the project's preparation took a while, we were satisfied that the analyzer's performance grew by over 10%. We will use Clang to build future releases of PVS-Studio for Windows.

PVS-Studio Team: Switching to Clang Improved PVS-Studio C++ Analyzer's Performance

by Alexey Govorov and Sergey Larin

From the article:

From the earliest days, we used MSVC to compile the PVS-Studio C++ analyzer for Windows - then, in 2006, known as Viva64, version 1.00. With new releases, the analyzer's C++ core learned to work on Linux and macOS, and we modified the project's structure to support CMake. However, we kept using the MSVC compiler to build the analyzer's version for Windows. Then, in 2019, on April 29th, Visual Studio developers announced they had included the LLVM utilities and Clang compiler in the IDE.

 

Checking Clang 11 with PVS-Studio

It's no secret that compilers employ their own built-in static code analyzers, and those are developing as well. That's why we write articles every now and then to show that our static analyzer, PVS-Studio, can find bugs even inside compilers and that we are worth our salt.

Checking Clang 11 with PVS-Studio

by Andrey Karpov

From the article:

The programmer is using a modulo operation to get a random value of either 0 or 1. But the value 1 seems to confuse developers and make them write the classic anti-pattern in which the modulo operation is performed on 1 instead of 2. The X % 1 operation is meaningless as it always evaluates to 0.

The surprisingly high cost of static-lifetime constructors--Arthur O’Dwyer

Today we look at compile time performance.

The surprisingly high cost of static-lifetime constructors

by Arthur O’Dwyer

From the article:

I was looking at HyperRogue again this week (see my previous post). It has a really nice localization framework: every message in the game can be translated just by adding a lookup entry to a single file (like, for the Czech translation, you add entries to language-cz.cpp); and then during the build process, all the language-??.cpp files are collated together and used to produce a single language-data.cpp file with a lookup table from each English message to the same message in every other language. (Seeing all the messages at once allows us to report on how “complete” each translation is, relative to the others.)...

 

Finding bugs in the code of LLVM project with the help of PVS-Studio

Let's take a look at the suspicious fragments in the LLVM code which PVS-Studio detected.

Finding bugs in the code of LLVM project with the help of PVS-Studio

by Andrey Karpov

From the article:

LLVM developers, of course, will be able to understand if there is a bug here or not. I have to play detective. Looking at the code, I was thinking in the following direction: The function should read the opening bracket '<', then it reads the identifiers and commas in the loop. If there is no comma, we expected a closing bracket. If something goes wrong, then the function returns an error code. I reckon there was supposed to be the following algorithm of the function work (pseudocode).