GCC static analysis branch now available on Compiler Explorer

[Martin Sebor]

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?

Martin

> 
> Dave
> 
> [1] https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer
> 
>