GSoC Static Analysis

GSoC Static Analysis

[Andrew Briand]

Hello,

I am an undergrad interested in extending GCC’s static analysis pass for GSoC 2020. In particular, I’m interested in adding C++ support. 

The selected project ideas list mentions adding new/delete checking and exception checking. The features that immediately come to my mind would be checking for undeleted allocations, mixing delete and delete[], double deletion (it seems the current static analyzer already checks for double free), and uncaught exceptions.

What would the expected scope of this project be? All of these features sound interesting to me, but I have no idea if doing all of them would be feasible within GSoC.

For information about my experience, I have about a year and a half of C++ experience (about nine months in a large code base), have written a few toy compilers in the past, and will soon be starting to take a formal course about compilers at my university.

Thanks,

Andrew Briand

Re: GSoC Static Analysis

[David Malcolm]

On Wed, 2020-03-25 at 15:36 -0700, Andrew Briand via Gcc wrote:
> Hello,
> 
> I am an undergrad interested in extending GCC’s static analysis pass
> for GSoC 2020. In particular, I’m interested in adding C++ support. 

Hi Andrew, thanks for your interest in the project.

> The selected project ideas list mentions adding new/delete checking
> and exception checking. The features that immediately come to my mind
> would be checking for undeleted allocations, mixing delete and
> delete[], double deletion (it seems the current static analyzer
> already checks for double free), and uncaught exceptions.

This sounds like a good list.  The analyzer currently ignores parts of
GCC's IR relating to exceptions, so properly supporting them will
require some new code.

> What would the expected scope of this project be? All of these
> features sound interesting to me, but I have no idea if doing all of
> them would be feasible within GSoC.

I kept the scope of the proposal quite broad, as there's plenty of work
to be done on the analyzer.

Several people have expressed an interest in the project (and, indeed
in the C++ part of it).  There may be room for more than one analyzer-
related project if we carve things out appropriately.  I think
realistically I don't have the bandwidth for more than two people (and
even that may be pushing it, especially given the disruption we're all
facing).

> For information about my experience, I have about a year and a half
> of C++ experience (about nine months in a large code base), have
> written a few toy compilers in the past, and will soon be starting to
> take a formal course about compilers at my university.

Sounds good.

A good next step for those interested in the project might be to try
compiling the analyzer from source.

David

Re: GSoC Static Analysis

[Jonathan Wakely]

On Wed, 25 Mar 2020 at 22:38, Andrew Briand wrote:
>
> Hello,
>
> I am an undergrad interested in extending GCC’s static analysis pass for GSoC 2020. In particular, I’m interested in adding C++ support.
>
> The selected project ideas list mentions adding new/delete checking and exception checking. The features that immediately come to my mind would be checking for undeleted allocations, mixing delete and delete[], double deletion (it seems the current static analyzer already checks for double free), and uncaught exceptions.

I'm not sure reporting about uncaught exceptions is useful, except in
the (unlikely) case where the entire program is visible to the
compiler, or maybe as an extension of the -Wterminate warning.
Exceptions are *supposed* to be uncaught in most code, so they
propagate to a layer that can actually do something about the error.

Some other ideas for C++ code could be:

- Locking a mutex twice, or locking it and not unlocking it in the same scope.

- Locking and unlocking a mutex around a region with no side effects
(i.e. no I/O, no volatile read/writes, no atomic operations on
non-local variables).

- Using a shared_ptr where there's only a single owner so unique_ptr would work.

- Returning a reference/pointer to a local variable through another
function (which the current -Wreturn-local-addr warning can't
diagnose) e.g.
int& f(int& i) { return i; }
int& g() { int i = 0; return f(i); }

GSoC Static Analysis

[Andrew Briand]

Hello,

I am an undergrad interested in extending GCC’s static analysis pass for GSoC 2020. In particular, I’m interested in adding C++ support. 

The selected project ideas list mentions adding new/delete checking and exception checking. The features that immediately come to my mind would be checking for undeleted allocations, mixing delete and delete[], double deletion (it seems the current static analyzer already checks for double free), and uncaught exceptions.

What would the expected scope of this project be? All of these features sound interesting to me, but I have no idea if doing all of them would be feasible within GSoC.

For information about my experience, I have about a year and a half of C++ experience (about nine months in a large code base), have written a few toy compilers in the past, and will soon be starting to take a formal course about compilers at my university.

Thanks,

Andrew Briand

GSoC Static Analysis

[Andrew Briand]

Hello,

I am an undergrad interested in extending GCC’s static analysis pass for GSoC 2020. In particular, I’m interested in adding C++ support. 

The selected project ideas list mentions adding new/delete checking and exception checking. The features that immediately come to my mind would be checking for undeleted allocations, mixing delete and delete[], double deletion (it seems the current static analyzer already checks for double free), and uncaught exceptions.

What would the expected scope of this project be? All of these features sound interesting to me, but I have no idea if doing all of them would be feasible within GSoC.

For information about my experience, I have about a year and a half of C++ experience (about nine months in a large code base), have written a few toy compilers in the past, and will soon be starting to take a formal course about compilers at my university.

Thanks,

Andrew Briand