Re: progress update after initial GSoC virtual meetup

[David Malcolm <dmalcolm@redhat.com>]

On Sun, 2021-05-30 at 20:38 +0530, Ankur Saini wrote:
> hello 

Hi Ankur, sorry about the delayed reply (it was a long weekend here in
the US)

> I was successfully able to build gcc with bootstrapping disabled and
> using xgcc directly from the build directory instead ( reducing the
> overall build time a lot, although it still takes about half an hour to
> build but it’s much faster than before ). 

Excellent.


> Also I was also able to run one single test on the built compiler.

Great.

> 
> Is there anything else I should be knowing to aid in development or
> should we start planing and preparing towards the project so that we
> can have a head start during coding phase ?

I tried brainstorming "what does a new contributor to GCC's analyzer
need to be able to do"; here's what I came up with:

- 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.

- 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.

- 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.

- 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.

- 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 hope all the above makes sense.  Don't hesitate to ask questions;
finding things out is the whole point of this part of the GSoC
schedule.

Can anyone think of something else that's worth sorting out in this
preliminary phase?

I don't think you're meant to be spending more than an hour or so a
week in this preliminary phase until the coding period officially
starts on Monday 7th.

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.  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.

Hope this is helpful

Dave