On Wed, 2021-07-14 at 22:41 +0530, Ankur Saini wrote: > CURRENT STATUS OF PROJECT: > > - The analyzer can now sucessfully detect and analyze function calls > that > doesn't have a callgraph edge ( like a call via function pointer )
Excellent. > > - A weird indentation problem caused by my text editor pointed out in > one of the previous mails ( > https://gcc.gnu.org/pipermail/gcc/2021-July/236747.html) > , that despite being fixed, still messed up indentation in all of > the changes > I have done so far. > > - the analyser can still not detect a call via vtable pointer > > --- > AIM FOR TODAY: > > - Complete the first evaluation of GSoC > - Fix the indentation errors my generated by my editor on changes > done till now > - Add the tests to regress testing > - Create a ChangeLog for the next patch > - Attach the patch with this mail > - Layout a new region subclass for vtables ( getting ready for next > patch ) > > --- > PROGRESS : > > - To fix the indentaion problem, I simply created a diff and fixed > all of them > manually. I also found and read a doc regarding coding convention > used by GCC > (https://gcc.gnu.org/codingconventions.html) and refactored the > chagnes and > changelog to follow this. Great. > > - After that I branched out and layed out foundation for next update > and started created a subclass region for vtable ( vtable_region ), > which > currently do nothing > > - After that in order to give some final finishing touches to > previous changes, > I created chagnelog and added 2 more tests to the analyzer > testsuite as > follows : > > 1. (function-ptr-4.c) > ``` [...snip...] > ``` > (godbolt link <https://godbolt.org/z/1o3cK4aYo>) Looks promising. Does this work in DejaGnu? The directive: /* { dg-warning "double-‘free’ of ‘int_ptr’" } */ might need changing to: /* { dg-warning "double-'free' of 'int_ptr'" } */ i.e. fixing the quotes to use ASCII ' rather than ‘ and ’. It's worth running the testcases with LANG=C when generating the expected outputs. IIRC this is done automatically by the various "make check-*". > > 2. ( pr100546.c < > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100546>) > ``` > #include <stdio.h> > #include <cstdlib.h> > > static void noReturn(const char *str) __attribute__((noreturn)); > static void noReturn(const char *str) { > printf("%s\n", str); > exit(1); > } > > void (*noReturnPtr)(const char *str) = &noReturn; > > int main(int argc, char **argv) { > char *str = 0; > if (!str) > noReturnPtr(__FILE__); > return printf("%c\n", *str); > } > ``` > (godbolt link <https://godbolt.org/z/aWfW51se3>) > > - But at the time of testing ( command used > was `make check-gcc RUNTESTFLAGS="-v -v analyzer.exp=pr100546.c"`), > both of > them failed unexpectedly with Segmentation fault at the call > > - From further inspection, I found out that this is due > "-fanalyzer-call-summaries" option, which looks like activats call > summaries > > - I would look into this in more details ( with gdb ) tomorrow, right > now > my guess is that this is either due too the changes I did in state- > purge.cc > or is a call-summary related problem ( I remember it not being > perfetly implemented right now). I'm not proud of the call summary code, so that may well be the problem. Are you able to use gdb on the analyzer? It ought to be fairly painless to identify where a segfault is happening, so let me know if you're running into any problems with that. > > --- > STATUS AT THE END OF THE DAY :- > > - Complete the first evaluation of GSoC ( done ) > - Fix the indentation errors my generated by my editor on changes > done till now ( done ) > - Layout a new region subclass for vtables ( done ) > - Create a ChangeLog for the next patch ( done ) > - Add the tests to regress testing ( pending ) > - Attach the patch with this mail ( pending ) > > --- > HOUR-O-METER :- > no. of hours spent on the project today : 4 hours > Grand total (by the end of 14th July 2021): 195 hours Thanks for estimating the time you're spending on the project. I'm wondering what the "grand total" above is covering: are you counting the application and "community bonding" periods, or just the "coding" period. Do you have more of a per-week breakdown for the coding period? The guidance from Google is that students are expected to spend roughtly 175 hours total in the coding period of a GSoC 2021 project, so I'm a bit alarmed if you've already spent more than that time when we're only halfway through. Dave
