daily report on extending static analyzer project [GSoC]

[Ankur Saini]

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 used the fact that the edge that we care about will not have any call_graph edge associated with it. ( means “sedge->get_any_callgraph_edge()" would return NULL )

- I was also successfully able to create the enode and connect it with an eedge representing the call and was able to see it calling the correct function on some examples. :)

- But the problem now is returning from the function, which turned out bigger then I though it was. 

- In order to tackle this problem, I first tried to update the call_string with the call, but the only way to push a call to the string I found was via “call_string::push_call()” function which finds the return_superedge from the cgraph_edge representing the return call ( which we don’t have )

so I decided to make an overload of "call_string::push_call()” which directly takes a return_superedge and push it the underlying vector of edges instead of taking it from the calling edge. It looks something like this :-

File:  {$SCR_DIR}/gcc/analyzer/call-string.cc <http://call-string.cc/>
158: void
159: call_string::push_call(const return_superedge *return_sedge)
160: {
161:   gcc_assert (return_sedge);
162:   m_return_edges.safe_push (return_sedge);
163: }

I also created a temporary return_superedge ( as we now have the source and destination ), and try to update the call_string with it just to find out that call_string is private to program_point. 

So my plan for next day would be to create a custom function to the program_point class the update the call stack and return back to correct spot. 

If there is a better way of doing it then do let me know.

STATUS AT THE END OF THE DAY :- 

- filter out the the nodes which already have an supergraph edge representing the call ( Done )
- create enode for destination ( Done )
- create eedge representing the call itself ( Done ? )

—

P.S. it has been over a week since I sent a mail to overseers@gcc.gnu.org <mailto:overseers@gcc.gnu.org> regarding the ssh key incident and I haven’t got any response form them till now, does this usually take this long for them to respond ? or does this means I didn’t provide some information to them that I should have. Is there something else I can do regarding this problem ?

Thank you
- Ankur