AIM for today : - update the call_string to store a vector of pair of supernode* instead of pointer to it - create a typdef to give a meaning full name to these " pair of supernode* “ - send the patch list to gcc-patches mailing list - add the example program I created to the GCC tests
— PROGRESS : - I successfully changed the entire call string representation again to keep track of "auto_vec<element_t> m_elements;” from "auto_vec<const std::pair<const supernode *,const supernode *>*> m_supernodes;” - while doing so, one hurdle I found was to change "hashval_t hash () const;”, function of which I quite didn’t understood properly, but looking at source, it looked like it just needed some value ( integer or pointer ) to add to ‘hstate’ and ' m_elements’ was neither a pointer nor an integer so I instead added pointer to callee supernode ( “second” of the m_elements ) to the ‘hstate’ for now. - for the callstring patch, I created a patch file ( using git format-patch ) and sent it to patches mailing list (via git send email ) and CCed my mentor. Although I received a positive reply from the command log (git send email) saying the mail was sent , I didn’t received that mail ( being subscribed to the patches list ) regarding the same ( I sent that just before sending this mail ). The mail should be sent from arse...@sourceware.org <mailto:arse...@sourceware.org> - I also added the example I was using to test the analyzer to regression tests as "gcc/testsuite/gcc.dg/analyzer/call-via-fnptr.c”. STATUS AT THE END OF THE DAY :- - update the call_string to store a vector of pair of supernode* instead of pointer to it ( done ) - create a typdef to give a meaning full name to these " pair of supernode* “ ( done ) - send the patch list to gcc-patches mailing list ( done ? ) - add the example program I created to the GCC tests ( done ) > On 07-Jul-2021, at 8:07 PM, David Malcolm <dmalc...@redhat.com> wrote: > > On Wed, 2021-07-07 at 19:22 +0530, Ankur Saini wrote: […] >> >> also regarding the ChangeLog >> >> how exactly does one update the changelog, does it get updated with >> the commit messages or do one have to update it manually ? >> >> I found and read this doc ( >> https://gcc.gnu.org/codingconventions.html#ChangeLogs >> <https://gcc.gnu.org/codingconventions.html#ChangeLogs> < >> https://gcc.gnu.org/codingconventions.html#ChangeLogs >> <https://gcc.gnu.org/codingconventions.html#ChangeLogs>>) about the >> same which says that “ ChangeLog entries are part of git commit >> messages and are automatically put into a corresponding ChangeLog >> file “. But when I pushed the commits which looks properly formatted >> to me, I was not able to see the changes reflecting back in >> gcc/analyzer/changelog . > > There's a script that runs every 24 hours on the main branches which > looks at the commits that have happened since the script last run, > tries to parse the commit messages to find ChangeLog entries, and adds > a commit adding those entries to the ChangeLog files. I don't think it > runs on user branches. > > We require ChangeLog entries when merging code to trunk and the release > branches, but it may be overkill for a personal development branch. > When I'm working on a new feature, I only bother writing the ChangeLog > when a patch is nearly ready for trunk, since often I find that patches > need a fair amount of reworking as I test them. make sense > > The call_string patch looks nearly ready for trunk, and thus probably > needs a ChangeLog, but the ipa-devirt work is going to be more > experimental for now, so I wouldn't bother with ChangeLogs on it yet > until it's clearer what the changes will be and how to land them into > trunk. > > I'm currently working on implementing detection of uses of > uninitialized values in -fanalyzer for GCC 12, and so I'm making my own > changes (mostly to region-model/store/constraint-manager). Hopefully > we won't get too many clashes between our changes. Ok , I will keep that in mind. Thank you - Ankur
