To get a trial key
fill out the form below
Team License (a basic version)
Enterprise License (an extended version)
* By clicking this button you agree to our Privacy Policy statement

Request our prices
New License
License Renewal
--Select currency--
* By clicking this button you agree to our Privacy Policy statement

Free PVS-Studio license for Microsoft MVP specialists
* By clicking this button you agree to our Privacy Policy statement

To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

Message submitted.

Your message has been sent. We will email you at

If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

PVS-Studio team: switching to Clang imp…

PVS-Studio team: switching to Clang improved PVS-Studio C++ analyzer's performance

May 31 2021

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. And just recently we've gotten around to try it.


Performance testing

We chose SelfTester - our utility for the analyzer's regression testing - as a benchmark. The utility analyzes a set of various projects and compares analysis results with reference values. For example, if the analyzer's core analysis showed new false positives or stopped showing applicable ones, this would mean the latest changes to the core caused some regression that needs to be fixed. To learn more about SelfTester, see the following article: "The Best is the Enemy of the Good".

The test base's projects vary in code volume quite a bit. Normally, when the running computer or test server is not overloaded, it takes SelfTester the same time - within the margin of error - to test the core of the same version. If the analyzer's productivity suffers, this significantly increases the overall testing time.

After we switched the C++ analyzer to the Clang compiler, SelfTester runs C++ core tests 11 minutes faster.


This means a 13% performance gain. That's quite significant, considering the only change was the compiler, don't you think?

Of course, there are disadvantages - but those are minor. The distribution's build slowed down by 8 minutes, and the executable file's size increased by 1.6 Mbytes - of those, 500 Kbytes come from static runtime linking.


Apparently, better performance is achieved by means of a longer LTO stage, that takes up most of the build time, and more aggressive loop unrolling and function inlining.

Now I'd like to talk more about issues we faced during the transition.

Generate a build for Clang

CMake scripts allow us to build code with all mainstream compilers, for required operating systems.

First, we used Visual Studio Installer to install the Clang compiler's components.


Clang-cl is a so-called "driver" that allows you to use clang with parameters from cl.exe. We expected clang-cl to interact with MSBuild transparently, almost like a native compiler.

Alternatively, we could have used official builds from the LLVM project. You can find them in their GitHub repository. However, they require an additional plugin so that Visual Studio could find the compilers. We chose the first route, so the toolset in examples below will be clangcl. If we used LLVM, the toolset name would have been llvm instead.

We specified toolchain in the solution generation command for Visual Studio:

cmake -G "Visual Studio 16 2019" -Tclangcl <src>

Alternatively, we could use GUI:


Then we opened the resulting project, built it - and got all these errors.


Fix the build

Although clang-cl looks and behaves like CL, under the hood it is a completely different compiler, with its own quirks.

We usually don't ignore compiler warnings, which is why we use /W4 and /WX flags. However, Clang may generate additional warnings that prevent the build from succeeding. That's why we temporarily deactivated them:


  if (WIN32)

Now that's better.

The GCC and Clang compilers, as opposed to MSVC for Windows, support the int128 type out-of-the-box. This is why a while ago PVS-Studio received an Int128 wrapper for Windows. The wrapper is written as inline assembly code wrapped in ifdef - in the best C/C++ traditions. Then we fixed preprocessor definitions. We replaced the code below

if (MSVC)
else ()
endif ()

with the following:

else ()
endif ()

Usually, the compiler driver, be it clang.exe or clang-cl.exe, passes a library with built-ins to the linker (lld). However, in this case MSBuild controlled the linker directly and did not know that the library was required. Consequently, the driver had no way to pass flags to the linker. So we handled the situation manually.




Yay! The build worked! However, when running tests, we encountered many segmentation faults:


The debugger was showing some strange value in IntegerInterval, while the problem was a bit further:


The data-flow mechanism's structures actively used the Int128 type we discussed earlier. The structures employed SIMD instructions to work with this type. The crashes were caused by an unaligned address:


The MOVAPS instruction moved a set of floating-point numbers to SIMD operation registers. For this operation to be successful, the address must be aligned and must end with 0. However, the address ended in 8. Here we had to help the compiler by setting the correct alignment:

class alignas(16) Int128

Looks good.

The last problem was prompted by Docker containers:


When generating builds for MSVC, we'd always employ static runtime linking that we had switched to dynamic for our Clang experiments. It turned out that Microsoft Visual C++ Redistributables were not included into Windows images by default. We decided to switch back to static linking so that our users wouldn't encounter the same challenges.


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.

Popular related articles
Static analysis as part of the development process in Unreal Engine

Date: Jun 27 2017

Author: Andrey Karpov

Unreal Engine continues to develop as new code is added and previously written code is changed. What is the inevitable consequence of ongoing development in a project? The emergence of new bugs in th…
How PVS-Studio Proved to Be More Attentive Than Three and a Half Programmers

Date: Oct 22 2018

Author: Andrey Karpov

Just like other static analyzers, PVS-Studio often produces false positives. What you are about to read is a short story where I'll tell you how PVS-Studio proved, just one more time, to be more atte…
Free PVS-Studio for those who develops open source projects

Date: Dec 22 2018

Author: Andrey Karpov

On the New 2019 year's eve, a PVS-Studio team decided to make a nice gift for all contributors of open-source projects hosted on GitHub, GitLab or Bitbucket. They are given free usage of PVS-Studio s…
Technologies used in the PVS-Studio code analyzer for finding bugs and potential vulnerabilities

Date: Nov 21 2018

Author: Andrey Karpov

A brief description of technologies used in the PVS-Studio tool, which let us effectively detect a large number of error patterns and potential vulnerabilities. The article describes the implementati…
The Ultimate Question of Programming, Refactoring, and Everything

Date: Apr 14 2016

Author: Andrey Karpov

Yes, you've guessed correctly - the answer is "42". In this article you will find 42 recommendations about coding in C++ that can help a programmer avoid a lot of errors, save time and effort. The au…
The way static analyzers fight against false positives, and why they do it

Date: Mar 20 2017

Author: Andrey Karpov

In my previous article I wrote that I don't like the approach of evaluating the efficiency of static analyzers with the help of synthetic tests. In that article, I give the example of a code fragment…
The Last Line Effect

Date: May 31 2014

Author: Andrey Karpov

I have studied many errors caused by the use of the Copy-Paste method, and can assure you that programmers most often tend to make mistakes in the last fragment of a homogeneous code block. I have ne…
Characteristics of PVS-Studio Analyzer by the Example of EFL Core Libraries, 10-15% of False Positives

Date: Jul 31 2017

Author: Andrey Karpov

After I wrote quite a big article about the analysis of the Tizen OS code, I received a large number of questions concerning the percentage of false positives and the density of errors (how many erro…
PVS-Studio ROI

Date: Jan 30 2019

Author: Andrey Karpov

Occasionally, we're asked a question, what monetary value the company will receive from using PVS-Studio. We decided to draw up a response in the form of an article and provide tables, which will sho…
The Evil within the Comparison Functions

Date: May 19 2017

Author: Andrey Karpov

Perhaps, readers remember my article titled "Last line effect". It describes a pattern I've once noticed: in most cases programmers make an error in the last line of similar text blocks. Now I want t…

Comments (0)

Next comments
This website uses cookies and other technology to provide you a more personalized experience. By continuing the view of our web-pages you accept the terms of using these files. If you don't want your personal data to be processed, please, leave this site.
Learn More →