Re: daily report on extending static analyzer project [GSoC]

2021-08-06 Thread Ankur Saini via Gcc
> On 06-Aug-2021, at 4:39 AM, David Malcolm wrote: > > On Thu, 2021-08-05 at 20:27 +0530, Ankur Saini wrote: >> >> >>> On 05-Aug-2021, at 4:56 AM, David Malcolm >>> wrote: >>> >>> On Wed, 2021-08-04 at 21:32 +0530, Ankur Saini wrote: >>> >>> [...snip...] - From observation, a t

Re: daily report on extending static analyzer project [GSoC]

2021-08-05 Thread David Malcolm via Gcc
On Thu, 2021-08-05 at 20:27 +0530, Ankur Saini wrote: > > > > On 05-Aug-2021, at 4:56 AM, David Malcolm > > wrote: > > > > On Wed, 2021-08-04 at 21:32 +0530, Ankur Saini wrote: > > > > [...snip...] > > > > > > - From observation, a typical vfunc call that isn't devirtualised > > > by > > > th

Re: daily report on extending static analyzer project [GSoC]

2021-08-05 Thread Ankur Saini via Gcc
> On 05-Aug-2021, at 4:56 AM, David Malcolm wrote: > > On Wed, 2021-08-04 at 21:32 +0530, Ankur Saini wrote: > > [...snip...] >> >> - From observation, a typical vfunc call that isn't devirtualised by >> the compiler's front end looks something like this >> "OBJ_TYPE_REF(_2;(struct A)a_ptr_

Re: daily report on extending static analyzer project [GSoC]

2021-08-04 Thread David Malcolm via Gcc
On Wed, 2021-08-04 at 21:32 +0530, Ankur Saini wrote: [...snip...] > > - From observation, a typical vfunc call that isn't devirtualised by > the compiler's front end looks something like this > "OBJ_TYPE_REF(_2;(struct A)a_ptr_5(D)->0) (a_ptr_5(D))" > where "a_ptr_5(D)" is pointer that is being

Re: daily report on extending static analyzer project [GSoC]

2021-08-04 Thread Ankur Saini via Gcc
AIM for today: - Extract out the pointer that is being used to call the vfunc from the current region. - Search it's regions to find out which subclass the pointer is actually pointing to. - Make use of this information to filter out one most probable call to function out of all of the possibl

Re: daily report on extending static analyzer project [GSoC]

2021-08-03 Thread Ankur Saini via Gcc
AIM: - Transfer the vfunc handling code to region_model::get_fndecl_for_call () - Filter out a possible targets of a polymorphic call to only one most porbable target --- PROGRESS : - I decided to transfer the code of detecting virtual call to region_model::get_fndecl_for_call () so that the

Re: daily report on extending static analyzer project [GSoC]

