Re: GCC static analysis branch now available on Compiler Explorer

[David Malcolm <dmalcolm at redhat dot com>]

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).

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
> > 
> >