Hello,
I’m looking at Clang’s analyzer as a replacement for Split (that we’re currently using) and it really looks nice and promising. However, due to a relatively large code base the analysis takes really a lot of time (about 14 minutes compared to the 1 min for Splint) and it won’t be possible to make the analysis every time a developer compile that code (as we did with Splint).
The analysis provided by Clang is really nice and we can certainly run it every few commits/hours/during the night, however I was looking if there is a way to speed it up (even on cost of bugs found) a bit to also have it at compilation time.
Right know, I made sure it’s compiled as a release (and not debug version) and I also disabled deadstore, malloc and similar checks (I’ve noticed they were a little bit slower than other checks), html reports and I’m running it in the following way:
clang -cc1 -triple i386-pc-linux-gnu -analyze -disable-free -disable-llvm-verifier -analyzer-checker=core -analyzer-output plist -w -mrelocation-model static -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -target-cpu pentium4 -target-linker-version 2.18.50.0.9 -momit-leaf-frame-pointer -resource-dir …/lib/clang/3.2 -fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem /usr/local/include -internal-isystem …/lib/clang/3.2/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdebug-compilation-dir clang/rx2 -ferror-limit 3 -fmessage-length 115 -mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics
In this way it takes about 10 minutes to finish (still 10 times slower than Splint) that’s still too much to run it every time the code is compiled 
May I ask you if you might have any hints for speeding up the analysis a little bit?
Thank you,
Vedran