2021-07-30 Thread David Malcolm via Gcc
On Fri, 2021-07-30 at 18:11 +0530, Ankur Saini wrote: > > > > On 30-Jul-2021, at 5:35 AM, David Malcolm > > wrote: > > > > On Thu, 2021-07-29 at 18:20 +0530, Ankur Saini wrote: [..snip...] > > > > > > > > > @@ -1242,6 +1243,17 @@ exploded_node::on_stmt (exploded_graph &eg, > > > unk

Re: daily report on extending static analyzer project [GSoC]

2021-07-29 Thread David Malcolm via Gcc
On Thu, 2021-07-29 at 18:20 +0530, Ankur Saini wrote: > I have attached the patches(one is the updated version of previous > patch to > detect calls via function pointers) of the changed done to make the > analyzer > understand the calls to virtual functions for initial review. > > 1. I decided

Re: daily report on extending static analyzer project [GSoC]

2021-07-29 Thread Ankur Saini via Gcc
I have attached the patches(one is the updated version of previous patch to detect calls via function pointers) of the changed done to make the analyzer understand the calls to virtual functions for initial review. 1. I decided to make a dedicated function to create enodes and eedges for the d

Re: daily report on extending static analyzer project [GSoC]

2021-07-28 Thread Ankur Saini via Gcc
AIM For Today: - Make the anlalyzer evaluate the vfunc calls by creating enodes and eedges representing the call. - Make the analyzer not treat such calls as call to "unknown function" --- PROGRESS : - After the analyzer sucessfully found which funcitons to call ( thanks to functions fr

Re: daily report on extending static analyzer project [GSoC]

2021-07-27 Thread Ankur Saini via Gcc
sorry for lack of updates recently, most of the time was consumed in exploring GCC's devirtualiser and experimenting with some approaches, and didn’t got enough content out everyday for a daily-report. AIM: - get the analyzer figure out which function to call when a vritual function is called

Re: daily report on extending static analyzer project [GSoC]

2021-07-24 Thread Ankur Saini via Gcc
AIM FOR TODAY: - Send the callstring patch to the patches list after sucessfull bootstrap and regress test - Create some basic examples to see how virtual function are being called - Layout a basic `vtable_region : public region` subclass to store vtables found till now --- PROGRESS : - I se

Re: daily report on extending static analyzer project [GSoC]

2021-07-22 Thread David Malcolm via Gcc
On Thu, 2021-07-22 at 22:40 +0530, Ankur Saini wrote: > AIM FOR TODAY: > > - Add custom edge info to the eedges created for dynamically > discovered calls > - Add the custom events to be showing in diagnostics > - update call_event and return_event to also work for the cases where > there is no u

Re: daily report on extending static analyzer project [GSoC]

2021-07-22 Thread David Malcolm via Gcc
On Wed, 2021-07-21 at 21:44 +0530, Ankur Saini wrote: > > > > On 17-Jul-2021, at 2:57 AM, David Malcolm > > wrote: > > > > On Fri, 2021-07-16 at 21:04 +0530, Ankur Saini wrote: > > > > > > > > > > On 15-Jul-2021, at 4:53 AM, David Malcolm > > > > wrote: > > > > > > > > On Wed, 2021-07-14 at

Re: daily report on extending static analyzer project [GSoC]

2021-07-22 Thread Ankur Saini via Gcc
AIM FOR TODAY: - Add custom edge info to the eedges created for dynamically discovered calls - Add the custom events to be showing in diagnostics - update call_event and return_event to also work for the cases where there is no underlying superedge representing the call --- PROGRESS : - I cre

Re: daily report on extending static analyzer project [GSoC]

2021-07-21 Thread Ankur Saini via Gcc
> On 17-Jul-2021, at 2:57 AM, David Malcolm wrote: > > On Fri, 2021-07-16 at 21:04 +0530, Ankur Saini wrote: >> >> >>> On 15-Jul-2021, at 4:53 AM, David Malcolm >>> wrote: >>> >>> On Wed, 2021-07-14 at 22:41 +0530, Ankur Saini wrote: >>> >>> > > [...snip...] > >>> 2. ( pr

Re: daily report on extending static analyzer project [GSoC]

2021-07-16 Thread David Malcolm via Gcc
On Fri, 2021-07-16 at 21:04 +0530, Ankur Saini wrote: > > > > On 15-Jul-2021, at 4:53 AM, David Malcolm > > wrote: > > > > On Wed, 2021-07-14 at 22:41 +0530, Ankur Saini wrote: > > > > [...snip...] > > > > > > > >   2. ( pr100546.c <   > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1

Re: daily report on extending static analyzer project [GSoC]

2021-07-16 Thread Ankur Saini via Gcc
> On 15-Jul-2021, at 4:53 AM, David Malcolm wrote: > > 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

Re: daily report on extending static analyzer project [GSoC]

2021-07-14 Thread David Malcolm via Gcc
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 te

Re: daily report on extending static analyzer project [GSoC]

2021-07-14 Thread David Malcolm via Gcc
On Mon, 2021-07-12 at 22:07 +0530, Ankur Saini wrote: > > > > On 11-Jul-2021, at 11:19 PM, David Malcolm > > wrote: > > > > On Sat, 2021-07-10 at 21:27 +0530, Ankur Saini wrote: [...] > > > > > > - for the callstring patch, I created a patch file ( using git > > > format- > > > patch ) and se

Re: daily report on extending static analyzer project [GSoC]

2021-07-14 Thread Ankur Saini via Gcc
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 ) - A weird indentation problem caused by my text editor pointed out in one of the previous mails (https://gcc.gnu.org/piper

Re: daily report on extending static analyzer project [GSoC]

2021-07-12 Thread Ankur Saini via Gcc
> > On 11-Jul-2021, at 11:19 PM, David Malcolm wrote: > > On Sat, 2021-07-10 at 21:27 +0530, Ankur Saini wrote: >> 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 " pai

Re: daily report on extending static analyzer project [GSoC]

2021-07-11 Thread David Malcolm via Gcc
On Sun, 2021-07-11 at 22:31 +0530, Ankur Saini wrote: > AIM for today : > > - get "state_purge_per_ssa_name::process_point () “ to  go from the > “return" supernode to the “call” supernode. > - fix bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100546 < > https://gcc.gnu.org/bugzilla/show_bug.c

Re: daily report on extending static analyzer project [GSoC]

2021-07-11 Thread David Malcolm via Gcc
On Sat, 2021-07-10 at 21:27 +0530, Ankur Saini wrote: > 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

Re: daily report on extending static analyzer project [GSoC]

2021-07-11 Thread Ankur Saini via Gcc
AIM for today : - get "state_purge_per_ssa_name::process_point () “ to go from the “return" supernode to the “call” supernode. - fix bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100546 in the process - test and observe the effect of ch

Re: daily report on extending static analyzer project [GSoC]

2021-07-10 Thread Ankur Saini via Gcc
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 — PROG

Re: daily report on extending static analyzer project [GSoC]

2021-07-07 Thread David Malcolm via Gcc
On Wed, 2021-07-07 at 19:22 +0530, Ankur Saini wrote: > > > > On 07-Jul-2021, at 4:16 AM, David Malcolm > > wrote: > > > > On Sat, 2021-07-03 at 20:07 +0530, Ankur Saini wrote: > > > AIM for today : > > > > > > - update the call_stack to track something else other than > > > supergraph > > >

Re: daily report on extending static analyzer project [GSoC]

2021-07-07 Thread Ankur Saini via Gcc
> On 07-Jul-2021, at 4:16 AM, David Malcolm wrote: > > On Sat, 2021-07-03 at 20:07 +0530, Ankur Saini wrote: >> AIM for today : >> >> - update the call_stack to track something else other than supergraph >> edges >> >> — >> >> PROGRESS : >> >> - After some brainstorming about tracking the

Re: daily report on extending static analyzer project [GSoC]

2021-07-06 Thread David Malcolm via Gcc
On Mon, 2021-07-05 at 21:45 +0530, Ankur Saini wrote: > I forgot to send the daily report yesterday, so this one covers the > work done on both days > > AIM : > > - make the analyzer call the function with the updated call-string > representation ( even the ones that doesn’t have a superedge ) >

Re: daily report on extending static analyzer project [GSoC]

2021-07-06 Thread David Malcolm via Gcc
On Tue, 2021-07-06 at 18:46 -0400, David Malcolm wrote: > On Sat, 2021-07-03 at 20:07 +0530, Ankur Saini wrote: > > AIM for today : > > > > - update the call_stack to track something else other than > > supergraph > > edges > > > > — > > > > PROGRESS : > > > > - After some brainstorming about

Re: daily report on extending static analyzer project [GSoC]

2021-07-06 Thread David Malcolm via Gcc
On Sat, 2021-07-03 at 20:07 +0530, Ankur Saini wrote: > AIM for today : > > - update the call_stack to track something else other than supergraph > edges > > — > > PROGRESS : > > - After some brainstorming about tracking the callstack, I think one > better way to track the call stack is to kee

Re: daily report on extending static analyzer project [GSoC]

2021-07-05 Thread Ankur Saini via Gcc
I forgot to send the daily report yesterday, so this one covers the work done on both days AIM : - make the analyzer call the function with the updated call-string representation ( even the ones that doesn’t have a superedge ) - make the analyzer figure out the point of return from the functio

Re: daily report on extending static analyzer project [GSoC]

2021-07-03 Thread Ankur Saini via Gcc
AIM for today : - update the call_stack to track something else other than supergraph edges — PROGRESS : - After some brainstorming about tracking the callstack, I think one better way to track the call stack is to keep track of source and destination of the call instead of supperedges repre

Re: daily report on extending static analyzer project [GSoC]

2021-07-02 Thread Ankur Saini via Gcc
AIM for today : - find and try alternative to make the analyser return from the function - if failed to find any worthy alternative then start changing the implementation of call_string to track gcalls* instead of return_edges — PROGRESS : - I initially tried to look for some workarounds to m

Re: daily report on extending static analyzer project [GSoC]

2021-06-30 Thread David Malcolm via Gcc
On Wed, 2021-06-30 at 21:39 +0530, Ankur Saini wrote: > > > > On 30-Jun-2021, at 1:23 AM, David Malcolm > > wrote: > > > > On Tue, 2021-06-29 at 22:04 +0530, Ankur Saini wrote: > > [...] > > > P.S. it has been over a week since I sent a mail to    > > > overse...@gcc.gnu.org 

Re: daily report on extending static analyzer project [GSoC]

2021-06-29 Thread David Malcolm via Gcc
On Tue, 2021-06-29 at 22:04 +0530, Ankur Saini wrote: > AIM for today : > > - filter out the the nodes which already have an supergraph edge > representing the call to avoid creating another edge for call > - create enode for destination > - create eedge representing the call itself > > — > > P

Re: daily report on extending static analyzer project [GSoC]

2021-06-29 Thread Ankur Saini via Gcc
AIM for today : - filter out the the nodes which already have an supergraph edge representing the call to avoid creating another edge for call - create enode for destination - create eedge representing the call itself — PROGRESS : - in order to filter out only the relevant edges, I simply use

Re: daily report on extending static analyzer project [GSoC]

2021-06-28 Thread David Malcolm via Gcc
On Mon, 2021-06-28 at 20:23 +0530, Ankur Saini wrote: > > > > On 28-Jun-2021, at 12:18 AM, David Malcolm > > wrote: > > > > > > > > > > > > > > > > > Q. But even if we find out which function to call, how will > > > > > the > > > > > analyzer know which snode does that function belong ? > > >

Re: daily report on extending static analyzer project [GSoC]

2021-06-28 Thread Ankur Saini via Gcc
> On 28-Jun-2021, at 12:18 AM, David Malcolm wrote: >> >>> Q. But even if we find out which function to call, how will the analyzer know which snode does that function belong ? >>> >>> Use this method of supergraph: >>> supernode *get_node_for_function_entry (function *fun)

Re: daily report on extending static analyzer project [GSoC]

2021-06-27 Thread David Malcolm via Gcc
On Sat, 2021-06-26 at 20:50 +0530, Ankur Saini wrote: > > > On 25-Jun-2021, at 9:04 PM, David Malcolm > > wrote: > > > > On Fri, 2021-06-25 at 20:33 +0530, Ankur Saini wrote: > > > AIM for today : > > > > > > - try to create an intra-procedural link between the calls the > > > calling > > > an

Re: daily report on extending static analyzer project [GSoC]

2021-06-26 Thread Ankur Saini via Gcc
> On 25-Jun-2021, at 9:04 PM, David Malcolm wrote: > > On Fri, 2021-06-25 at 20:33 +0530, Ankur Saini wrote: >> AIM for today : >> >> - try to create an intra-procedural link between the calls the calling >> and returning snodes >> - figure out the program point where exploded graph would kno

Re: daily report on extending static analyzer project [GSoC]

2021-06-25 Thread David Malcolm via Gcc
On Fri, 2021-06-25 at 20:33 +0530, Ankur Saini wrote: > AIM for today : > > - try to create an intra-procedural link between the calls the calling > and returning snodes > - figure out the program point where exploded graph would know about > the function calls > - figure out how the exploded nod

Re: daily report on extending static analyzer project [GSoC]

2021-06-25 Thread Ankur Saini via Gcc
AIM for today : - try to create an intra-procedural link between the calls the calling and returning snodes - figure out the program point where exploded graph would know about the function calls - figure out how the exploded node will know which function to call - create enodes and eedges for

Re: daily report on extending static analyzer project [GSoC]

2021-06-24 Thread David Malcolm via Gcc
On Thu, 2021-06-24 at 19:59 +0530, Ankur Saini wrote: > CURRENT STATUS : > > analyzer is now splitting nodes even at call sites which doesn’t have > a cgraph_edge. But as now the call and return nodes are not > connected, the part of the function after such calls becomes > unreachable making them