[GSoC-2021] Interested in project `Extend the static analysis pass`

[GSoC-2021] Interested in project `Extend the static analysis pass`

[Saloni Garg]

Hi all,
I am an undergraduate student in AMU, Aligarh. I am interested in the
project* `Extend the static analysis pass`. *I have followed this(
https://gcc.gnu.org/pipermail/gcc/2021-March/234941.html) and been able to
successfully build and successfully ran and pass the test suite for C and
C++.

I found this sub-project `C++ support (new/delete checking, exceptions,
etc)` interesting and may be the conservative code for this can be made
along the lines of malloc/free implementation in C. I found here(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355) that some part of it
has already been implemented . I would like to expand it further and learn
about it, maybe start with writing some test cases, please let me know.

Further, I am inclined on this(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97111). Let me know if it is
still available.

Looking forward to hearing from you guys.
Thanks,
Saloni Garg

Re: [GSoC-2021] Interested in project `Extend the static analysis pass`

[David Malcolm]

On Thu, 2021-03-25 at 14:52 +0530, Saloni Garg via Gcc wrote:
> Hi all,
> I am an undergraduate student in AMU, Aligarh. I am interested in the
> project* `Extend the static analysis pass`. *I have followed this(
> https://gcc.gnu.org/pipermail/gcc/2021-March/234941.html) and been
> able to
> successfully build and successfully ran and pass the test suite for C
> and
> C++.
> 
> I found this sub-project `C++ support (new/delete checking,
> exceptions,
> etc)` interesting and may be the conservative code for this can be
> made
> along the lines of malloc/free implementation in C. I found here(
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355) that some part of
> it
> has already been implemented . I would like to expand it further and
> learn
> about it, maybe start with writing some test cases, please let me
> know.
> 
> Further, I am inclined on this(
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97111). Let me know if
> it is
> still available.
> 
> Looking forward to hearing from you guys.
> Thanks,
> Saloni Garg

Hi!

I'm the author/maintainer of the static analysis pass, and would be the
mentor for any GSoC project(s) involving it.

I've already implemented most of the new/delete checking in GCC 11; the
big missing component there is exception-handling.

Implementing exception-handling in the analyzer could make a good GSoC
project: it's non-trivial, but hopefully doable in one summer.  I see
you've already seen bug 97111, and there are some links in that bug to
resources.  Given that the analyzer runs on the gimple-ssa
representation, by the time it sees the code, much of the exception-
handling has already been translated into calls to various __cxa_-
prefixed functions in the C++ runtime, so part of the work would
involve "teaching" the analyzer about those functions.  One way to make
a start on this would be to create a collection of trivial C++ examples
that use exceptions, and then look at analyzer dumps to see what IR is
being "seen" by the analyzer for the various constructs.   (I actually
started this a long time ago and have a very crude barely-working
prototype, but it was just the start, and I've forgotten almost all of
it...)

Hope this is helpful
Dave

Re: [GSoC-2021] Interested in project `Extend the static analysis pass`

[Saloni Garg]

Hi, I have tried the following examples with the fanalyzer option in g++.

1 (a)
void myFunction()
{
    char *p =new char;
}
int main()
{
   func();
   return 0;
}

1(b)
void myFunction()
{
    try {
         char *p = new char;
         throw p;
    }
    catch(...) {
    }
}
int main()
{
   myFunction();
   return 0;
}
In 1(a), there is no exception handling. When I ran `cc1plus`, a memory
leak was reported as shown in bug #94355.
In 1(b), there is a use of exception handling. When I ran cc1plus`, no
memory leaks were detected. I believe there should be one. Can you please
confirm from your side as well? As you said all the calls to try, catch and
throw got converted to _cxa prefixed functions. I am trying to find the
places where the corresponding checks can be placed for the analysis of
exception handling in gimple IR.

Please, let me know your thoughts on this.

On Fri, Mar 26, 2021 at 12:48 AM David Malcolm <dmalcolm@redhat.com> wrote:

> On Thu, 2021-03-25 at 14:52 +0530, Saloni Garg via Gcc wrote:
> > Hi all,
> > I am an undergraduate student in AMU, Aligarh. I am interested in the
> > project* `Extend the static analysis pass`. *I have followed this(
> > https://gcc.gnu.org/pipermail/gcc/2021-March/234941.html) and been
> > able to
> > successfully build and successfully ran and pass the test suite for C
> > and
> > C++.
> >
> > I found this sub-project `C++ support (new/delete checking,
> > exceptions,
> > etc)` interesting and may be the conservative code for this can be
> > made
> > along the lines of malloc/free implementation in C. I found here(
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355) that some part of
> > it
> > has already been implemented . I would like to expand it further and
> > learn
> > about it, maybe start with writing some test cases, please let me
> > know.
> >
> > Further, I am inclined on this(
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97111). Let me know if
> > it is
> > still available.
> >
> > Looking forward to hearing from you guys.
> > Thanks,
> > Saloni Garg
>
> Hi!
>
> I'm the author/maintainer of the static analysis pass, and would be the
> mentor for any GSoC project(s) involving it.
>
> I've already implemented most of the new/delete checking in GCC 11; the
> big missing component there is exception-handling.
>
> Implementing exception-handling in the analyzer could make a good GSoC
> project: it's non-trivial, but hopefully doable in one summer.  I see
> you've already seen bug 97111, and there are some links in that bug to
> resources.  Given that the analyzer runs on the gimple-ssa
> representation, by the time it sees the code, much of the exception-
> handling has already been translated into calls to various __cxa_-
> prefixed functions in the C++ runtime, so part of the work would
> involve "teaching" the analyzer about those functions.  One way to make
> a start on this would be to create a collection of trivial C++ examples
> that use exceptions, and then look at analyzer dumps to see what IR is
> being "seen" by the analyzer for the various constructs.   (I actually
> started this a long time ago and have a very crude barely-working
> prototype, but it was just the start, and I've forgotten almost all of
> it...)
>
> Hope this is helpful
> Dave
>
>
>

Re: [GSoC-2021] Interested in project `Extend the static analysis pass`

[David Malcolm]

On Sun, 2021-03-28 at 18:06 +0530, Saloni Garg wrote:
> Hi, I have tried the following examples with the fanalyzer option in
> g++.
> 
> 1 (a)
> void myFunction()
> {
>     char *p =new char;
> }
> int main()
> {
>    func();
>    return 0;
> }

BTW, are you familiar with Compiler Explorer (godbolt.org)?  It's very
handy for testing small snippets of code on different compilers and
different compiler versions.  Though I don't know how long the URLs are
good for (in terms of how long code is cached for)

Fixing up the name of the called function to "func":
  https://godbolt.org/z/TnM6n4xGc
I get the leak report, as per RFE 94355.  This warning looks correct,
in that p does indeed leak.

I should mention that the analyzer has some special-casing for "main",
in that the user might not care about one-time leaks that occur within
"main", or something only called directly by it; this doesn't seem to
be the case here.  If I remove the implementation to main, the analyzer
still correctly complains about the leak:
  https://godbolt.org/z/zhK4vW6G8

<source>: In function 'void func()':
<source>:4:1: warning: leak of 'p' [CWE-401] [-Wanalyzer-malloc-leak]
    4 | }
      | ^
  'void func()': events 1-2
    |
    |    3 |     char *p =new char;
    |      |                  ^~~~
    |      |                  |
    |      |                  (1) allocated here
    |    4 | }
    |      | ~                 
    |      | |
    |      | (2) 'p' leaks here; was allocated at (1)
    |


> 1(b)
> void myFunction()
> {
>     try {
>          char *p = new char;
>          throw p;
>     }
>     catch(...) {
>     }
> }
> int main()
> {
>    myFunction();
>    return 0;
> }
> In 1(a), there is no exception handling. When I ran `cc1plus`, a
> memory
> leak was reported as shown in bug #94355.
> In 1(b), there is a use of exception handling. When I ran cc1plus`,
> no
> memory leaks were detected. I believe there should be one. Can you
> please
> confirm from your side as well?

I too am seeing no diagnostics on 1(b).

> As you said all the calls to try, catch and
> throw got converted to _cxa prefixed functions. 

-fdump-ipa-analyzer=stderr shows the _cxa-prefixed functions:
  https://godbolt.org/z/YMa9dE6aM

> I am trying to find the
> places where the corresponding checks can be placed for the analysis
> of
> exception handling in gimple IR.

Have a look at exploded_node::on_stmt in engine.cc; in particular, see
the GIMPLE_CALL case in the switch statement.  Most of the the
analyzer's "knowledge" of the behaviors of specific functions is here,
or called from here.

The simpler cases are handled in the call to
  m_region_model->on_call_pre
for functions which merely update state, which are implemented in
region-model-impl-calls.cc

Cases involving state machines (e.g. allocation) are handled in the:
  sm.on_stmt
call torwards the bottom of the function.

But exception-handling is a special case, in that it affects control
flow.  The closest thing to compare it to currently within the analyzer
is setjmp/longjmp, so it's worth stepping through how that is handled.
In particular, the real implementation of longjmp involves directly
updating the program counter, registers and stack, potentially popping
multiple stack frames.  This is similar to what throwing an exception
does.

So I'd recommend looking at the analyzer's implementation of
setjmp/longjmp, the custom classes that I added to handle them, and
stepping through how exploded_node::on_stmt handles setjmp and longjmp
calls, and what the resulting exploded_graph looks like (-fdump-
analyzer-exploded-graph and -fdump-analyzer-supergraph), in that
special-cased edges have to be created that weren't in the original
CFGs or callgraph (for the interprocedural case).

I think an implementation of exception-handling would look somewhat
similar.

> Please, let me know your thoughts on this.

Looks like you're making a great start.

Hope this is helpful
Dave


> On Fri, Mar 26, 2021 at 12:48 AM David Malcolm <dmalcolm@redhat.com>
> wrote:
> 
> > On Thu, 2021-03-25 at 14:52 +0530, Saloni Garg via Gcc wrote:
> > > Hi all,
> > > I am an undergraduate student in AMU, Aligarh. I am interested in
> > > the
> > > project* `Extend the static analysis pass`. *I have followed
> > > this(
> > > https://gcc.gnu.org/pipermail/gcc/2021-March/234941.html) and
> > > been
> > > able to
> > > successfully build and successfully ran and pass the test suite
> > > for C
> > > and
> > > C++.
> > > 
> > > I found this sub-project `C++ support (new/delete checking,
> > > exceptions,
> > > etc)` interesting and may be the conservative code for this can
> > > be
> > > made
> > > along the lines of malloc/free implementation in C. I found here(
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355) that some
> > > part of
> > > it
> > > has already been implemented . I would like to expand it further
> > > and
> > > learn
> > > about it, maybe start with writing some test cases, please let me
> > > know.
> > > 
> > > Further, I am inclined on this(
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97111). Let me know
> > > if
> > > it is
> > > still available.
> > > 
> > > Looking forward to hearing from you guys.
> > > Thanks,
> > > Saloni Garg
> > 
> > Hi!
> > 
> > I'm the author/maintainer of the static analysis pass, and would be
> > the
> > mentor for any GSoC project(s) involving it.
> > 
> > I've already implemented most of the new/delete checking in GCC 11;
> > the
> > big missing component there is exception-handling.
> > 
> > Implementing exception-handling in the analyzer could make a good
> > GSoC
> > project: it's non-trivial, but hopefully doable in one summer.  I
> > see
> > you've already seen bug 97111, and there are some links in that bug
> > to
> > resources.  Given that the analyzer runs on the gimple-ssa
> > representation, by the time it sees the code, much of the
> > exception-
> > handling has already been translated into calls to various __cxa_-
> > prefixed functions in the C++ runtime, so part of the work would
> > involve "teaching" the analyzer about those functions.  One way to
> > make
> > a start on this would be to create a collection of trivial C++
> > examples
> > that use exceptions, and then look at analyzer dumps to see what IR
> > is
> > being "seen" by the analyzer for the various constructs.   (I
> > actually
> > started this a long time ago and have a very crude barely-working
> > prototype, but it was just the start, and I've forgotten almost all
> > of
> > it...)
> > 
> > Hope this is helpful
> > Dave
> > 
> > 
> > 

Re: [GSoC-2021] Interested in project `Extend the static analysis pass`

[Saloni Garg]

On Sun, Mar 28, 2021 at 8:03 PM David Malcolm <dmalcolm@redhat.com> wrote:

> On Sun, 2021-03-28 at 18:06 +0530, Saloni Garg wrote:
> > Hi, I have tried the following examples with the fanalyzer option in
> > g++.
> >
> > 1 (a)
> > void myFunction()
> > {
> >     char *p =new char;
> > }
> > int main()
> > {
> >    func();
> >    return 0;
> > }
>
> BTW, are you familiar with Compiler Explorer (godbolt.org)?  It's very
> handy for testing small snippets of code on different compilers and
> different compiler versions.  Though I don't know how long the URLs are
> good for (in terms of how long code is cached for)
>
> Fixing up the name of the called function to "func":
>   https://godbolt.org/z/TnM6n4xGc
> I get the leak report, as per RFE 94355.  This warning looks correct,
> in that p does indeed leak.
>
> Hi, thanks for the effort, sorry for the typo. I now know about the
godbolt.org and it is certainly useful.

> I should mention that the analyzer has some special-casing for "main",
> in that the user might not care about one-time leaks that occur within
> "main", or something only called directly by it; this doesn't seem to
> be the case here.  If I remove the implementation to main, the analyzer
> still correctly complains about the leak:
>   https://godbolt.org/z/zhK4vW6G8
>
> That's something new. I also didn't know that. I believe we can shift our
minimal example to just func() and remove main().

> <source>: In function 'void func()':
> <source>:4:1: warning: leak of 'p' [CWE-401] [-Wanalyzer-malloc-leak]
>     4 | }
>       | ^
>   'void func()': events 1-2
>     |
>     |    3 |     char *p =new char;
>     |      |                  ^~~~
>     |      |                  |
>     |      |                  (1) allocated here
>     |    4 | }
>     |      | ~
>     |      | |
>     |      | (2) 'p' leaks here; was allocated at (1)
>     |
>
>
> > 1(b)
> > void myFunction()
> > {
> >     try {
> >          char *p = new char;
> >          throw p;
> >     }
> >     catch(...) {
> >     }
> > }
> > int main()
> > {
> >    myFunction();
> >    return 0;
> > }
> > In 1(a), there is no exception handling. When I ran `cc1plus`, a
> > memory
> > leak was reported as shown in bug #94355.
> > In 1(b), there is a use of exception handling. When I ran cc1plus`,
> > no
> > memory leaks were detected. I believe there should be one. Can you
> > please
> > confirm from your side as well?
>
> I too am seeing no diagnostics on 1(b).
>
Thanks for confirming.

>
> > As you said all the calls to try, catch and
> > throw got converted to _cxa prefixed functions.
>
> -fdump-ipa-analyzer=stderr shows the _cxa-prefixed functions:
>   https://godbolt.org/z/YMa9dE6aM
>
> > I am trying to find the
> > places where the corresponding checks can be placed for the analysis
> > of
> > exception handling in gimple IR.
>
> Have a look at exploded_node::on_stmt in engine.cc; in particular, see
> the GIMPLE_CALL case in the switch statement.  Most of the the
> analyzer's "knowledge" of the behaviors of specific functions is here,
> or called from here.
>
> The simpler cases are handled in the call to
>   m_region_model->on_call_pre
> for functions which merely update state, which are implemented in
> region-model-impl-calls.cc
>
> Cases involving state machines (e.g. allocation) are handled in the:
>   sm.on_stmt
> call torwards the bottom of the function.
>
> But exception-handling is a special case, in that it affects control
> flow.  The closest thing to compare it to currently within the analyzer
> is setjmp/longjmp, so it's worth stepping through how that is handled.
> In particular, the real implementation of longjmp involves directly
> updating the program counter, registers and stack, potentially popping
> multiple stack frames.  This is similar to what throwing an exception
> does.
>
> So I'd recommend looking at the analyzer's implementation of
> setjmp/longjmp, the custom classes that I added to handle them, and
> stepping through how exploded_node::on_stmt handles setjmp and longjmp
> calls, and what the resulting exploded_graph looks like (-fdump-
> analyzer-exploded-graph and -fdump-analyzer-supergraph), in that
> special-cased edges have to be created that weren't in the original
> CFGs or callgraph (for the interprocedural case).
>
> I think an implementation of exception-handling would look somewhat
> similar.
>
> Thanks, for all the references to the code. I am new to GCC, so apologies
if I am a bit slow in understanding. I am trying to run and go through all
the references that you gave me.

> > Please, let me know your thoughts on this.
>
> Looks like you're making a great start.
>
Thanks for the feedback.  In parallel, can I start working on the Gsoc
proposal as well? I hope, we can get suggestions from the gcc community as
well once the things are written properly in a document.

- Saloni

>
> Hope this is helpful
> Dave
>
>
> > On Fri, Mar 26, 2021 at 12:48 AM David Malcolm <dmalcolm@redhat.com>
> > wrote:
> >
> > > On Thu, 2021-03-25 at 14:52 +0530, Saloni Garg via Gcc wrote:
> > > > Hi all,
> > > > I am an undergraduate student in AMU, Aligarh. I am interested in
> > > > the
> > > > project* `Extend the static analysis pass`. *I have followed
> > > > this(
> > > > https://gcc.gnu.org/pipermail/gcc/2021-March/234941.html) and
> > > > been
> > > > able to
> > > > successfully build and successfully ran and pass the test suite
> > > > for C
> > > > and
> > > > C++.
> > > >
> > > > I found this sub-project `C++ support (new/delete checking,
> > > > exceptions,
> > > > etc)` interesting and may be the conservative code for this can
> > > > be
> > > > made
> > > > along the lines of malloc/free implementation in C. I found here(
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355) that some
> > > > part of
> > > > it
> > > > has already been implemented . I would like to expand it further
> > > > and
> > > > learn
> > > > about it, maybe start with writing some test cases, please let me
> > > > know.
> > > >
> > > > Further, I am inclined on this(
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97111). Let me know
> > > > if
> > > > it is
> > > > still available.
> > > >
> > > > Looking forward to hearing from you guys.
> > > > Thanks,
> > > > Saloni Garg
> > >
> > > Hi!
> > >
> > > I'm the author/maintainer of the static analysis pass, and would be
> > > the
> > > mentor for any GSoC project(s) involving it.
> > >
> > > I've already implemented most of the new/delete checking in GCC 11;
> > > the
> > > big missing component there is exception-handling.
> > >
> > > Implementing exception-handling in the analyzer could make a good
> > > GSoC
> > > project: it's non-trivial, but hopefully doable in one summer.  I
> > > see
> > > you've already seen bug 97111, and there are some links in that bug
> > > to
> > > resources.  Given that the analyzer runs on the gimple-ssa
> > > representation, by the time it sees the code, much of the
> > > exception-
> > > handling has already been translated into calls to various __cxa_-
> > > prefixed functions in the C++ runtime, so part of the work would
> > > involve "teaching" the analyzer about those functions.  One way to
> > > make
> > > a start on this would be to create a collection of trivial C++
> > > examples
> > > that use exceptions, and then look at analyzer dumps to see what IR
> > > is
> > > being "seen" by the analyzer for the various constructs.   (I
> > > actually
> > > started this a long time ago and have a very crude barely-working
> > > prototype, but it was just the start, and I've forgotten almost all
> > > of
> > > it...)
> > >
> > > Hope this is helpful
> > > Dave
> > >
> > >
> > >
>
>
>

Re: [GSoC-2021] Interested in project `Extend the static analysis pass`

[David Malcolm]

On Tue, 2021-03-30 at 16:06 +0530, Saloni Garg wrote:
> On Sun, Mar 28, 2021 at 8:03 PM David Malcolm <dmalcolm@redhat.com>
> wrote:
> 
> > On Sun, 2021-03-28 at 18:06 +0530, Saloni Garg wrote:
> > > Hi, I have tried the following examples with the fanalyzer option
> > > in
> > > g++.
> > > 
> > > 1 (a)
> > > void myFunction()
> > > {
> > >     char *p =new char;
> > > }
> > > int main()
> > > {
> > >    func();
> > >    return 0;
> > > }
> > 
> > BTW, are you familiar with Compiler Explorer (godbolt.org)?  It's
> > very
> > handy for testing small snippets of code on different compilers and
> > different compiler versions.  Though I don't know how long the URLs
> > are
> > good for (in terms of how long code is cached for)
> > 
> > Fixing up the name of the called function to "func":
> >   https://godbolt.org/z/TnM6n4xGc
> > I get the leak report, as per RFE 94355.  This warning looks
> > correct,
> > in that p does indeed leak.
> > 
> > Hi, thanks for the effort, sorry for the typo. I now know about the
> godbolt.org and it is certainly useful.
> 
> > I should mention that the analyzer has some special-casing for
> > "main",
> > in that the user might not care about one-time leaks that occur
> > within
> > "main", or something only called directly by it; this doesn't seem
> > to
> > be the case here.  If I remove the implementation to main, the
> > analyzer
> > still correctly complains about the leak:
> >   https://godbolt.org/z/zhK4vW6G8
> > 
> > That's something new. I also didn't know that. I believe we can
> > shift our
> minimal example to just func() and remove main().

Yes - simpler is better with such examples.

(Occasionally it's helpful to have "main" so that the resulting code
can be executed - especially under valgrind, as a check that something
really is leaking - but a simpler reproducer is usually best when
debugging)

[...snip...]

> > I think an implementation of exception-handling would look somewhat
> > similar.
> > 
> > Thanks, for all the references to the code. I am new to GCC, so
> > apologies
> if I am a bit slow in understanding. I am trying to run and go
> through all
> the references that you gave me.

Sorry if I'm overwhelming you with too much at once...

...and here's yet more information!

I wrote this guide to getting started with hacking on GCC, aimed at
newcomers to the project:
  https://dmalcolm.fedorapeople.org/gcc/newbies-guide/

and in particular you may find the guide to debugging GCC useful:
  https://dmalcolm.fedorapeople.org/gcc/newbies-guide/debugging.html

FWIW I like to use
  -fanalyzer-dump-stderr
when stepping through the analyzer in gdb, so that I can put
breakpoints on what I'm interested in, but also have a log of the
activity that happened between the breakpoints.


> > > Please, let me know your thoughts on this.
> > 
> > Looks like you're making a great start.
> > 
> Thanks for the feedback.  In parallel, can I start working on the
> Gsoc
> proposal as well?

Please do work on the formal proposal - without it we can't accept you
as a GSoC student.  The window for submitting proposals opened
yesterday, and I believe it closes in a couple of weeks, and you need
to do that, so any experimentation you do now should really just be in
support of writing a good proposal.  It would be a shame to not have a
good prospective candidate because they didn't allow enough time to do
the proper GSoC paperwork before the deadline.

> I hope, we can get suggestions from the gcc community as
> well once the things are written properly in a document.

Indeed

Hope this is constructive
Dave

[...snip...]

Re: [GSoC-2021] Interested in project `Extend the static analysis pass`

[Saloni Garg]

On Tue, Mar 30, 2021 at 6:42 PM David Malcolm <dmalcolm@redhat.com> wrote:

> On Tue, 2021-03-30 at 16:06 +0530, Saloni Garg wrote:
> > On Sun, Mar 28, 2021 at 8:03 PM David Malcolm <dmalcolm@redhat.com>
> > wrote:
> >
> > > On Sun, 2021-03-28 at 18:06 +0530, Saloni Garg wrote:
> > > > Hi, I have tried the following examples with the fanalyzer option
> > > > in
> > > > g++.
> > > >
> > > > 1 (a)
> > > > void myFunction()
> > > > {
> > > >     char *p =new char;
> > > > }
> > > > int main()
> > > > {
> > > >    func();
> > > >    return 0;
> > > > }
> > >
> > > BTW, are you familiar with Compiler Explorer (godbolt.org)?  It's
> > > very
> > > handy for testing small snippets of code on different compilers and
> > > different compiler versions.  Though I don't know how long the URLs
> > > are
> > > good for (in terms of how long code is cached for)
> > >
> > > Fixing up the name of the called function to "func":
> > >   https://godbolt.org/z/TnM6n4xGc
> > > I get the leak report, as per RFE 94355.  This warning looks
> > > correct,
> > > in that p does indeed leak.
> > >
> > > Hi, thanks for the effort, sorry for the typo. I now know about the
> > godbolt.org and it is certainly useful.
> >
> > > I should mention that the analyzer has some special-casing for
> > > "main",
> > > in that the user might not care about one-time leaks that occur
> > > within
> > > "main", or something only called directly by it; this doesn't seem
> > > to
> > > be the case here.  If I remove the implementation to main, the
> > > analyzer
> > > still correctly complains about the leak:
> > >   https://godbolt.org/z/zhK4vW6G8
> > >
> > > That's something new. I also didn't know that. I believe we can
> > > shift our
> > minimal example to just func() and remove main().
>
> Yes - simpler is better with such examples.
>
> (Occasionally it's helpful to have "main" so that the resulting code
> can be executed - especially under valgrind, as a check that something
> really is leaking - but a simpler reproducer is usually best when
> debugging)
>
> [...snip...]
>
Ok, I will keep this in mind. Thanks.

>
> > > I think an implementation of exception-handling would look somewhat
> > > similar.
> > >
> > > Thanks, for all the references to the code. I am new to GCC, so
> > > apologies
> > if I am a bit slow in understanding. I am trying to run and go
> > through all
> > the references that you gave me.
>
> Sorry if I'm overwhelming you with too much at once...
>
> ...and here's yet more information!
>
> I wrote this guide to getting started with hacking on GCC, aimed at
> newcomers to the project:
>   https://dmalcolm.fedorapeople.org/gcc/newbies-guide/
>
> and in particular you may find the guide to debugging GCC useful:
>   https://dmalcolm.fedorapeople.org/gcc/newbies-guide/debugging.html
>
> FWIW I like to use
>   -fanalyzer-dump-stderr
> when stepping through the analyzer in gdb, so that I can put
> breakpoints on what I'm interested in, but also have a log of the
> activity that happened between the breakpoints.
>
No, it's actually fun learning all this. Thank you for sharing all the
references. Although, I was already using gdb to travel inside the code.

>
> > > > Please, let me know your thoughts on this.
> > >
> > > Looks like you're making a great start.
> > >
> > Thanks for the feedback.  In parallel, can I start working on the
> > Gsoc
> > proposal as well?
>
> Please do work on the formal proposal - without it we can't accept you
> as a GSoC student.  The window for submitting proposals opened
> yesterday, and I believe it closes in a couple of weeks, and you need
> to do that, so any experimentation you do now should really just be in
> support of writing a good proposal.  It would be a shame to not have a
> good prospective candidate because they didn't allow enough time to do
> the proper GSoC paperwork before the deadline.
>
Thanks for understanding. Here is an initial draft (
https://docs.google.com/document/d/1inkkU5B55s_FOWRzUuf38s7XEet65kc0dW3yFn0yh1M/edit?usp=sharing)
of my GSoC proposal. I am yet to fill in the missing blocks.
Please, let me know if you have any comments on the document itself.

>
> > I hope, we can get suggestions from the gcc community as
> > well once the things are written properly in a document.
>
> Indeed
>
> Hope this is constructive
> Dave
>
> [...snip...]
>
> I also request the GCC community also to please provide any suggestions
possible on the above-shared document.

-Saloni

Re: [GSoC-2021] Interested in project `Extend the static analysis pass`

[David Malcolm]

On Wed, 2021-03-31 at 21:41 +0530, Saloni Garg wrote:
> On Tue, Mar 30, 2021 at 6:42 PM David Malcolm <dmalcolm@redhat.com>
> wrote:
> 
> > On Tue, 2021-03-30 at 16:06 +0530, Saloni Garg wrote:
> > > On Sun, Mar 28, 2021 at 8:03 PM David Malcolm <
> > > dmalcolm@redhat.com>
> > > wrote:

[...snip...]

> > > 
> No, it's actually fun learning all this. Thank you for sharing all
> the
> references. Although, I was already using gdb to travel inside the
> code.

Great!

> > 
> > > > > Please, let me know your thoughts on this.
> > > > 
> > > > Looks like you're making a great start.
> > > > 
> > > Thanks for the feedback.  In parallel, can I start working on the
> > > Gsoc
> > > proposal as well?
> > 
> > Please do work on the formal proposal - without it we can't accept
> > you
> > as a GSoC student.  The window for submitting proposals opened
> > yesterday, and I believe it closes in a couple of weeks, and you
> > need
> > to do that, so any experimentation you do now should really just be
> > in
> > support of writing a good proposal.  It would be a shame to not
> > have a
> > good prospective candidate because they didn't allow enough time to
> > do
> > the proper GSoC paperwork before the deadline.
> > 
> Thanks for understanding. Here is an initial draft (
>   
> https://docs.google.com/document/d/1inkkU5B55s_FOWRzUuf38s7XEet65kc0dW3yFn0yh1M/edit?usp=sharing
> )
> of my GSoC proposal. I am yet to fill in the missing blocks.
> Please, let me know if you have any comments on the document itself.

Caveat: I'm not familiar with the expected format of such documents.

Looks like a good first draft.

Some notes:
- maybe update the title to be more specific (i.e. that it's about
extending the pass to support C++ exception-handling)
- my email address is misspelled (missing the leading "d")
- in Example 2, maybe spell out why it's a leak - when does the
allocated buffer stop being referenceable?
- you have a simple example of a false negative; is it possible to give
a simple example of a false positive?  (I think "new" is meant to raise
an exception if it fails, so a diagnostics about a NULL-deref on
unchecked new might be a false positive.  I'm not sure)
- maybe specify that this is exception-handling specifically for C++
code (GCC supports many languages)
- "sample example programs": for "sample" did you mean to write
"simple" here?
- as well as understanding code, you'll need to understand data,
specifically getting a feel for the kinds of control flow graphs that
the analyzer is receiving as inputs i.e. what the analyzer "sees" when
the user inputs various C++ language constructs; what interprocedural
vs intraprocedural raise/try/catch situations look like, etc.

Hope this makes sense and is helpful
Dave

Re: [GSoC-2021] Interested in project `Extend the static analysis pass`

[Saloni Garg]

Hi, apologies for the delayed reply. I was having some college commitments.
On Wed, Mar 31, 2021 at 11:22 PM David Malcolm <dmalcolm@redhat.com> wrote:

> On Wed, 2021-03-31 at 21:41 +0530, Saloni Garg wrote:
> > On Tue, Mar 30, 2021 at 6:42 PM David Malcolm <dmalcolm@redhat.com>
> > wrote:
> >
> > > On Tue, 2021-03-30 at 16:06 +0530, Saloni Garg wrote:
> > > > On Sun, Mar 28, 2021 at 8:03 PM David Malcolm <
> > > > dmalcolm@redhat.com>
> > > > wrote:
>
> [...snip...]
>
> > > >
> > No, it's actually fun learning all this. Thank you for sharing all
> > the
> > references. Although, I was already using gdb to travel inside the
> > code.
>
> Great!
>
> > >
> > > > > > Please, let me know your thoughts on this.
> > > > >
> > > > > Looks like you're making a great start.
> > > > >
> > > > Thanks for the feedback.  In parallel, can I start working on the
> > > > Gsoc
> > > > proposal as well?
> > >
> > > Please do work on the formal proposal - without it we can't accept
> > > you
> > > as a GSoC student.  The window for submitting proposals opened
> > > yesterday, and I believe it closes in a couple of weeks, and you
> > > need
> > > to do that, so any experimentation you do now should really just be
> > > in
> > > support of writing a good proposal.  It would be a shame to not
> > > have a
> > > good prospective candidate because they didn't allow enough time to
> > > do
> > > the proper GSoC paperwork before the deadline.
> > >
> > Thanks for understanding. Here is an initial draft (
> >
> >
> https://docs.google.com/document/d/1inkkU5B55s_FOWRzUuf38s7XEet65kc0dW3yFn0yh1M/edit?usp=sharing
> > )
> > of my GSoC proposal. I am yet to fill in the missing blocks.
> > Please, let me know if you have any comments on the document itself.
>
> Caveat: I'm not familiar with the expected format of such documents.
>
> Looks like a good first draft.

I don't think there is any such expected format(I checked some previous
years accepted proposals). I believe if we clearly write the expected goal
and the tentative approach to reach it, that would be okay for the proposal.

>
> Some notes:
> - maybe update the title to be more specific (i.e. that it's about
> extending the pass to support C++ exception-handling)
>
Done.

> - my email address is misspelled (missing the leading "d")
>
Really sorry. Done.

> - in Example 2, maybe spell out why it's a leak - when does the
> allocated buffer stop being referenceable?
>
Explained. Please let me know if you feel it has any loose ends.

> - you have a simple example of a false negative; is it possible to give
> a simple example of a false positive?  (I think "new" is meant to raise
> an exception if it fails, so a diagnostics about a NULL-deref on
> unchecked new might be a false positive.  I'm not sure)
>
I tried the following example:

#include <new>
#include <iostream>
using namespace std;
int *p;
int* alloc() {
   return new int;
}
void free() {
   delete p;
}
int main()
{
   try {
     p = alloc();
     free();
   } catch(...) {
   }
   return 0;
}
Please, have a look here (https://godbolt.org/z/8WvoaP67n). I believe it is
a false positive, I am not sure, please confirm.

> - maybe specify that this is exception-handling specifically for C++
> code (GCC supports many languages)
>
Done.

> - "sample example programs": for "sample" did you mean to write
> "simple" here?
>
By sample examples, I meant the test cases that shall be used to prove the
correctness of the patches during the course.

> - as well as understanding code, you'll need to understand data,
> specifically getting a feel for the kinds of control flow graphs that
> the analyzer is receiving as inputs i.e. what the analyzer "sees" when
> the user inputs various C++ language constructs; what interprocedural
> vs intraprocedural raise/try/catch situations look like, etc.
>
I am in the process to understand how the analyzer works. I believe I have
just got a gist of the approach being used. The gimple graph has been
processed in a Worklist manner. We analyze each statement and add
predecessors/successors if there is some new information coming out of the
analyzed statement. For example, In the memory leak examples discussed
here, if at a statement I see a *new *expression, then I need to add all
the nodes where this value can flow into, to find out a possible *free
*expression
to block the possible memory leak.
In the case of interprocedural, I need to incorporate the effects of any
function calls in between and see if it changes my analysis result or not.

Please, let me know if I am wrong somewhere.
-Saloni

>
> Hope this makes sense and is helpful
> Dave
>
>

Re: [GSoC-2021] Interested in project `Extend the static analysis pass`

[David Malcolm]

On Wed, 2021-04-07 at 01:59 +0530, Saloni Garg wrote:
> Hi, apologies for the delayed reply. I was having some college
> commitments.
> On Wed, Mar 31, 2021 at 11:22 PM David Malcolm <dmalcolm@redhat.com>
> wrote:
> 
> > On Wed, 2021-03-31 at 21:41 +0530, Saloni Garg wrote:
> > > On Tue, Mar 30, 2021 at 6:42 PM David Malcolm <
> > > dmalcolm@redhat.com>
> > > wrote:
> > > 
> > > > On Tue, 2021-03-30 at 16:06 +0530, Saloni Garg wrote:
> > > > > On Sun, Mar 28, 2021 at 8:03 PM David Malcolm <
> > > > > dmalcolm@redhat.com>
> > > > > wrote:
> > 

[...snip...]

> > > > Please do work on the formal proposal - without it we can't
> > > > accept
> > > > you
> > > > as a GSoC student.  The window for submitting proposals opened
> > > > yesterday, and I believe it closes in a couple of weeks, and
> > > > you
> > > > need
> > > > to do that, so any experimentation you do now should really
> > > > just be
> > > > in
> > > > support of writing a good proposal.  It would be a shame to not
> > > > have a
> > > > good prospective candidate because they didn't allow enough
> > > > time to
> > > > do
> > > > the proper GSoC paperwork before the deadline.
> > > > 
> > > Thanks for understanding. Here is an initial draft (
> > > 
> > > 
> >   
> > https://docs.google.com/document/d/1inkkU5B55s_FOWRzUuf38s7XEet65kc0dW3yFn0yh1M/edit?usp=sharing
> > > )
> > > of my GSoC proposal. I am yet to fill in the missing blocks.
> > > Please, let me know if you have any comments on the document
> > > itself.
> > 
> > Caveat: I'm not familiar with the expected format of such
> > documents.
> > 
> > Looks like a good first draft.
> 
> I don't think there is any such expected format(I checked some
> previous
> years accepted proposals). I believe if we clearly write the expected
> goal
> and the tentative approach to reach it, that would be okay for the
> proposal.

Looking at:
  https://gcc.gnu.org/wiki/SummerOfCode#Application
we don't have a specific format to be followed.

That said, I saw this 
  https://google.github.io/gsocguides/student/writing-a-proposal
which seems to have useful advice to prospective GSoC students.  In
particular, the "Elements of a Quality Proposal" lists various things
that in your current draft are missing, and which would strengthen your
proposal.  So I'd recommend that you (and other prospective GSoC
candidates) have a look at that.

[...snip...]

> > - in Example 2, maybe spell out why it's a leak - when does the
> > allocated buffer stop being referenceable?
> > 
> Explained. Please let me know if you feel it has any loose ends.

I think the leak is actually at line 8, when the "catch" clause ends. 
Isn't the buffer passed into the exception-state of the thread, and
becomes live during the "catch" clause, but stops being live at the end
of the catch clause?

> 
> > - you have a simple example of a false negative; is it possible to
> > give
> > a simple example of a false positive?  (I think "new" is meant to
> > raise
> > an exception if it fails, so a diagnostics about a NULL-deref on
> > unchecked new might be a false positive.  I'm not sure)
> > 
> I tried the following example:
> 
> #include <new>
> #include <iostream>
> using namespace std;
> int *p;
> int* alloc() {
>    return new int;
> }
> void free() {
>    delete p;
> }

FWIW please don't create a top-level function called "free" that isn't
the C stdlib's free, it's confusing!

> int main()
> {
>    try {
>      p = alloc();
>      free();
>    } catch(...) {
>    }
>    return 0;
> }
> Please, have a look here (https://godbolt.org/z/8WvoaP67n). I believe
> it is
> a false positive, I am not sure, please confirm.

It looks like one to me.  I had a look at -fdump-analyzer-exploded-
graph and the false positive seems to be associated with the edge with
the EH flag (to the catch handler).

[...snip...]

> 
> > - "sample example programs": for "sample" did you mean to write
> > "simple" here?
> > 
> By sample examples, I meant the test cases that shall be used to
> prove the
> correctness of the patches during the course.

Isn't "sample examples" a tautology, though?  (or, at least, my
interpretation of "sample" here makes it so, I think).

> 
> > - as well as understanding code, you'll need to understand data,
> > specifically getting a feel for the kinds of control flow graphs
> > that
> > the analyzer is receiving as inputs i.e. what the analyzer "sees"
> > when
> > the user inputs various C++ language constructs; what
> > interprocedural
> > vs intraprocedural raise/try/catch situations look like, etc.
> > 
> I am in the process to understand how the analyzer works. I believe I
> have
> just got a gist of the approach being used. The gimple graph has been
> processed in a Worklist manner. We analyze each statement and add
> predecessors/successors if there is some new information coming out
> of the
> analyzed statement. 

When we process a node in the worklist, we only ever add successor
nodes, recording the next <point, state> pairs.

> For example, In the memory leak examples discussed
> here, if at a statement I see a *new *expression, then I need to add
> all
> the nodes where this value can flow into, to find out a possible
> *free
> *expression
> to block the possible memory leak.

Right.  Or the first place where the value is no longer live, so that
we can report a leak there.

> In the case of interprocedural, I need to incorporate the effects of
> any
> function calls in between and see if it changes my analysis result or
> not.

Currently the analyzer has a "brute force" approach to interprocedural
analysis, and attempts to simulate the calls and returns in a fairly
direct way.  It's crude (and has exponential growth), but is reasonably
simple conceptually (or at least I think so).  The analyzer implements
setjmp/longjmp in a similar way, and exception-handling could be based
on that code.

There *is* some placeholder code to attempt to summarize the effects of
a whole function, but it doesn't work well and is disabled by default
(I hope to fix this in GCC 12).

> 
> Please, let me know if I am wrong somewhere.
> -Saloni

Hope this is helpful
Dave

Re: [GSoC-2021] Interested in project `Extend the static analysis pass`

[Saloni Garg]

On Thu, Apr 8, 2021 at 8:19 AM David Malcolm <dmalcolm@redhat.com> wrote:

> On Wed, 2021-04-07 at 01:59 +0530, Saloni Garg wrote:
> > Hi, apologies for the delayed reply. I was having some college
> > commitments.
> > On Wed, Mar 31, 2021 at 11:22 PM David Malcolm <dmalcolm@redhat.com>
> > wrote:
> >
> > > On Wed, 2021-03-31 at 21:41 +0530, Saloni Garg wrote:
> > > > On Tue, Mar 30, 2021 at 6:42 PM David Malcolm <
> > > > dmalcolm@redhat.com>
> > > > wrote:
> > > >
> > > > > On Tue, 2021-03-30 at 16:06 +0530, Saloni Garg wrote:
> > > > > > On Sun, Mar 28, 2021 at 8:03 PM David Malcolm <
> > > > > > dmalcolm@redhat.com>
> > > > > > wrote:
> > >
>
> [...snip...]
>
> > > > > Please do work on the formal proposal - without it we can't
> > > > > accept
> > > > > you
> > > > > as a GSoC student.  The window for submitting proposals opened
> > > > > yesterday, and I believe it closes in a couple of weeks, and
> > > > > you
> > > > > need
> > > > > to do that, so any experimentation you do now should really
> > > > > just be
> > > > > in
> > > > > support of writing a good proposal.  It would be a shame to not
> > > > > have a
> > > > > good prospective candidate because they didn't allow enough
> > > > > time to
> > > > > do
> > > > > the proper GSoC paperwork before the deadline.
> > > > >
> > > > Thanks for understanding. Here is an initial draft (
> > > >
> > > >
> > >
> > >
> https://docs.google.com/document/d/1inkkU5B55s_FOWRzUuf38s7XEet65kc0dW3yFn0yh1M/edit?usp=sharing
> > > > )
> > > > of my GSoC proposal. I am yet to fill in the missing blocks.
> > > > Please, let me know if you have any comments on the document
> > > > itself.
> > >
> > > Caveat: I'm not familiar with the expected format of such
> > > documents.
> > >
> > > Looks like a good first draft.
> >
> > I don't think there is any such expected format(I checked some
> > previous
> > years accepted proposals). I believe if we clearly write the expected
> > goal
> > and the tentative approach to reach it, that would be okay for the
> > proposal.
>
> Looking at:
>   https://gcc.gnu.org/wiki/SummerOfCode#Application
> we don't have a specific format to be followed.
>
> That said, I saw this
>   https://google.github.io/gsocguides/student/writing-a-proposal
> which seems to have useful advice to prospective GSoC students.  In
> particular, the "Elements of a Quality Proposal" lists various things
> that in your current draft are missing, and which would strengthen your
> proposal.  So I'd recommend that you (and other prospective GSoC
> candidates) have a look at that.
>
Added some new sections. Tried to explain them as well. There are some
things I am not clear about, so explicitly mentioned them and will add the
relevant explanations and present them in the later reports. Please let me
know if this sounds good to you and provide feedback as well.

>
> [...snip...]
>
> > > - in Example 2, maybe spell out why it's a leak - when does the
> > > allocated buffer stop being referenceable?
> > >
> > Explained. Please let me know if you feel it has any loose ends.
>
> I think the leak is actually at line 8, when the "catch" clause ends.
> Isn't the buffer passed into the exception-state of the thread, and
> becomes live during the "catch" clause, but stops being live at the end
> of the catch clause?
>
Yes, I understood your point and have added the same in the document as
well. The memory becomes unreferenced after the catch block ends so that is
basically the point where this leak started.

>
> >
> > > - you have a simple example of a false negative; is it possible to
> > > give
> > > a simple example of a false positive?  (I think "new" is meant to
> > > raise
> > > an exception if it fails, so a diagnostics about a NULL-deref on
> > > unchecked new might be a false positive.  I'm not sure)
> > >
> > I tried the following example:
> >
> > #include <new>
> > #include <iostream>
> > using namespace std;
> > int *p;
> > int* alloc() {
> >    return new int;
> > }
> > void free() {
> >    delete p;
> > }
>
> FWIW please don't create a top-level function called "free" that isn't
> the C stdlib's free, it's confusing!
>
Sorry, my bad renamed it to `myfree`.

>
> > int main()
> > {
> >    try {
> >      p = alloc();
> >      free();
> >    } catch(...) {
> >    }
> >    return 0;
> > }
> > Please, have a look here (https://godbolt.org/z/8WvoaP67n). I believe
> > it is
> > a false positive, I am not sure, please confirm.
>
> It looks like one to me.  I had a look at -fdump-analyzer-exploded-
> graph and the false positive seems to be associated with the edge with
> the EH flag (to the catch handler).
>
I have understood the exploded graph but not able to understand the `EH
flag` point you are making, so I will get back to you on this.

>
> [...snip...]
>
> >
> > > - "sample example programs": for "sample" did you mean to write
> > > "simple" here?
> > >
> > By sample examples, I meant the test cases that shall be used to
> > prove the
> > correctness of the patches during the course.
>
> Isn't "sample examples" a tautology, though?  (or, at least, my
> interpretation of "sample" here makes it so, I think).
>
yes, I guess I didn't frame that in words appropriately. But, yes I meant
the same as what you are saying.

>
> >
> > > - as well as understanding code, you'll need to understand data,
> > > specifically getting a feel for the kinds of control flow graphs
> > > that
> > > the analyzer is receiving as inputs i.e. what the analyzer "sees"
> > > when
> > > the user inputs various C++ language constructs; what
> > > interprocedural
> > > vs intraprocedural raise/try/catch situations look like, etc.
> > >
> > I am in the process to understand how the analyzer works. I believe I
> > have
> > just got a gist of the approach being used. The gimple graph has been
> > processed in a Worklist manner. We analyze each statement and add
> > predecessors/successors if there is some new information coming out
> > of the
> > analyzed statement.
>
> When we process a node in the worklist, we only ever add successor
> nodes, recording the next <point, state> pairs.
>
Yes. Right. Since this analysis is similar to dead variable analysis(Read
from the Internet) we only add successors.

>
> > For example, In the memory leak examples discussed
> > here, if at a statement I see a *new *expression, then I need to add
> > all
> > the nodes where this value can flow into, to find out a possible
> > *free
> > *expression
> > to block the possible memory leak.
>
> Right.  Or the first place where the value is no longer live, so that
> we can report a leak there.
>
Yes.

>
> > In the case of interprocedural, I need to incorporate the effects of
> > any
> > function calls in between and see if it changes my analysis result or
> > not.
>
> Currently the analyzer has a "brute force" approach to interprocedural
> analysis, and attempts to simulate the calls and returns in a fairly
> direct way.  It's crude (and has exponential growth), but is reasonably
> simple conceptually (or at least I think so).  The analyzer implements
> setjmp/longjmp in a similar way, and exception-handling could be based
> on that code.
>
Going through that already and your comments at the start of every data
structure defined are really helpful.

>
> There *is* some placeholder code to attempt to summarize the effects of
> a whole function, but it doesn't work well and is disabled by default
> (I hope to fix this in GCC 12).

>
> > Please, let me know if I am wrong somewhere.
> > -Saloni
>
> Hope this is helpful
> Dave
>
> Yes. It was.

- Saloni

Re: [GSoC-2021] Interested in project `Extend the static analysis pass`

[David Malcolm]

On Sat, 2021-04-10 at 21:18 +0530, Saloni Garg wrote:
> On Thu, Apr 8, 2021 at 8:19 AM David Malcolm <dmalcolm@redhat.com>
> wrote:
> 
> > On Wed, 2021-04-07 at 01:59 +0530, Saloni Garg wrote:

[...]

> > Looking at:
> >   https://gcc.gnu.org/wiki/SummerOfCode#Application
> > we don't have a specific format to be followed.
> > 
> > That said, I saw this
> >   https://google.github.io/gsocguides/student/writing-a-proposal
> > which seems to have useful advice to prospective GSoC students.  In
> > particular, the "Elements of a Quality Proposal" lists various
> > things
> > that in your current draft are missing, and which would strengthen
> > your
> > proposal.  So I'd recommend that you (and other prospective GSoC
> > candidates) have a look at that.
> > 
> Added some new sections. Tried to explain them as well. There are
> some
> things I am not clear about, so explicitly mentioned them and will
> add the
> relevant explanations and present them in the later reports. Please
> let me
> know if this sounds good to you and provide feedback as well.

The updated version looks a lot stronger.

That said, you haven't given details of your programming expertise - in
particular this project will require proficiency with C++, so a good
application would give evidence to the reader that you're already up-
to-speed on writing and debugging C++ (see the "Biographical
Information" section in the guide I linked to above for more info).


[...snip...]

> > FWIW please don't create a top-level function called "free" that
> > isn't
> > the C stdlib's free, it's confusing!
> > 
> Sorry, my bad renamed it to `myfree`.

Thanks!

> > 
> > > int main()
> > > {
> > >    try {
> > >      p = alloc();
> > >      free();
> > >    } catch(...) {
> > >    }
> > >    return 0;
> > > }
> > > Please, have a look here (https://godbolt.org/z/8WvoaP67n). I
> > > believe
> > > it is
> > > a false positive, I am not sure, please confirm.
> > 
> > It looks like one to me.  I had a look at -fdump-analyzer-exploded-
> > graph and the false positive seems to be associated with the edge
> > with
> > the EH flag (to the catch handler).
> > 
> I have understood the exploded graph but not able to understand the
> `EH
> flag` point you are making, so I will get back to you on this.

Edges in control flow graphs can have flags; see the various
DEF_EDGE_FLAG in gcc/cfg-flags.def in the source tree, and in
particular the "EH" flag.

These flags are visible in the analyzer's supergraph - they should
appear in the .dot dump files from the analyzer - so sometimes they're
difficult to see, depending on how GraphViz lays things out.  (FWIW I
use:
  https://github.com/jrfonseca/xdot.py
to view the .dot files; it's fast and convenient)

[...snip...]

> 
> > > 
> > 
> > Currently the analyzer has a "brute force" approach to
> > interprocedural
> > analysis, and attempts to simulate the calls and returns in a
> > fairly
> > direct way.  It's crude (and has exponential growth), but is
> > reasonably
> > simple conceptually (or at least I think so).  The analyzer
> > implements
> > setjmp/longjmp in a similar way, and exception-handling could be
> > based
> > on that code.
> > 
> Going through that already and your comments at the start of every
> data
> structure defined are really helpful.

Thanks!

> 
[...snip...]

Dave

Re: [GSoC-2021] Interested in project `Extend the static analysis pass`

[Saloni Garg]

On Sun, Apr 11, 2021 at 12:14 AM David Malcolm <dmalcolm@redhat.com> wrote:

> On Sat, 2021-04-10 at 21:18 +0530, Saloni Garg wrote:
> > On Thu, Apr 8, 2021 at 8:19 AM David Malcolm <dmalcolm@redhat.com>
> > wrote:
> >
> > > On Wed, 2021-04-07 at 01:59 +0530, Saloni Garg wrote:
>
> [...]
>
> > > Looking at:
> > >   https://gcc.gnu.org/wiki/SummerOfCode#Application
> > > we don't have a specific format to be followed.
> > >
> > > That said, I saw this
> > >   https://google.github.io/gsocguides/student/writing-a-proposal
> > > which seems to have useful advice to prospective GSoC students.  In
> > > particular, the "Elements of a Quality Proposal" lists various
> > > things
> > > that in your current draft are missing, and which would strengthen
> > > your
> > > proposal.  So I'd recommend that you (and other prospective GSoC
> > > candidates) have a look at that.
> > >
> > Added some new sections. Tried to explain them as well. There are
> > some
> > things I am not clear about, so explicitly mentioned them and will
> > add the
> > relevant explanations and present them in the later reports. Please
> > let me
> > know if this sounds good to you and provide feedback as well.
>
> The updated version looks a lot stronger.
>
Hi, Thanks for the quick feedback.

>
> That said, you haven't given details of your programming expertise - in
> particular this project will require proficiency with C++, so a good
> application would give evidence to the reader that you're already up-
> to-speed on writing and debugging C++ (see the "Biographical
> Information" section in the guide I linked to above for more info).
>
Apologies, but I am a beginner in this area of compilers and static
analysis. I already know some C++ coding which I have used mostly in
Competitive coding competitions. I have been following this(
https://www.cse.iitk.ac.in/users/karkare/Courses/cs618/) course to
understand the nuances of the static analysis. I am confident that I can
write the C++ code that is required here and know how to use tools like
GDB, Valgrind to debug the C++ codes, but I don't have any good projects to
prove that right now. My college got stopped due to COVID-19 and hasn't
started yet properly, so I have been trying to learn most of the things
online only.
I hope you understand.

- Saloni

> [...snip...]
>
> > > FWIW please don't create a top-level function called "free" that
> > > isn't
> > > the C stdlib's free, it's confusing!
> > >
> > Sorry, my bad renamed it to `myfree`.
>
> Thanks!
>
> > >
> > > > int main()
> > > > {
> > > >    try {
> > > >      p = alloc();
> > > >      free();
> > > >    } catch(...) {
> > > >    }
> > > >    return 0;
> > > > }
> > > > Please, have a look here (https://godbolt.org/z/8WvoaP67n). I
> > > > believe
> > > > it is
> > > > a false positive, I am not sure, please confirm.
> > >
> > > It looks like one to me.  I had a look at -fdump-analyzer-exploded-
> > > graph and the false positive seems to be associated with the edge
> > > with
> > > the EH flag (to the catch handler).
> > >
> > I have understood the exploded graph but not able to understand the
> > `EH
> > flag` point you are making, so I will get back to you on this.
>
> Edges in control flow graphs can have flags; see the various
> DEF_EDGE_FLAG in gcc/cfg-flags.def in the source tree, and in
> particular the "EH" flag.
>
> These flags are visible in the analyzer's supergraph - they should
> appear in the .dot dump files from the analyzer - so sometimes they're
> difficult to see, depending on how GraphViz lays things out.  (FWIW I
> use:
>   https://github.com/jrfonseca/xdot.py
> to view the .dot files; it's fast and convenient)
>
> [...snip...]
>
> >
> > > >
> > >
> > > Currently the analyzer has a "brute force" approach to
> > > interprocedural
> > > analysis, and attempts to simulate the calls and returns in a
> > > fairly
> > > direct way.  It's crude (and has exponential growth), but is
> > > reasonably
> > > simple conceptually (or at least I think so).  The analyzer
> > > implements
> > > setjmp/longjmp in a similar way, and exception-handling could be
> > > based
> > > on that code.
> > >
> > Going through that already and your comments at the start of every
> > data
> > structure defined are really helpful.
>
> Thanks!
>
> >
> [...snip...]
>
> Dave
>
>

Re: [GSoC-2021] Interested in project `Extend the static analysis pass`

[David Malcolm]

On Sun, 2021-04-11 at 17:06 +0530, Saloni Garg wrote:
> On Sun, Apr 11, 2021 at 12:14 AM David Malcolm <dmalcolm@redhat.com>
> wrote:
> 
> > On Sat, 2021-04-10 at 21:18 +0530, Saloni Garg wrote:
> > > On Thu, Apr 8, 2021 at 8:19 AM David Malcolm
> > > <dmalcolm@redhat.com>
> > > wrote:
> > > 
> > > > On Wed, 2021-04-07 at 01:59 +0530, Saloni Garg wrote:
> > 
> > [...]
> > 
> > > > Looking at:
> > > >   https://gcc.gnu.org/wiki/SummerOfCode#Application
> > > > we don't have a specific format to be followed.
> > > > 
> > > > That said, I saw this
> > > >     
> > > > https://google.github.io/gsocguides/student/writing-a-proposal
> > > > which seems to have useful advice to prospective GSoC
> > > > students.  In
> > > > particular, the "Elements of a Quality Proposal" lists various
> > > > things
> > > > that in your current draft are missing, and which would
> > > > strengthen
> > > > your
> > > > proposal.  So I'd recommend that you (and other prospective
> > > > GSoC
> > > > candidates) have a look at that.
> > > > 
> > > Added some new sections. Tried to explain them as well. There are
> > > some
> > > things I am not clear about, so explicitly mentioned them and
> > > will
> > > add the
> > > relevant explanations and present them in the later reports.
> > > Please
> > > let me
> > > know if this sounds good to you and provide feedback as well.
> > 
> > The updated version looks a lot stronger.
> > 
> Hi, Thanks for the quick feedback.
> 
> > 
> > That said, you haven't given details of your programming expertise
> > - in
> > particular this project will require proficiency with C++, so a
> > good
> > application would give evidence to the reader that you're already
> > up-
> > to-speed on writing and debugging C++ (see the "Biographical
> > Information" section in the guide I linked to above for more info).
> > 
> Apologies, but I am a beginner in this area of compilers and static
> analysis. I already know some C++ coding which I have used mostly in
> Competitive coding competitions. I have been following this(
> https://www.cse.iitk.ac.in/users/karkare/Courses/cs618/) course to
> understand the nuances of the static analysis. I am confident that I
> can
> write the C++ code that is required here and know how to use tools
> like
> GDB, Valgrind to debug the C++ codes, 

Your proposal would benefit from including something like the above.

We're not expecting Bjarne Stroustrup levels of competence in C++,
especially considering that you are all students - but we need some
ability in C++... which you may already have, it's hard for me to tell
as the current draft proposal is written.  Part of the point of GSoC is
to learn, but to learn about the specifics of the FLOSS project you
apply to [1], rather than the implementation language.

> but I don't have any good projects to
> prove that right now. My college got stopped due to COVID-19 and
> hasn't
> started yet properly, so I have been trying to learn most of the
> things
> online only.
> I hope you understand.

Indeed.


Hope this is helpful; good luck (the deadline to apply is fast
approaching)

Dave

[1] and to learn about what "real" programming is like (for some
definition of "real"), as opposed to the rather artifical programming
that university coursework tends to be like.  For example, GCC has 30+
years of legacy code to maintain, full of weird specialcases and dark
corners, with dozens of target configurations - we can't just rewrite
it all, or at least, not quickly :)

Re: [GSoC-2021] Interested in project `Extend the static analysis pass`

[Saloni Garg]

On Mon, Apr 12, 2021 at 7:35 PM David Malcolm <dmalcolm@redhat.com> wrote:

> On Sun, 2021-04-11 at 17:06 +0530, Saloni Garg wrote:
> > On Sun, Apr 11, 2021 at 12:14 AM David Malcolm <dmalcolm@redhat.com>
> > wrote:
> >
> > > On Sat, 2021-04-10 at 21:18 +0530, Saloni Garg wrote:
> > > > On Thu, Apr 8, 2021 at 8:19 AM David Malcolm
> > > > <dmalcolm@redhat.com>
> > > > wrote:
> > > >
> > > > > On Wed, 2021-04-07 at 01:59 +0530, Saloni Garg wrote:
> > >
> > > [...]
> > >
> > > > > Looking at:
> > > > >   https://gcc.gnu.org/wiki/SummerOfCode#Application
> > > > > we don't have a specific format to be followed.
> > > > >
> > > > > That said, I saw this
> > > > >
> > > > > https://google.github.io/gsocguides/student/writing-a-proposal
> > > > > which seems to have useful advice to prospective GSoC
> > > > > students.  In
> > > > > particular, the "Elements of a Quality Proposal" lists various
> > > > > things
> > > > > that in your current draft are missing, and which would
> > > > > strengthen
> > > > > your
> > > > > proposal.  So I'd recommend that you (and other prospective
> > > > > GSoC
> > > > > candidates) have a look at that.
> > > > >
> > > > Added some new sections. Tried to explain them as well. There are
> > > > some
> > > > things I am not clear about, so explicitly mentioned them and
> > > > will
> > > > add the
> > > > relevant explanations and present them in the later reports.
> > > > Please
> > > > let me
> > > > know if this sounds good to you and provide feedback as well.
> > >
> > > The updated version looks a lot stronger.
> > >
> > Hi, Thanks for the quick feedback.
> >
> > >
> > > That said, you haven't given details of your programming expertise
> > > - in
> > > particular this project will require proficiency with C++, so a
> > > good
> > > application would give evidence to the reader that you're already
> > > up-
> > > to-speed on writing and debugging C++ (see the "Biographical
> > > Information" section in the guide I linked to above for more info).
> > >
> > Apologies, but I am a beginner in this area of compilers and static
> > analysis. I already know some C++ coding which I have used mostly in
> > Competitive coding competitions. I have been following this(
> > https://www.cse.iitk.ac.in/users/karkare/Courses/cs618/) course to
> > understand the nuances of the static analysis. I am confident that I
> > can
> > write the C++ code that is required here and know how to use tools
> > like
> > GDB, Valgrind to debug the C++ codes,
>
> Your proposal would benefit from including something like the above.
>
> We're not expecting Bjarne Stroustrup levels of competence in C++,
> especially considering that you are all students - but we need some
> ability in C++... which you may already have, it's hard for me to tell
> as the current draft proposal is written.  Part of the point of GSoC is
> to learn, but to learn about the specifics of the FLOSS project you
> apply to [1], rather than the implementation language.
>
Yes, I have added the details related to C++ in the document.

>
> > but I don't have any good projects to
> > prove that right now. My college got stopped due to COVID-19 and
> > hasn't
> > started yet properly, so I have been trying to learn most of the
> > things
> > online only.
> > I hope you understand.
>
> Indeed.
>
>
> Hope this is helpful; good luck (the deadline to apply is fast
> approaching)
>
Thanks, I have submitted the final proposal. Now switching on to the coding
part.

- Saloni

> [...snip...]