progress update after initial GSoC virtual meetup

[Ankur Saini]

> On 01-Jun-2021, at 6:38 PM, David Malcolm <dmalcolm@redhat.com> wrote:
> 
> - able to build the analyzer from source *quickly*, for hacking on the
> code.  i.e. with --disable-bootstrap.  We want to minimize the time it
> takes to, say, hack in a print statement into a single .cc file in the
> analyzer subdirectory, rebuild, and rerun.   With bootstrapping
> disabled, if you run "make -jsome-number-of-cores" from the build
> directory's "gcc" subdirectory, it should merely rebuild the .o file
> for the .cc you touched, and do some relinking (and rerun the
> selftests); hopefully such an edit should take less than a minute
> before you're able to run the code and see the results.
> 
> It sounds like you're close to being able to do that.
> 
> (FWIW I tend to use gdb rather than putting in print statements, I tend
> to hack in gcc_unreachable into conditions that I hope are being hit,
> so that execution will stop at that point in gdb if my assumptions are
> correct, and then I can print things, inject calls, etc in gdb)
> 
> - able to build the analyzer with a full bootstrap (--enable-bootstrap
> is the default) and running the regression test suites ("make check -
> jnumber-of-cores"),  On the fastest box I have this (64 cores, 128 GB
> ram) this takes about 45 minutes to do the build and about 45 minutes
> to do the testsuites; it used to take up to three hours total when I
> was running it on a laptop (and thus was a major pain as it's no fun to
> have a hot noisy laptop for several hours).  Maybe it's best to have an
> account on the GCC compile farm for this:
>  https://gcc.gnu.org/wiki/CompileFarm
> IIRC you already have such an account.  It might be worth trying out a
> full bootstrap and testsuite run on one of the powerful machines in the
> farm.   I tend to use "screen" in case my ssh connection drops during
> through a build, so that losing the ssh connection doesn't kill the
> build.

I tried this, and it’s awesome :D , I was able to complete the either bootstrap build on one of the powerful machine there with almost similar time to that of what my laptop takes to build with bootstrap disabled.

> 
> - able to step through the code in the debugger.  IIRC you've already
> been doing that.

> 
> - copyright assignment paperwork to the FSF.  IIRC you've already done
> that.

done

> 
> - ability to run just a single test in the testsuite, rather than the
> whole lot (so that you can easily develop new tests without having to
> run everything each time you make an edit to a test).  As you say
> above, you've done that.

done

> 
> - the analyzer has testcases for C, C++ and Fortran, so you might want
> to figure out the argument you need for --enable-languages= when
> configuring GCC to enable those languages (but probably no others when
> hacking, to speed of rebuilding GCC).  Obviously you'll need C++, as
> C++ support is the point of your project.

Right now I only enable C and C++ when building.

> 
> - it might be good to create a personal branch on the gcc git
> repository that you can push your work to.  I'm in two minds about
> this, in that ideally you'd just commit your work to trunk once each
> patch is approved, but maybe it's good to have a public place as a
> backup of the "under development" stuff?  Also, at some point we want
> you to be pushing changes to the trunk, so we'll want your account to
> be able to do that.

I already did that when I was fiddling around with the source code and track my changes seperately

> 
> If you're *really* eager to start, you might want to look at 
>  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100546
> This is a case where the analyzer "sees" a call through a function
> pointer, and, despite figuring out what the function pointer actually
> points to, entirely fails to properly handle the call, since the

> supergraph and engine.cc code is looking at the static callgraph, and
> needs work to handle such calls through function pointers.  I started
> debugging this a couple of weeks ago, and realized it has a *lot* of
> similarities to the vtable case, so thought I might leave it so you can
> have a go at it once the project starts properly.

yes, looking at exploded graph, the analyzer is not able to understand the call to function “noReturn()” when called via a function pointer ( noReturnPtr.0_1 ("<source>”); ) at all. I would be looking into it and will report back as soon as I find something useful.

also, should I prefer discussing about this bug here( gcc mailing list) or on the bugzilla itself ?

>  That said, before
> the 7th you're meant to be focusing on schoolwork, I think, so we
> really ought to be merely just sorting out accounts, ensuring your
> coding environment is set up, etc.

ok

> 
> Hope this is helpful

Thanks,

- Ankur