[amadvance]

The Clang static analyzer is integrated into the build pipeline. Any warnings will cause the build to fail. Additionally, build with the flags -Wall and -Werror. When testing, run with runtime checkers such as Valgrind and sanitizers.

Periodically, run other static analyzers like Klocwork and Coverity. They can catch many more issues than Clang. It's not that Clang is bad, but it has inherent limitations because it only analyzes a single source file and stops analysis when you call a function from another module

[yaantc]

> It's not that Clang is bad, but it has inherent limitations because it only analyzes a single source file and stops analysis when you call a function from another module.

Nowadays that's only the default. But you can enable "cross translation units" [1] support to perform analysis across all the files of an application. It's easier to deploy CTU by using CodeChecker [2].

Also for the Clang static analyzer: make sure the build does use Z3. It should be the case now in most distro (it's the case in Debian stable ;). It will improve the results.

With both CTU and Z3 I'm very happy with the results. Klocwork mostly only reported false alarms after a clean CodeChecker pass.

     [1] https://clang.llvm.org/docs/analyzer/user-docs/CrossTranslationUnit.html
     [2] https://codechecker.readthedocs.io/en/latest/

[HybridCurve]

I agree that CTU analysis makes it better. There are also a bunch of tunables for the clang analyzer that you can take advantage of that suites like CodeChecker do not fully allow access to or take advantage of.

[Joel_Mckay]

Most LLVM projects I see are simply replacing -O3 pipelines. i.e. the code has already been heavily stress-tested prior to a safer optimization port of a stripped binary.

I also do time critical stuff, so llvm is a nonstarter for predictive latency in code motion. For most other use-cases, clang/llvm typically does improve performance a bit, and I do like its behavior on ARM.

Happy coding =)