I've been using it on a C program for almost one year, added to my Makefile's "make check" and it does work, although like with rustc some times you need to refactor something to express it in a way that it understands.
A few weeks ago after some changes in my program it would complain about something and after figuring out that it was actually fine, I didn't want to rewrite that part just to spell things out for the analyzer. I went to check if they had made improvements. My distro still had only GCC 10 but 11 had been released so I compiled it from source and tried it: the warning disappeared, and I decided to leave the code as it was.
If you give it a try, make sure to do it with GCC 11 at least, it improved a lot since 10.
I've used both quite extensively and I think that Coverity is still better, but GCC's static analysis is the closest free tool I've found that is doing the kind of complicated dataflow analysis that Coverity does.
In GCC 12, compared to GCC 10/11, it got a whole lot more "aggressive", to the point where it's no longer possible to compile the kernel with warn-error because of many static analysis warnings in core code, and I also had to rearrange and annotate [to disable some warnings] a lot of code in my own projects to get things to compile.
So next time you compile some C code with GCC 10, 11 or 12, definitely try -fanalyzer to see what it says, but be warned that you might be presented with some complicated error messages which require quite a lot of time to analyse to see if they're real problems or false alarms.
Sure, the power of warnings and gcc/clang's dedicated static analyzer modes aren't usually as good as commercial alternatives. The commercial ones either have fewer false positives or a larger suite of checks, or both. But the fact that (at least with clang) you can throw on a "-Wall --analyze" while you're compiling means that there's a huge level of convenience that you don't even need to setup or play with the build environment in order to get coverity/klockwork/etc working.
That PVS Studio is an interesting one. It has some very clever and (at one time) unique checks looking at similar consecutive statements and expressions and the identifier names used within in order to identify a pattern and find a deviation from the pattern.
This, and also the fact that everyone on the team has to use the compiler, no matter what they’re doing. Separate tools are much harder to get into everyone’s workflow.
Neat, I didn't even realise gcc had a static analyser built in (though it looks like it's only a couple of years old so I guess that's why I haven't noticed).
I'll have to try it out on some of my C/C++ projects.
A few weeks ago after some changes in my program it would complain about something and after figuring out that it was actually fine, I didn't want to rewrite that part just to spell things out for the analyzer. I went to check if they had made improvements. My distro still had only GCC 10 but 11 had been released so I compiled it from source and tried it: the warning disappeared, and I decided to leave the code as it was.
If you give it a try, make sure to do it with GCC 11 at least, it improved a lot since 10.