On Tue, Mar 30, 2021 at 6:42 PM David Malcolm <dmalc...@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 <dmalc...@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
