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