GCC static analysis branch now available on Compiler Explorer

Martin Sebor msebor@gmail.com
Tue Dec 10 19:51:00 GMT 2019

On 12/10/19 10:56 AM, David Malcolm wrote:
> On Tue, 2019-12-10 at 09:36 -0700, Martin Sebor wrote:
>> On 12/10/19 8:46 AM, David Malcolm wrote:
>>> For the adventurous/curious, my static analyzer branch of GCC [1]
>>> is
>>> now available on Compiler Explorer (aka godbolt.org) so you can try
>>> it
>>> out without building it yourself.  [Thanks to Matt Godbolt, Patrick
>>> Quist and others at the Compiler Explorer project]
>>> On https://godbolt.org/ within the C and C++ languages, select
>>>     "x86-64 gcc (static analysis)"
>>> as the compiler (though strictly speaking only C is in-scope right
>>> now).  It's configured to automatically inject -fanalyzer (just on
>>> this
>>> site; it isn't the default in the branch).
>>> Some precanned examples:
>>>     * various malloc issues: https://godbolt.org/z/tnx65n
>>>     * stdio issues: https://godbolt.org/z/4BP-Tj
>>>     * fprintf in signal handler: https://godbolt.org/z/ew7mW6
>>>     * tainted data affecting control flow:
>>> https://godbolt.org/z/3v8vSj
>>>     * password-leakage: https://godbolt.org/z/pRPYiv
>>> (the non-malloc examples are much more in "proof-of-concept"
>>> territory)
>>> Would it make sense to add an "analyzer" component to our bugzilla,
>>> even though this is still on a branch? (with me as default
>>> assignee)
>> Yes, that would make sense to me for bugs/enhancements specific to
>> just the analyzer.
>> I think it's important to have a shared understanding how requests
>> for new warnings (either completely new features or enhancements to
>> existing ones) should be triaged in Bugzilla.  For instance, pr82520
>> is a request to enhance -Wreturn-local-addr to detect other forms of
>> escaping dangling pointers besides by returning them from functions.
>> I think the request (and a number of others) would be a good fit for
>> the analyzer as well, but assigning it to the analyzer component
>> would suggest that it's suitable only for it.  How do we track
>> requests that we'd like handled in both?
> It feels to me that the question of BZ component is a proxy for a
> deeper scope question about what we want to handle in each warning.  If
> it's clear that we want an issue handled by both the core code *and* by
> the analyzer, then we should have two PRs.  Perhaps discuss in the PRs
> which things we expect to be handled by which warning (e.g. some cases
> might be capable of being caught by -Wreturn-local-addr, others might
> require the deeper analysis of -fanalyzer).

You're quite right that the two questions are related, and it is
the latter that prompted my comment above.

My concern is that I'm not sure we have a good rule of thumb to
decide whether a given warning is better suited to just the analyzer
or just the middle-end, or that it should be implemented in both.
Or even a good basis for making such decisions.  We have not discussed
yet if we should even worry about overlap (duplicate warnings issued
by both the analyzer and the middle-end).  I asked a few questions to
help get more clarity here in my comments on the initial patch but only
heard from Jeff.

So here are some of my thoughts.  I'd be very interested in yours (or
anyone else's who cares about this subject).

I can think of no warning that's currently implemented in the middle-
end (or that could be implemented there) that would not also be
appropriate for the analyzer.  IIUC, it has the potential for finding
more problems but may be more noisy than a middle-end implementation,
and take longer to analyze code.  Are there any kinds of problems that
you think are not appropriate for it?  Any inherent limitations?

At the same time I also think there's room for and value in providing
at least some support in the middle-end for pretty much every warning
that the analyzer already exposes options for.  They may not find as
many problems as the analyzer eventually will but they don't have as
much overhead (either to implement, or in terms of compile time --
the analysis often benefits optimizations as well).  In addition, by
being tied to the optimizers the detection provides an opportunity
to also prevent the bugs (by folding invalid code away, or inserting
traps or branches around it, perhaps under the control of users as we
have discussed).

In my mind the only reason to have to choose between one and other
is the duplication of effort and resource constraints: we don't have
enough contributors into either area.  There isn't a lot we can about
the latter but we should make an effort to minimize the duplication
(starting with bug triage).

But maybe I'm overanalyzing it and playing it by ear will work just


> Otherwise, have a single PR and assign it accordingly.
> I'm not sure if that answers your question.
> Dave
>> Martin
>>> Dave
>>> [1] https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer

More information about the Gcc mailing list