Re: GSoC project

[Ankur Saini via Gcc]

I think this is what you are looking for 

https://gcc.gnu.org/wiki/SummerOfCode

> On 22-Feb-2021, at 12:08 PM, Utkarsh singh via Gcc  wrote:
> 
> Greeting to the team,
> I  am Utkarsh Singh. I was going through various projects in the
> archive section of GSoC. I searched for some specific projects in
> Mathematics and C programming as I am most used with this field. I feel I
> can contribute to the organisation which is in turn contributing to the
> world. I wanted to know if the organisation has registered for GSoC 2021
> and how I should start my contribution journey in GNU Compiler Collection.
> Thanks and Regards.

GSoC 2021 - Static analyzer project

[Ankur Saini via Gcc]

Hello,

While looking for some project to contribute on for GSOC 2021, I came across 
project about extending static analyser pass, especially the part that involve 
adding C++ support to it.

I have already used -fanalyzer option ( which I initially came to know about 
via some blog post ) a couple of times to make debugging process of some of my 
C projects easier and faster ( especially thanks to the part where it also 
provides CWE code of the error along with the error message )  but always 
wanted a C++ version of it ever since ( as that is the language I use the most 
), and finding it as a project idea for this years GSOC sounded a perfect 
opportunity for me to try and contribute something to this project.

I have already built the compiler from the source code and was able to run a 
testsuit for it as mentioned in “Before you apply” section of the “Summer Of 
Code” page of gcc (https://gcc.gnu.org/wiki/SummerOfCode 
),

currently I am in process of reading this ( 
https://gcc.gnu.org/onlinedocs/gccint/Analyzer-Internals.html#Analyzer-Internals
 
)
 documentation to understand how things are going on under the hood and trying 
to make sense out of the source code of the analyzer itself with the help of it.

I have some questions before applying

- Am I on right path before applying for the project ? 

- Is there a way I can contribute some small bug fixes before applying for the 
real project itself 
( although I am scanning the bug 
tracker(https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&bug_status=VERIFIED&component=analyzer&product=gcc
 
)
 for any potential quick fix but any help in finding one would be a great ) ? 

- Is there anything else I should be aware of before applying ?

Thanks,
Ankur

Re: GSoC 2021 - Static analyzer project

[Ankur Saini via Gcc]

> On 06-Mar-2021, at 6:05 AM, David Malcolm  wrote:
> 
> If you run the analyzer on your own code, and can trigger a false
> positive or a false negative with the analyzer on it, and try to figure
> out the issue, that could be a useful step (though it might turn out to
> be a difficult one to fix, of course…)
> 

ok, I will see what can I do

> 
> There is a tracker bug for C++ support in the analyzer here:
>  https://gcc.gnu.org/bugzilla/showdependencytree.cgi?id=97110 
> 
> though obviously that would be actually doing the project itself.
> 
> To set expectations of what's reasonable to do in one summer - I don't
> expect someone to be able to fully implement C++ support in one GSoC
> project; for example, both of
>  (a) implementing exception-handling and
>  (b) implementing RTTI/vfuncs
> are each probably big enough by themselves to take all summer.  So you
> might want to pick one of those two to focus on (there are some notes
> on each in the bugzilla comments).

thanks, I will go through them and see what suites me best

> 
>> - Is there anything else I should be aware of before applying ?
> 
> I think if you've read the internals doc and the various organization
> stuff on https://gcc.gnu.org/wiki/SummerOfCode 
>  page you're on the right
> lines.
> 

good to hear that, so I will continue to understand the source code with help 
of internal docs for now and will report back when I would have successfully 
triggered a false positive or false negative with the analyser with it’s cause 
( and if possible the fix also )

> Hope this is helpful; good luck!

> 
> Dave

thanks again,

Ankur

Re: static analysis above GCC (GSoC 2021)

[Ankur Saini via Gcc]

> On 06-Mar-2021, at 6:40 PM, Basile Starynkevitch  
> wrote:
> 
> 
> 
> On Fri, 2021-03-05 at 17:04 +0530, Ankur Saini via Gcc wrote:
>> Hello,
> Hi Ankur
> You could look at the DECODER European project on 
> https://www.decoder-project.eu/ <https://www.decoder-project.eu/> and at the 
> Bismon static source code analyzer funded by it (for a few more weeks)
> 
> https://github.com/bstarynk/bismon <https://github.com/bstarynk/bismon>
thanks, I will check that out also

- Ankur

Re: GSoC 2021 - Static analyzer project

[Ankur Saini via Gcc]

hello sir 

in my quest of finding a bug ( which ended up being a feature ) along with it’s 
source in the analyzer, I tested the code on these 2 code snippets and here’s 
how I went towards it 

(1)
int main()
{
int *ptr = (int *)malloc(sizeof(int));
return 0;
}

link to running example (https://godbolt.org/z/1jGW1qYez 
)

(2)
int definaltly_main()
{
int *ptr = (int *)malloc(sizeof(int));
return 0;
}

link to running example (https://godbolt.org/z/bzjMYex4M 
)


where on second snipper analyzer is warning us about the leak as it should be, 
but in the first one it isn’t. 

and as the gimple representation of both looks exactly the same apart from 
function name, which made me think that either intentionally or 
unintentionally, analyzer handles case of main() differently than any other 
function.

so while looking at it’s exploded graphs I found out that the only 2 
differences in them 

1. There is one less exploded node(after node E-8) created in first one ( I 
earlier thought state merging or state pruning is taking place here but it 
isn’t because the results are not affected even after disabling those using  
`-fno-analyzer-state-purge` and `-fno-analyzer-state-merge` options )

2. no diagnosis for malloc leak happening at the end of first one even though 
there exist a pointer in unchecked state at the end ( according to the malloc 
state machine )

In quest to find the cause I started navigating through the source code of the 
analyser starting off with the run_checkers() function in engine.cc which looks 
like the entry point of the analyser ( found via the commit history of the 
analyzer ). But finally it ended at 
`impl_region_model_context::on_state_leak()` function where I found out that 
analyzer is intentionally skipping the leak report when it is in main. 

This gave rise to some questions

1. why does the analyzer make exceptions with the main() function ?

2. even if it is not complaining about the leak then this still doesn’t explain 
the reason for one less exploded node in this case of main() function.

thanks

- Ankur

Re: GSoC 2021 - Static analyzer project

[Ankur Saini via Gcc]

> On 30-Mar-2021, at 7:27 PM, David Malcolm  wrote:

>> This gave rise to some questions
>> 
>> 1. why does the analyzer make exceptions with the main() function ?
> 
> The user's attention is important - we don't want to spam the user with
> unnecessary reports if we can help it.

make sense. 

——

After fiddling around with a lot of C codes, I switched to C++ programs  
in-order to find how exactly the analyzer doesn’t understand exception handling 
and more interestingly calls to virtual functions ( which I am thinking to work 
on this summer ). 

It was comparatively harder to find such an example where it would fail as 
looks like gcc do amazingly nice job at devirtualising the function calls ( 
even with -O0 option ) but finally after a lot of attempts and reading online 
about devirtualisation, I found this particular example where the analyzer 
generates a false positive

#include 

struct A
{
virtual int foo (void) 
{
return 42;
}
};

struct B: public A
{
int *ptr;
void alloc ()
{
ptr = (int*)malloc(sizeof(int));
}
int foo (void) 
{ 
free(ptr);
return 0;
}
};

int test()
{
struct B b, *bptr=&b;
b.alloc();
bptr->foo();
return bptr->foo();
}

int main()
{
test();
}

working link of the above code (https://godbolt.org/z/n17WK4MxG 
)

here as the analyzer doesn’t understand the call to virtual function, wasn’t 
able to locate a double free in the program which was found at runtime.

so I went through it’s exploded graph to see how exactly is this being 
processed. And from the looks of things the anayzer doesn’t understood the 
function call which according to me was the following part in gimple 
representation :

1 = bptr_8->D.3795._vptr.A;
 _2 = *_1;
OBJ_TYPE_REF(_2;(struct B)bptr_8->0) (bptr_8)

after scanning the source-code a bit i found out that such calls were being 
processed by "region_model::handle_unrecognized_call()” where it just keeps 
track of reachable states from that node.

——

Questions 

1. The link to the bug tracker for vfunc() [ 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97114 
 ] says that for vfuncs() 
to be understood by anayzer, it ought to be able to devirtualize calls, but is 
it possible to devirtualise all the calls ? what if it is random or depends on 
user input ?

2. Even though analyzer didn’t understood calls to virtual function, it didn’t 
gave warning about a memory leak either which according to it, should exist if 
the functions were never called to deallocate the pointer ( after exploded node 
152 and 118, the state of malloc changes automatically ) ?

sorry if I am asking a lot of questions.

Thank you

- Ankur

Re: GSoC 2021 gcc analyzer project

[Ankur Saini via Gcc]

> On 19-May-2021, at 4:12 AM, David Malcolm  wrote:
> 
> [sending this offlist for now]
> 
> Hi Ankur

Hi

> 
> I'm mentoring your "Extending C++ support for static analysis pass"
> GSoC project, so I thought I'd say "hi"... or looking at your email
> address should that be "hail"? :-)
XD

> 
> We're in the "Community Bonding" phase (until June 6th, I believe).
> 
> Some things we ought to get set up during this time:
> 
> - copyright assignment (see Martin Jambor's email)

 Done

> 
> - making sure you can build GCC from source, run the test suite on the
> result, and step through things in the debugger (you've already done
> some of this already, IIRC).

Yes, I have already build gcc from source few times ( especially when there is 
an update to analyzer ) and have skimmed thought things via debugger but I 
would be doing more of it now.

> 
> Can we have this discussion on the GCC mailing list?

Ok, I have cc gcc@gcc.gnu.org  on this reply

> 
> What's the best email address to contact you at?  The GSoC dashboard
> has your email as "hailankurthe...@gmail.com", but your application has
> "arsenic.second...@gmail.com" so I've sent this email to both.

"arsenic.second...@gmail.com ” is what I 
would be using primarily for most of my interactions here, the other one is 
more for personal or urgent mails( free from all the noise from mailing lists 
that I am subscribed to ) so feel free to use it in case you want to send an 
urgent mail that need immediate attention. 

> 
> It might be good to have an initial "meeting" virtually if that's
> something you can do - e.g. Zoom or Google Meetings, or similar.  I
> live near Boston, MA in the USA (currently at UTC-4), and I believe
> you're in/near Delhi (UTC+5:30 ?).  That's a somewhat awkward
> combination of timezones.  With no specific date in mind, but looking
> at:
>  
> https://www.timeanddate.com/worldclock/meetingtime.html?year=2021&month=5&day=18&p1=43&p2=771
> it looks like my 8:15am is your 5:45pm, if that's a time that could
> work for you?

I am totally ok with the timing and have access to both zoom and google meet 
for online meetings.

> 
> That said I have no idea what bandwidth is like for you (e.g. if your
> connection is metered, or if access to internet is difficult given the
> pandemic), so I apologize if this is an unreasonable suggestion.

internet should not be a problem, I have access to an unlimited broadband WIFI 
connection along with decent amount of cellular data to back it up in case of 
speed drops or power failure.

Thanks

- Ankur

Re: Welcome GCC GSoC 2021 participants

[Ankur Saini via Gcc]

Hello,

> On 18-May-2021, at 9:52 PM, Martin Jambor  wrote:
> 
> All accepted students which do not already have one must request a
> copyright assignment[1] as soon as possible.  Please email the
> following information to ass...@gnu.org and they will send you the
> assignment form for your past and future changes.  Use your full legal
> name (in ASCII characters) as the subject line of the message.  The
> "program or package" is of course GCC.
> 

I sent a mail requesting the same to ass...@gnu.org  on 
19th-May-2021, and haven’t received any response till now. Is this common to 
have them take this long ?

Thank you,
- Ankur

Re: Welcome GCC GSoC 2021 participants

[Ankur Saini via Gcc]

> On 24-May-2021, at 3:12 PM, Martin Jambor  wrote:
> 
> Hello,
> 
> On Sun, May 23 2021, Ankur Saini wrote:
>> Hello,
>> 
>>> On 18-May-2021, at 9:52 PM, Martin Jambor  wrote:
>>> 
>>> All accepted students which do not already have one must request a
>>> copyright assignment[1] as soon as possible.  Please email the
>>> following information to ass...@gnu.org and they will send you the
>>> assignment form for your past and future changes.  Use your full legal
>>> name (in ASCII characters) as the subject line of the message.  The
>>> "program or package" is of course GCC.
>>> 
>> 
>> I sent a mail requesting the same to ass...@gnu.org
>>  on 19th-May-2021, and haven’t received any
>> response till now. Is this common to have them take this long ?
> 
> Unfortunately, it has happened in the past.
> 
> Please remind them about your request every week or so until they
> respond.  If the delay interferes with your project, let me know and I
> will talk to our steering committee and others about the situation.


Thanks for information : )
Actually not long after this, they sent the form for signing and today I have 
finally got my complete assignment in hand with me.

Thanks,

- Ankur

progress update after initial GSoC virtual meetup

[Ankur Saini via Gcc]

hello 

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 ). Also I was also able to run one single test on the built 
compiler. 

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 ?

Thanks,

- Ankur

Re: progress update after initial GSoC virtual meetup

[Ankur Saini via Gcc]

> On 01-Jun-2021, at 6:38 PM, David Malcolm  wrote:
> 
> - 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.

I tried this, and it’s awesome :D , I was able to complete the either bootstrap 
build on one of the powerful machine there with almost similar time to that of 
what my laptop takes to build with bootstrap disabled.

> 
> - 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.

done

> 
> - 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.

done

> 
> - 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.

Right now I only enable C and C++ when building.

> 
> - 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 already did that when I was fiddling around with the source code and track my 
changes seperately

> 
> 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.

yes, looking at exploded graph, the analyzer is not able to understand the call 
to function “noReturn()” when called via a function pointer ( noReturnPtr.0_1 
("”); ) at all. I would be looking into it and will report back as soon 
as I find something useful.

also, should I prefer discussing about this bug here( gcc mailing list) or on 
the bugzilla itself ?

>  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.

ok

> 
> Hope this is helpful

Thanks,

- Ankur

Re: progress update after initial GSoC virtual meetup

[Ankur Saini via Gcc]

> On 08-Jun-2021, at 11:24 PM, David Malcolm  wrote:
> 
> Is there a URL for your branch?

no, currently it only local branch on my machine. Should I upload it on a 
hosting site ( like GitHub ) ? or can I create a branch on remote also ?

> The issue is that the analyzer currently divides calls into
> (a) calls where GCC's middle-end "knows" which function is called, and
> thus the call site has a cgraph_node.
> (b) calls where GCC's middle-end doesn't "know" which function is
> called.
> 
> The analyzer handles
>  (a) by building call and return edges in the supergraph, and
> processing them, and
>  (b) with an "unknown call" handler, which conservatively sets lots of
> state to "unknown" to handle the effects of an arbitrary call, and
> where the call doesn't get its own exploded_edge.

> 
> In this bug we have a variant of (b), let's call it (c): GCC's middle-
> end doesn't know which function is called, but the analyzer's
> region_model *does* know at a particular exploded_node.

but how will the we know this at the time of creation of supergraph? isn’t 
exploded graph and regional model created after the supergraph ?

>  I expect this kind of thing will also arise for virtual function calls.

yes, it would be a similar case as if the call is not devirtualised, GCC’s 
middle-end would not know which function is being called but our regional model 
would know about the same.

>  So I think you should look at supergraph.cc at where it handles calls; I 
> think we
> need to update how it handles (b), so that it can handle the (c) cases,
> probably by splitting supernodes at all call sites, rather than just
> those with cgraph_edges, and then creating exploded_edges (with custom
> edge info) for calls where the analyzer "figured out" what the function
> pointer was in the region_model, even if there wasn't a cgraph_node.

> 
> Does that make sense?

ok so we are leaving the decision of how to handle case (b) to explodedgraph 
with the additional info from the regional model and create a call and return 
supernodes for all type of function calls whether or not middle-end know which 
function is called or not, makes sense. ( ok so this answers my previous 
question )

I went through supergraph.cc  and can see the splitting 
happening in the constructor’s (supergraph::supergraph() ) at the end of first 
pass.

> 
> Or you could attack the problem from the other direction, by looking at
> what GCC generates for a vfunc call, and seeing if you can get the
> region_model to "figure out" what the function pointer is at a
> particular exploded_node.

I will also be looking at this after the fixing the above problem, my current 
plan is to see how GCC's devirtualiser do it.

> 
>> 
>> also, should I prefer discussing about this bug here( gcc mailing
>> list) or on the bugzilla itself ?
> 
> Either way works for me.  Maybe on this list?  (given that this feels
> like a design question)

ok

> 
> Hope this is helpful
> Dave

Thanks

- Ankur

progress update

[Ankur Saini via Gcc]

> On 13-Jun-2021, at 8:22 PM, David Malcolm  wrote:
> 
> On Sun, 2021-06-13 at 19:11 +0530, Ankur Saini wrote:
>> 
>> 
>>> On 08-Jun-2021, at 11:24 PM, David Malcolm >> >
>>> wrote:
>>> 
>>> Is there a URL for your branch?
>> 
>> no, currently it only local branch on my machine. Should I upload it on
>> a hosting site ( like GitHub ) ? or can I create a branch on remote
>> also ?
> 
> At some point we want you to be able to push patches to trunk, so as a
> step towards that I think it would be good for you to have a personal
> branch on the gcc git repository.
> 
> A guide to getting access is here:
>  https://gcc.gnu.org/gitwrite.html 
> 
> I will sponsor you.

I have filled the form.

> 
>> 
>>> The issue is that the analyzer currently divides calls into
>>> (a) calls where GCC's middle-end "knows" which function is called,
>>> and
>>> thus the call site has a cgraph_node.
>>> (b) calls where GCC's middle-end doesn't "know" which function is
>>> called.
>>> 
>>> The analyzer handles
>>>  (a) by building call and return edges in the supergraph, and
>>> processing them, and
>>>  (b) with an "unknown call" handler, which conservatively sets lots
>>> of
>>> state to "unknown" to handle the effects of an arbitrary call, and
>>> where the call doesn't get its own exploded_edge.
>> 
>>> 
>>> In this bug we have a variant of (b), let's call it (c): GCC's
>>> middle-
>>> end doesn't know which function is called, but the analyzer's
>>> region_model *does* know at a particular exploded_node.
>> 
>> but how will the we know this at the time of creation of supergraph?
>> isn’t exploded graph and regional model created after the supergraph ?
> 
> You are correct.
> 
> What I'm thinking is that when we create the supergraph we should split
> the nodes at more calls, not just at those calls that have a
> cgraph_edge, but also at those that are calls to an unknown function
> pointer (or maybe even split them at *all* calls).
> 
> Then, later, when engine.cc  is building the 
> exploded_graph, the
> supergraph will have a superedge for those calls, and we can create an
> exploded_edge representing the call.  That way if we discover the
> function pointer then (rather than having it from a cgraph_edge), we
> can build exploded nodes and exploded edges that are similar to the "we
> had a cgraph_edge" case.  You may need to generalize some of the event-
> handling code to do this.
> 
> Does that make sense?
> 
> You might want to try building some really simple examples of this, to
> make it as easy as possible to see what's happening, and to debug.

ok let me see what can I do.

[...]

> Great.
> 
> Let me know how you get on.
> 
> As I understand it, Google recommends that we're exchanging emails
> about our GSoC project at least two times a week, so please do continue
> to report in, whether you're making progress, or if you feel you're
> stuck on something.

ok I would be more active from now on.

—

btw while using the gdb on “xgcc”, for some reason, debugger is not tracing the 
call to "run_checkers()” and is directly jumping from 
"pass_analyzer::execute()” to some instruction inside 
"ana::dump_analyzer_json()”. 

I am invoking debugger like this  :- 

—
$ ./xgcc /Users/ankursaini/Desktop/test.c -fanalyzer -B . -wrapper gdb,—args
—

and then while putting a breakpoint on “ana::run_checkers()”, gdb places 2 
breakpoints ( one on correct position and another weirdly inside a different 
function in the same file )

—
(gdb) br ana::run_checkers() 
Breakpoint 3 at 0x101640990 (2 locations)

(gdb) info br
Num Type   Disp Enb AddressWhat
1   breakpoint keep y   0x00010174ade7 in fancy_abort(char const*, 
int, char const*) at ../../gcc-source/gcc/diagnostic.c:1915
2   breakpoint keep y   0x00010174ee01 in internal_error(char 
const*, ...) at ../../gcc-source/gcc/diagnostic.c:1835

3   breakpoint keep y
3.1  y   0x000101640990 

3.2  y   0x000101640ba0 in 
ana::run_checkers() at ../../gcc-source/gcc/analyzer/engine.cc:4918 

—

but during the execution it only hits the breakpoint 3.1 ( which is inside the 
function "ana::dump_analyzer_json()” which according to me is called during the 
execution of "impl_run_checkers()”, after completing the analysis to dump the 
results in json format ) 

after looking at backtrace, I could see it calling "pass_analyzer::execute()” 
where “run_checkers()” should be called, but no such call (or a call to 
"impl_run_checkers()”)  is seen there .

here is the backtrace when debugger hits this breakpoint 3.1
—
(gdb) c
Continuing.
[New Thread 0x1c17 of process 2392]

Thread 2 hit Breakpoint 3, 0x000101640990 in ana::dump_analyzer_json 
(sg=..., eg=...) at ../../gcc-source/gcc/analyzer/engine.cc:4751
4751  char *filename = concat (dump_base_nam

Progress update on extending static analyser to support c++'s virtual function

[Ankur Saini via Gcc]

so I have a good news and a bad news 

good news is that I was successfully able to split the calls at every call-site 
during the creation of super-graph. 

I did it by simply adding an 'else’ statement where analyser handles splitting 
of snodes, so that it can still handle the known calls ( one with a cgraph_edge 
) and also split the calls at the unknown call sites for analyzer to later 
speculate the source of the call with more information from regional models. 

something like this :-

in `ana::supergraph::supergraph(ana::logger*)` in supergraph.cc 


185 if (cgraph_edge *edge = supergraph_call_edge (fun, stmt))
186 {
187m_cgraph_edge_to_caller_prev_node.put(edge, node_for_stmts);
188node_for_stmts = add_node (fun, bb, as_a  (stmt), 
NULL);
189m_cgraph_edge_to_caller_next_node.put (edge, node_for_stmts);
190 }
191 else
192 {
193   gcall *call = dyn_cast (stmt);
194   if (call)
195 node_for_stmts = add_node (fun, bb, as_a  (stmt), NULL);
196 }

after building I could see analyzer creating snodes for returning calls from 
the function it was not before for various examples. 

—

now the bad news. 

I accidentally overwrote the file containing my ssh key to gcc.gnu.org 
 , with another ssh key. :(

is there something that I can do to retrieve it back ? or is it lost forever 
and I have no option left other than contacting overse...@gcc.gnu.org 
 regarding the same ?

daily report on extending static analyzer project [GSoC]

[Ankur Saini via Gcc]

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 impossible to 
properly analyse.

AIM for today : 

- try to create an intra-procedural link between the calls the calling and 
returning snodes 
- find the place where the exploded nodes and edges are being formed 
- figure out the program point where exploded graph would know about the 
function calls

—

PROGRESS :

- I initially tried to connect the calling and returning snodes with an 
intraprocedural sedge but looks like for that only nodes which have a 
cgraph_edge or a CFG edge are connected in the supergraph. I tried a few ways 
to connect them but at the end thought I would be better off leaving them like 
this and connecting them during the creation of exploded graph itself.

- As the exploded graph is created during building and processing of the 
worklist, "build_initial_worklist ()” and “process_worklist()” should be the 
interesting areas to analyse, especially the processing part.

- “build_initial_worklist()” is just creating enodes for functions that can be 
called explicitly ( possible entry points ) so I guess the better place to 
investigate is “process_worklist ()” function.

—

STATUS AT THE END OF THE DAY :- 

- try to create an intra-procedural link between the calls the calling and 
returning snodes ( Abandoned )
- find the place where the exploded nodes and edges are being formed ( Done )
- figure out the program point where exploded graph knows about the function 
call ( Pending )


Thank you
- Ankur

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

[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 the calls

—

PROGRESS :

- I created an intraprocedural link between where the the splitting is 
happening to connect the call and returning snodes. like this :-

(in supergraph.cc at "supergraph::supergraph (logger *logger)" )
```
185 if (cgraph_edge *edge = supergraph_call_edge (fun, stmt))
186 {
187m_cgraph_edge_to_caller_prev_node.put(edge, node_for_stmts);
188node_for_stmts = add_node (fun, bb, as_a  (stmt), 
NULL);
189m_cgraph_edge_to_caller_next_node.put (edge, node_for_stmts);
190 }
191 else
192 {
193   gcall *call = dyn_cast (stmt);
194   if (call)
195   {
196 supernode *old_node_for_stmts = node_for_stmts;
197 node_for_stmts = add_node (fun, bb, as_a  (stmt), 
NULL);
198
199 superedge *sedge = new callgraph_superedge 
(old_node_for_stmts,
200 node_for_stmts,
201 SUPEREDGE_INTRAPROCEDURAL_CALL,
202 NULL);
203 add_edge (sedge);
204   }
205 }
```

- now that we have a intraprocedural link between such calls, and the analyzer 
will consider them as “impossible edge” ( whenever a "node->on_edge()” returns 
false ) while processing worklist, and I think this should be the correct place 
to speculate about the function call by creating exploded nodes and edges 
representing calls ( maybe by adding a custom edge info ).

- after several of failed attempts to do as mentioned above, looks like I was 
looking the wrong way all along. I think I just found out what my mentor meant 
when telling me to look into "calls node->on_edge”. During the edge inspection 
( in program_point::on_edge() ) , if it’s an Intraprocedural s sedge, maybe I 
can add an extra intraprocedural sedge to the correct edge right here with the 
info state of that program point. 

Q. But even if we find out which function to call, how will the analyzer know 
which snode does that function belong ?

Q. on line 461 of program-point.cc 

```
457 else
458   {
459 /* Otherwise, we ignore these edges  */
460 if (logger)
461   logger->log ("rejecting interprocedural edge");
462 return false;
463   }
```
why are we rejecting “interprocedural" edge when we are examining an 
“intraprocedural” edge ? or is it for the "cg_sedge->m_cedge” edge, which is an 
interprocedural edge ?

STATUS AT THE END OF THE DAY :- 

- try to create an intra-procedural link between the calls the calling and 
returning snodes ( Done )
- figure out the program point where exploded graph would know about the 
function calls ( Done )
- figure out how the exploded node will know which function to call ( Pending )
- create enodes and eedges for the calls ( Pending )


Thank you
- Ankur

> On 25-Jun-2021, at 2:23 AM, David Malcolm  wrote:
> 
> 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 impossible to properly analyse.
>> 
>> AIM for today : 
>> 
>> - try to create an intra-procedural link between the calls the
>> calling and returning snodes 
>> - find the place where the exploded nodes and edges are being formed 
>> - figure out the program point where exploded graph would know about
>> the function calls
>> 
>> —
>> 
>> PROGRESS :
>> 
>> - I initially tried to connect the calling and returning snodes with
>> an intraprocedural sedge but looks like for that only nodes which
>> have a cgraph_edge or a CFG edge are connected in the supergraph. I
>> tried a few ways to connect them but at the end thought I would be
>> better off leaving them like this and connecting them during the
>> creation of exploded graph itself.
>> 
>> - As the exploded graph is created during building and processing of
>> the worklist, "build_initial_worklist ()” and “process_worklist()”
>> should be the interesting areas to analyse, especially the processing
>> part.
>> 
>> - “build_initial_worklist()” is just creating enodes for functions
>> that can be called explicitly ( possible entry points ) so I guess
>> the better place to investigate is “process_worklist ()” function.
> 
> Yes.
> 
> Have a look at exploded_graph::process_node (which is called by
> process_worklist).
> The eedges for calls with supergraph edges happens there in
> the "case PK_AFT

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

[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 know about
>> the function calls
>> - figure out how the exploded node will know which function to call
>> - create enodes and eedges for the calls
>> 
>> —
>> 
>> PROGRESS :
>> 
>> - I created an intraprocedural link between where the the splitting is 
>> happening to connect the call and returning snodes. like this :-
>> 
>> (in supergraph.cc at "supergraph::supergraph (logger *logger)" )
>> ```
>> 185 if (cgraph_edge *edge = supergraph_call_edge (fun, stmt))
>> 186 {
>> 187m_cgraph_edge_to_caller_prev_node.put(edge, 
>> node_for_stmts);
>> 188node_for_stmts = add_node (fun, bb, as_a  
>> (stmt), NULL);
>> 189m_cgraph_edge_to_caller_next_node.put (edge, 
>> node_for_stmts);
>> 190 }
>> 191 else
>> 192 {
>> 193   gcall *call = dyn_cast (stmt);
>> 194   if (call)
>> 195   {
>> 196 supernode *old_node_for_stmts = node_for_stmts;
>> 197 node_for_stmts = add_node (fun, bb, as_a  
>> (stmt), NULL);
>  ^
> Given the dyn_cast of stmt to gcall * at line 193 you can use "call"
> here, without the as_a cast, as you've already got "stmt" as a gcall *
> as tline 193.

ok

> 
> You might need to add a hash_map recording the mapping from such stmts
> to the edges, like line 189 does.  I'm not sure, but you may need it
> later.

but the node is being created if there is no cgraph_edge corresponding to the 
call, so to what edge will I map “node_for_stmts" to ?

> 
> 
>> 198
>> 199 superedge *sedge = new callgraph_superedge 
>> (old_node_for_stmts,
>> 200 node_for_stmts,
>> 201 SUPEREDGE_INTRAPROCEDURAL_CALL,
>> 202 NULL);
>> 203 add_edge (sedge);
>> 204   }
>> 205 }
>> ```
>> 
>> - now that we have a intraprocedural link between such calls, and the
>> analyzer will consider them as “impossible edge” ( whenever a "node-
>>> on_edge()” returns false ) while processing worklist, and I think this
>> should be the correct place to speculate about the function call by
>> creating exploded nodes and edges representing calls ( maybe by adding
>> a custom edge info ).
>> 
>> - after several of failed attempts to do as mentioned above, looks like
>> I was looking the wrong way all along. I think I just found out what my
>> mentor meant when telling me to look into "calls node->on_edge”. During
>> the edge inspection ( in program_point::on_edge() ) , if it’s an
>> Intraprocedural s sedge, maybe I can add an extra intraprocedural sedge
>> to the correct edge right here with the info state of that program
>> point. 
> 
> I don't think we need a superedge for such a call, just an
> exploded_edge.  (Though perhaps adding a superedge might make things
> easier?  I'm not sure, but I'd first try not bothering to add one)

ok, will scratch this idea for now.

> 
>> 
>> 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) const;
> to get the supernode for the entrypoint of a given function.
> 
> You can get the function * from a fndecl via DECL_STRUCT_FUNCTION.

so once we get fndecl, it should be comparatively smooth sailing from there. 

My attempt to get the value of function pointer from the state : -

- to access the region model of the state, I tried to access “m_region_model” 
of that state.
- now I want to access cluster for a function pointer.
- but when looking at the accessible functions to region model class, I 
couldn’t seem to find the fitting one. ( the closest I could find was 
“region_model::get_reachable_svalues()” to get a set of all the svalues 
reachable from that model )

> 
>> Q. on line 461 of program-point.cc 
>> 
>> ```
>> 457 else
>> 458   {
>> 459 /* Otherwise, we ignore these edges  */
>> 460 if (logger)
>> 461   logger->log ("rejecting interprocedural edge");
>> 462 return false;
>> 463   }
>> ```
>> why are we rejecting “interprocedural" edge when we are examining an
>> “intraprocedural” edge ? or is it for the "cg_sedge->m_cedge” edge,
>> which is an interprocedural edge ?
> 
> Currently, those interprocedural edges don't do much.  Above the "else"
> clause of the lines above the ones you quote is some support for call
> summaries.
> 
> The idea is that we ought to be able to compute 

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

[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) const;
>>> to get the supernode for the entrypoint of a given function.
>>> 
>>> You can get the function * from a fndecl via DECL_STRUCT_FUNCTION.
>> 
>> so once we get fndecl, it should be comparatively smooth sailing from
>> there. 
>> 
>> My attempt to get the value of function pointer from the state : -
>> 
>> - to access the region model of the state, I tried to access
>> “m_region_model” of that state.
>> - now I want to access cluster for a function pointer.
>> - but when looking at the accessible functions to region model class,
>> I couldn’t seem to find the fitting one. ( the closest I could find
>> was “region_model::get_reachable_svalues()” to get a set of all the
>> svalues reachable from that model )
> 
> In general you can use:
>  region_model::get_rvalue
> to go from a tree to a symbolic value for what the analyzer "thinks"
> the value of that tree is at that point along the path.
> 
> If it "knows" that it's a specific function pointer, then IIRC this
> will return a region_svalue where region_svalue::get_pointee () will
> (hopefully) point at the function_region representing the memory
> holding the code of the function.  function_region::get_fndecl should
> then give you the tree for the specific FUNCTION_DECL, from which you
> can find the supergraph node etc.
> 
> It looks like
>  region_model::get_fndecl_for_call
> might already do most of what you need, but it looks like it bails out
> for the "NULL cgraph_node" case.  Maybe that needs fixing, so that it
> returns the fndecl for that case?  That already gets used in some
> places, so maybe try putting a breakpoint on that and see if fixing
> that gets you further?

shouldn’t the fn_decl should still have a cgraph_node if the function is 
declared in the program itself ? it should just not have an edge representing 
the call.
Because I was able to find the super-graph node just with the help of the 
function itself.

this is how the function looks "exploded_node::on_edge()" right now.

File: {$SCR_DIR}/gcc/analyzer/engine.cc
1305: bool
1306: exploded_node::on_edge (exploded_graph &eg,
1307:   const superedge *succ,
1308:   program_point *next_point,
1309:   program_state *next_state,
1310:   uncertainty_t *uncertainty)
1311: {
1312:   LOG_FUNC (eg.get_logger ());
1313: 
1314:   if (succ->m_kind == SUPEREDGE_INTRAPROCEDURAL_CALL)
1315:   {
1316: const program_point *this_point = &this->get_point();
1317: const program_state *this_state = &this->get_state ();
1318: const gcall *call = this_point->get_supernode ()->get_final_call 
();
1319: 
1320: impl_region_model_context ctxt (eg, 
1321:   this, 
1322:   this_state, 
1323:   next_state, 
1324:   uncertainty,
1325:   this_point->get_stmt());
1326: 
1327: region_model *model = this_state->m_region_model;
1328: tree fn_decl = model->get_fndecl_for_call(call,&ctxt);
1329: if(DECL_STRUCT_FUNCTION(fn_decl))
1330: {
1331:   const supergraph *sg = &eg.get_supergraph();
1332:   supernode * sn =  sg->get_node_for_function_entry 
(DECL_STRUCT_FUNCTION(fn_decl));
1333:   // create enode and eedge ?
1334: }
1335:   }
1336: 
1337:   if (!next_point->on_edge (eg, succ))
1338: return false;
1339: 
1340:   if (!next_state->on_edge (eg, this, succ, uncertainty))
1341: return false;
1342: 
1343:   return true;
1344: }

for now, it is also detecting calls that already have call_sedge connecting 
them, so I think I also have to filter them out.

> 
> Hope this is helpful
> Dave

Thanks 
- Ankur

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

[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 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 
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 overse...@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

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

[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 make the call return from 
the function by making returning exploded nodes and edges at the time of the 
call itself but failed 

- so I created a local (experimental) branch and started hacking the 
call_string to maintain a vector of gcall* instead of return_superedge*.

- I was able to modify all function execpt few, for which I either didn’t quite 
understood what should be changed or found discussing with you better before 
proceeding much better. They are as follows :- 

1. call_string::validate () : ( this one performs sanity on the object ) 
earlier object was considered to be sane if the caller is the callee of 
previous entry, but how can I get caller from the gcall ? or when can I know 
that I have a correct vector of gcalls* ?

2. call_string::cmp (const call_string &a, const call_string &b) : ( this one 
is a comparator of the call-strings ) it was earlier comparing the index of 
edges and then length. for now I have just condensed it down to compare based 
on the size of gcall vector ( assuming more calls means deeper call stack )

3. call_string::print (pretty_printer *pp): ( printer of the call-string ): how 
should the printed call stack look-like ? 

for me, it looks like maybe just tracking gcalls is not enough, or maybe I 
don’t know enough about the stuff I can access from from the gcalls ( I am 
currently looking into gcc/gimple.c for the all the possible actions I can take 
with a gimple statement )

STATUS AT THE END OF THE DAY :- 

- find and try alternative to make the analyser return from the function ( 
abandoned )
- if failed to find any worthy alternative then start changing the 
implementation of call_string to track gcalls* instead of return_edges ( 
pending )

Thank you
- Ankur

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

[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 representing them. 

- so I branched again and updated the call-string to now capture a pair of 
supernodes ( one representing callee and other representing caller ), like this 
I was not only able to easily port the entire code to adapt it without much 
difficulty, but now can also push calls to functions that doesn’t possess a 
superedge.

- changes done can be seen on the " refs/users/arsenic/heads/call_string_update 
“ branch. ( currently this branch doesn’t contain other changes I have done 
till now, as I wanted to test the new call-string representation exclusively 
and make sure it doesn’t affect the functionality of the base analyser )

- now hopefully all that is left for tomorrow is to update the analyzer to 
finally see, call and return from the function aclled via the function pointer. 

STATUS AT THE END OF THE DAY :- 

- update the call_stack to track something else other than supergraph edges ( 
done )

Thank you
- Ankur

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

[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 function called 
without the superedge
- make the analyser figure out the correct point to return back in the caller 
function
- make enode and eedge representing the return call
- test the changes on the example I created before
- speculate what GCC generates for a vfunc call and discuss how can we use it 
to our advantage

—

PROGRESS  ( changes can be seen on "refs/users/arsenic/heads/analyzer_extension 
“ branch of the repository ) :

- Thanks to the new call-string representation, I was able to push calls to the 
call stack which doesn’t have a superedge and was successfully able to see the 
calls happening via the function pointer.

- To detect the returning point of the function I used the fact that such 
supernodes would contain an EXIT bb, would not have any return superedge and 
would still have a pending call-stack. 

- Now the next part was to find out the destination node of the return, for 
this I again made use of the new call string and created a custom accessor to 
get the caller and callee supernodes of the return call, then I extracted the 
gcall* from the caller supernode to ulpdate the program state, 

- now that I have got next state and next point, it was time to put the final 
piece of puzzle together and create exploded node and edge representing the 
returning call.

- I tested the changes on the the following program where the analyzer was 
earlier giving a false negative due to not detecting call via a function pointer

```
#include 
#include 

void fun(int *int_ptr)
{
free(int_ptr);
}

int test()
{
int *int_ptr = (int*)malloc(sizeof(int));
void (*fun_ptr)(int *) = &fun;
(*fun_ptr)(int_ptr);

return 0;
}

void test_2()
{
  test();
}
```
( compiler explorer link : https://godbolt.org/z/9KfenGET9 
 )

and results were showing success where the analyzer was now able to 
successfully detect, call and return from the function that was called via the 
function pointer and no longer reported the memory leak it was reporting 
before. : )

- I think I should point this out, in the process I created a lot of custom 
function to access/alter some data which was not possible before.

- now that calls via function pointer are taken care of, it was time to see 
what exactly happen what GCC generates when a function is dispatched 
dynamically, and as planned earlier, I went to  ipa-devirt.c ( devirtualizer’s 
implementation of GCC ) to investigate.

- althogh I didn’t understood everything that was happening there but here are 
some of the findings I though might be interesting for the project :- 
> the polymorphic call is called with a OBJ_TYPE_REF which contains 
otr_type( a type of class whose method is called) and otr_token (the index into 
virtual table where address is taken)
> the devirtualizer builds a type inheritance graph to keep track of 
entire inheritance hierarchy
> the most interesting function I found was 
“possible_polymorphic_call_targets()” which returns the vector of all possible 
targets of polymorphic call represented by a calledge or a gcall.
> what I understood the devirtualizer do is to search in these 
polymorphic calls and filter out the the calls which are more likely to be 
called ( known as likely calls ) and then turn them into speculative calls 
which are later turned into direct calls.

- another thing I was curious to know was, how would analyzer behave when 
encountered with a polymorphic call now that we are splitting the superedges at 
every call. 

the results were interesting, I was able to see analyzer splitting supernodes 
for the calls right away but this time they were not connected via a 
intraprocedural edge making the analyzer crashing at the callsite ( I would 
look more into it tomorrow ) 

the example I used was : -
```
struct A
{
virtual int foo (void) 
{
return 42;
}
};

struct B: public A
{
  int foo (void) 
{ 
return 0;
}
};

int test()
{
struct B b, *bptr=&b;
bptr->foo();
return bptr->foo();
}
```
( compiler explorer link : https://godbolt.org/z/d986ab7MY 
 )

—

STATUS AT THE END OF THE DAY :- 

- make the analyzer call the function with the updated call-string 
representation ( even the ones that doesn’t have a superedge ) (done)
- make the analyzer figure out the point of return from the function called 
without the superedge (done)
- make the analyser figure out the correct point to return back in the caller 
function (done)
- make enode and eedge representing the return call (done)
- test the changes on the example I created before (done)
- speculate what GCC generates for a vfunc call

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

[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 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 representing them. 
>> 
>> - so I branched again and updated the call-string to now capture a pair
>> of supernodes ( one representing callee and other representing caller
>> ), like this I was not only able to easily port the entire code to
>> adapt it without much difficulty, but now can also push calls to
>> functions that doesn’t possess a superedge.
>> 
>> - changes done can be seen on the "
>> refs/users/arsenic/heads/call_string_update “ branch. ( currently this
>> branch doesn’t contain other changes I have done till now, as I wanted
>> to test the new call-string representation exclusively and make sure it
>> doesn’t affect the functionality of the base analyser )
> 
> I'm not an expert at git, so it took me a while to figure out how to
> access your branch.
> 
> It's easier for me if you can also use "git format-patch" to generate a
> patch and "git send-email" to send it to this list (and me, please), so
> that the patch content is going to the list.
> 
> The approach in the patch seems reasonable.
> 
> I think you may have a memory leak, though: you're changing call_string
> from:
>  auto_vec m_return_edges;
> to:
>  auto_vec*> m_supernodes;
> 
> and the std:pairs are being dynamically allocated on the heap.
> Ownership gets transferred by call_string::operator=, but if I'm
> reading the patch correctly never get deleted.  This is OK for
> prototyping, but will need fixing before the code can be merged.

> 
> It's probably simplest to get rid of the indirection and allocation in
> m_supernodes and have the std::pair be stored by value, rather than by
> pointer, i.e.:
>  auto_vec > m_supernodes;
> 
> Does that work? (or is there a problem I'm not thinking of).

yes, I noticed that while creating, was thinking to empty the vector and delete 
the all the memory in the destructor of the call-string ( or make them unique 
pointers and let them destroy themselves ) but looks like storing the values of 
the pairs would make more sense.

> 
> If that's a problem, I think you might be able to get away with
> dropping the "first" from the pair, and simply storing the supernode to
> return to; I think the only places that "first" gets used are in dumps
> and in validation.  But "first" is probably helpful for debugging, so
> given that you've got it working with that field, better to keep it.

yes, I see that too, but my idea is to keep it as is for now ( maybe it might 
turn out to be helpful in future ). I will change it back if it proves to be 
useless and we get time at the end.

> 
> Hope this is helpful
> Dave
> 
>> 
>> - now hopefully all that is left for tomorrow is to update the analyzer
>> to finally see, call and return from the function aclled via the
>> function pointer. 
>> 
>> STATUS AT THE END OF THE DAY :- 
>> 
>> - update the call_stack to track something else other than supergraph
>> edges ( done )
>> 
>> Thank you
>> - Ankur

———

> On 07-Jul-2021, at 4:20 AM, David Malcolm  wrote:
> 
> 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 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 representing them. 
>>> 
>>> - so I branched again and updated the call-string to now capture a
>>> pair
>>> of supernodes ( one representing callee and other representing
>>> caller
>>> ), like this I was not only able to easily port the entire code to
>>> adapt it without much difficulty, but now can also push calls to
>>> functions that doesn’t possess a superedge.
>>> 
>>> - changes done can be seen on the "
>>> refs/users/arsenic/heads/call_string_update “ branch. ( currently
>>> this
>>> branch doesn’t contain other changes I have done till now, as I
>>> wanted
>>> to test the new call-string representation exclusively and make
>>> sure it
>>> doesn’t affect the functionality of the base analyser )
>> 
>> I'm not an expert at git, so it took me a while to figure out how to
>> access your branch.
>> 
>> It's easier for me if you can also use "git format-patch" to generate
>> a
>> patch and "git send-email" to send it to this list (and me, please),
>> so
>> that the patch content is going to the list.
>> 
>> The approach in the patch seems reasonable.
>> 
>> I think you may have a memory leak, though: you're chang

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

[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

—

PROGRESS :

- I successfully changed the entire call string representation again to keep 
track of "auto_vec m_elements;” from "auto_vec*> 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 
 

- 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  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 
>> >) 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

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

[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 changes done so far on vfunc calls

—

PROGRESS :

- In order to go from “return” supernode to “call” supernode, I used the fact 
that return supernode will have GIMPLE call statement which when passed to 
“get_supernode_for_stmt ()”  returns pointer to “call” supernode. 

now that part of the function look something like this 

File: {SCR_DIR}/gcc/analyzer/state-purge.cc 

347:/* Add any intraprocedually edge for a call.  */
348:if (snode->m_returning_call)
349:  {
350:cgraph_edge *cedge
351:  = supergraph_call_edge (snode->m_fun,
352:  snode->m_returning_call);
353:if(!cedge)
354:{
355:supernode* callernode = map.get_sg 
().get_supernode_for_stmt(snode->m_returning_call);
356:gcc_assert (callernode);
357:add_to_worklist
358:  (function_point::after_supernode (callernode),
359:   worklist, logger);
360:}
361:else
362:{
363:gcc_assert (cedge);
364:superedge *sedge
365:  = map.get_sg 
().get_intraprocedural_edge_for_call (cedge);
366:gcc_assert (sedge);
367:add_to_worklist
368:  (function_point::after_supernode 
(sedge->m_src),
369:   worklist, logger);
370:}
371:  }

- now the patch also fixes bug #100546 
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100546 
) and doesn’t give out a 
false report about dereferencing a null pointer which will never happen.

- now I tested it with vfuncs to see what happens in that case, the results 
were as expected where the analyzer detects the call to virtual function and 
split call and returning supernodes, but did not understand which function to 
calll, making nodes after it unreachable. 

- Now If we somehow able to update the regional model to understand which 
function is called ( or may be called ) then the analyzer can now easily call 
and analyze that virtual function call.


STATUS AT THE END OF THE DAY :- 

- get "state_purge_per_ssa_name::process_point () “ to  go from the “return" 
supernode to the “call” supernode. ( done )
- fix bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100546 
 in the process. ( done )
- test and observe the effect of changes done so far on vfunc calls ( done )

—
P.S. 
regarding the patch I sent to mailing list yesterday. I found it, apparently 
the mail was detected as a "spam mail” by my system and was redirected  to my 
spam inbox. 
Btw I am also attaching that patch file with this mail for the records.




Thank you 
- Ankur

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

[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 " 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 m_elements;” from "auto_vec> std::pair*> 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 
>>  > arse...@sourceware.org > 
> 
> Thanks.
> 
> I see the patch email in the list archives here:
>  https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574888.html 
> 
> but for some reason it's not showing up in my inbox.  I'm not sure why;
> I recently got migrated to a new email server and my filters are
> currently a mess so it could be a problem at my end; sorry if that's
> the case.
> 
> Given that neither you nor I seem to have received the patch I wonder
> if anyone else received it?

Then I think it’s better to attach patch file with the updates here instead.

> 
> Given that, I'm going to reply to that patch email inline here (by
> copying and pasting it from the archive):
> 
>> [PATCH 1/2] analyzer: refactor callstring to work with pairs of supernodes 
>> [GSoC]
>> 
>> 2021-07-3  Ankur Saini  > >
> 
> There are some formatting rules that we follow with ChangeLog entries.
> We have a script:
> 
>  ./contrib/gcc-changelog/git_check_commit.py --help

Ok, I will keep in mind to double check with it from now on.

> 
> that you can run to check the formatting.
> 
>>* gcc/analyzer/call-string.cc : refactor 
>> callstring to work with pair of supernodes instead of super superedges
>>* gcc/analyzer/call-string.h: make callstring work with pairs of 
>> supernodes
>>* gcc/analyzer/program-point.cc : refactor 
>> program point to work with new call-string format
> 
> The "gcc/analyzer" directory has its own ChangeLog file, and filenames
> should be expressed relative to it, so these entries should read
> something like:
> 
> gcc/analyzer/ChangeLog:
>   * call-string.cc : ...etc
>   * call-string.h: ...etc
>   * program-point.cc : ...etc
> 
> The entries should be sentences (i.e. initial capital letter and
> trailing full-stop).
> 
> They should be line-wrapped (I do it at 74 columns), giving this:
> 
> gcc/analyzer/ChangeLog:
>   * call-string.cc : Refactor callstring to work 
> with pair of
>   supernodes instead of superedges.
>   * call-string.h: Make callstring work with pairs of supernodes.
>   * program-point.cc : Refactor program point 
> to work with new
>   call-string format.
> 
> Your text editor might have a mode for working with ChangeLog files.

Yes, there is a way to wrap text after certain number of columns in my text 
editor, I would be using that from now on when working with changelogs.

> 
>   [...snip...]
> 
>> @@ -152,22 +152,40 @@ call_string::push_call (const supergraph &sg,
>>   gcc_assert (call_sedge);
>>   const return_superedge *return_sedge = call_sedge->get_edge_for_return 
>> (sg);
>>   gcc_assert (return_sedge);
>> -  m_return_edges.safe_push (return_sedge);
>> +  const std::pair *e = new 
>> (std::pair)
> 
> We don't want lines wider than 80 columns unless it can't be helped. 
> Does your text editor have a feature to warn you about overlong lines?
> 
> Changing from:
>  std::pair
> to:
>  element_t
> should make it much easier to avoid overlong lines.
> 
> [...snip...]
> 
>> diff --git a/gcc/analyzer/call-string.h b/gcc/analyzer/call-string.h
>> index 7721571ed60..0134d185b90 100644
>> --- a/gcc/analyzer/call-string.h
>> +++ b

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

[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/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.

- 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)
  ```
  #include 
  #include 
  
  void fun(int *int_ptr)
  {
  free(int_ptr);  /* { dg-warning "double-‘free’ of ‘int_ptr’" } */
  }
  
  void single_call()
  {
  int *int_ptr = (int*)malloc(sizeof(int));
  void (*fun_ptr)(int *) = &fun;
  (*fun_ptr)(int_ptr);
  }
  
  void double_call()
  {
  int *int_ptr = (int*)malloc(sizeof(int));
  void (*fun_ptr)(int *) = &fun;
  (*fun_ptr)(int_ptr);
  (*fun_ptr)(int_ptr);
  }
  
  /*{ dg-begin-multiline-output "" }
  6 | free(int_ptr);
| ^
‘double_call’: events 1-2
  |
  |   16 | void double_call()
  |  |  ^~~
  |  |  |
  |  |  (1) entry to ‘double_call’
  |   17 | {
  |   18 | int *int_ptr = (int*)malloc(sizeof(int));
  |  |  ~~~
  |  |  |
  |  |  (2) allocated here
  |
  +--> ‘fun’: events 3-6
 |
 |4 | void fun(int *int_ptr)
 |  |  ^~~
 |  |  |
 |  |  (3) entry to ‘fun’
 |  |  (5) entry to ‘fun’
 |5 | {
 |6 | free(int_ptr);
 |  | ~
 |  | |
 |  | (4) first ‘free’ here
 |  | (6) second ‘free’ here; first ‘free’ was at (4)
 |
  */
  ```
  (godbolt link )

  2. ( pr100546.c )
  ```
  #include 
  #include 
  
  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 )

- 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). 

---
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

Thank you
- Ankur

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

[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 )
> 
> 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 > >)
> 
> 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-*”.

ok

> 
> 
>> 
>>   2. ( pr100546.c <   
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100546 
>> >)
>>   ```
>>   #include 
>>   #include 
>>   
>>   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 > >)
>> 
>> - 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.

Yes, I used gdb on the analyzer to go into details and looks like I was 
correct, the program was crashing in “analysis_plan::use_summary_p ()” on line 
114 ( const cgraph_node *callee = edge->callee; ) where program was trying to 
access callgraph edge which didn’t exist .

I fixed it by simply making analyzer abort using call summaries in absence of 
callgraph edge.

File: {src-dir}/gcc/analyzer/analysis-plan.cc

105: bool
106: analysis_plan::use_summary_p (const cgraph_edge *edge) const
107: {
108:   /* Don't use call summaries if -fno-analyzer-call-summaries.  */
109:   if (!flag_analyzer_call_summaries)
110: return false;
111: 
112:   /* Don't use call summaries if there is no callgraph edge */
113:   if(!edge || !edge->callee)
114: return false;

and now the tests are passing successfully. ( both manually and via DejaGnu ).

I have attached a sample patch of work done till now with this mail for review 
( I haven’t sent this one to the patches list as it’s change log was not 
complete for now ).

P.S. I have also sent another mail ( 

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

[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. ( pr100546.c <   
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100546 < 
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100546>>)
   ```
   #include 
   #include 
   
   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 >)
 
 - 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.
>> 
>> Yes, I used gdb on the analyzer to go into details and looks like I was
>> correct, the program was crashing in “analysis_plan::use_summary_p ()”
>> on line 114 ( const cgraph_node *callee = edge->callee; ) where program
>> was trying to access callgraph edge which didn’t exist .
>> 
>> I fixed it by simply making analyzer abort using call summaries in
>> absence of callgraph edge.
>> 
>> File: {src-dir}/gcc/analyzer/analysis-plan.cc
>> 
>> 105: bool
>> 106: analysis_plan::use_summary_p (const cgraph_edge *edge) const
>> 107: {
>> 108:   /* Don't use call summaries if -fno-analyzer-call-summaries.  */
>> 109:   if (!flag_analyzer_call_summaries)
>> 110: return false;
>> 111: 
>> 112:   /* Don't use call summaries if there is no callgraph edge */
>> 113:   if(!edge || !edge->callee)
>> 114: return false;
>> 
>> and now the tests are passing successfully. ( both manually and via
>> DejaGnu ).
> 
> Great.
> 
>> 
>> I have attached a sample patch of work done till now with this mail for
>> review ( I haven’t sent this one to the patches list as it’s change log
>> was not complete for now ).
>> 
>> P.S. I have also sent another mail (   
>> https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575396.html <  
>> https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575396.html> ) to
>> patches list with the previous call-string patch and this time it
>> popped up in my inbox as it should, did you also received it now ?
> 
> I can see it in the archive URL, but for some reason it's not showing
> up in my inbox.  Bother.  Please can you try resending it directly to
> me?

Ok, I have sent the call-string patch directly to you. I have actually sent 2 
mails ( from different mail ids ) to check if it’s the id which is causing the 
issue or the contents of the mail itself.

> 
> Putting email issues to one side, the patch you linked to above looks
> good.  To what extent has it been tested?  If it bootstraps and passes
> the test suite, it's ready for trunk.

It bootstrapped successfully on a couple of the x86_64 machines ( on gcc farm ) 
And regress testing is underway.

> 
> Note that over the last couple of days I pushed my "use of
> uninitialized values" detection work to trunk (aka master), along with
> various other changes, so it's worth pulling master and rebasing on top
> of that before testing.  I *think* we've been touching different parts
> of the analyzer code, but there's a chance you might have to resolve
> some merge conflicts.

I have been constantly updating my branch as soon as I see a commit on analyzer 
( on patches list ) to avoid any conflicts. 
Till now I haven’t encountered any.

> 
> As for the patch you attached to this email
>  "[PATCH] analyzer: make analyer detect calls via function pointers"
> here's an initial review:

thanks for the review

> 
>> diff --git a/gcc/analyzer/analysis-plan.cc b/gcc/analyzer/analysis-plan.cc
>> index 7dfc48e9c3e..1c7e4d2cc84 100644
>> --- a/gcc/analyzer/analysis-plan.cc
>> +++ b/g

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

[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 created "dynamic_call_info_t" subclass reprsenting custom info on the edge 
representing the dynamically discovered calls 

- I overloaded it's "add_events_to_path ()" function to add call and return 
event to checkers path

- Now call_event and return_event subclasses mostly make use of the underlying 
interprocedural superedge representing the call to work properly. To tackle 
this problem, I used the same method I used for callstring patch earlier 
working with src and dest supernodes instead of superedge )

- The call_event subclass (and same applies to return_event subclass also) now 
have 2 additional pointers to source and destination supernodes representing 
the call in absense of a superedge. 

- I have also tweeked a few more things to make it work, I think the best way 
to show them all is to attach a patch ( it should be attached with this mail ) 
for just the changes I did today for better understanding on what exactly have 
I changed since last update. ( this patch would be squashed in previous one 
before the final review ).

- After all the changes done, now the analyzer emmits the following error 
message for the test program ( godbolt link https://godbolt.org/z/Td8n4c9a6 
 ), which I think now emmits all the events it 
was missing before.

```
test.c: In function ‘fun’:
test.c:6:9: warning: double-‘free’ of ‘int_ptr’ [CWE-415] 
[-Wanalyzer-double-free]
6 | free(int_ptr);
  | ^
  ‘double_call’: events 1-3
|
|   16 | void double_call()
|  |  ^~~
|  |  |
|  |  (1) entry to ‘double_call’
|   17 | {
|   18 | int *int_ptr = (int*)malloc(sizeof(int));
|  |  ~~~
|  |  |
|  |  (2) allocated here
|   19 | void (*fun_ptr)(int *) = &fun;
|   20 | (*fun_ptr)(int_ptr);
|  | ~~~
|  |  |
|  |  (3) calling ‘fun’ from ‘double_call’
|
+--> ‘fun’: events 4-5
   |
   |4 | void fun(int *int_ptr)
   |  |  ^~~
   |  |  |
   |  |  (4) entry to ‘fun’
   |5 | {
   |6 | free(int_ptr);
   |  | ~
   |  | |
   |  | (5) first ‘free’ here
   |
<--+
|
  ‘double_call’: events 6-7
|
|   20 | (*fun_ptr)(int_ptr);
|  | ~^~
|  |  |
|  |  (6) returning to ‘double_call’ from ‘fun’
|   21 | (*fun_ptr)(int_ptr);
|  | ~~~
|  |  |
|  |  (7) calling ‘fun’ from ‘double_call’
|
+--> ‘fun’: events 8-9
   |
   |4 | void fun(int *int_ptr)
   |  |  ^~~
   |  |  |
   |  |  (8) entry to ‘fun’
   |5 | {
   |6 | free(int_ptr);
   |  | ~
   |  | |
   |  | (9) second ‘free’ here; first ‘free’ was at (5)
   |
```

---
STATUS AT THE END OF THE DAY :- 

- Add custom edge info to the eedges created for dynamically discovered calls 
(done )
- Add the custom events to be showing in diagnostics (done)
- update call_event and return_event to also work for the cases where there is 
no underlying superedge representing the call (done)

--- 
Question / doubt :- 

- In "case EK_RETURN_EDGE” of "diagnostic_manager::prune_for_sm_diagnostic ()” 
function. 

File:{source_dir}/gcc/analyzer/diagnostic-manager.cc
2105:   log ("event %i:"
2106:" recording critical state for %qs at return"
2107:" from %qE in caller to %qE in callee",
2108:idx, sval_desc.m_buffer, callee_var, callee_var);

shouldn’t it be 

2107:" from %qE in caller to %qE in callee",
2108:idx, sval_desc.m_buffer, caller_var, callee_var);

and get value of caller_var before ? will they always be same ?

---
Patch representing changes done today :-



Thank you
- Ankur

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

[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 sent the final callstring patch after sucessfully bootstraping and running 
the regress tests on it with no unexpected fails/passes. This time I wrote the 
mail manually(instead of using git send-mail) and attached the patch file with 
it.

- while testing this on various examples I created, I found out the following : 

1. vtable (which I guess looks something like _ZTV1 in GIMPLE 
representation ) is either inside the contructor of the function or ( if 
default constructor is not overloaded ) in the function where the instance of 
the class is created.

2. when called ( call looks something like this OBJ_TYPE_REF(_3;(struct <
classname>)a_7->0) (a_7); ) we get the name of the class which functions is 
being called and the index in vtable where address is taken.

- Although at first I though it was imposible to get the info about the 
functions the vtable is holding by just looking at it's GIMPLE ir, after a 
little digging in ipa-devirt.c I found out that aprantly compiler's front end 
actually attaches this information ( known as BINFO ) with every tree (
RECORD_TYPE) which can be used to acess info about the same. ( I will be diggin 
more about it to see the extect to which I can use this BINFO to the project's 
advantage )

- So maybe the new region should hold a collection ( maybe vector ?) of cgraph 
nodes of the functions present in the vtable, which will be evaluated when the 
analyzer tries to find the function decl of the dynamically dicovered call.

- The problem arrises when we have a base class pointer and we don't exactly 
know which subclasse's method is being called. 

In a previous discussion 
(https://gcc.gnu.org/pipermail/gcc/2021-April/235335.html 
),
a possible plan to tackle this was to "potentially have the analyzer speculate 
about the subclasses it knows about, adding exploded edges to speculated calls 
for the various subclasses." But I would like look a bit more into ipa-devirt, 
especially possible_polymorphic_call_targets() function ( which seems to do 
most of the work similar to what we want to do ) to find something to overcome 
this problem.

---
STATUS AT THE END OF THE DAY :- 

- Send the callstring patch to the patches list after sucessfull bootstrap and 
regress test ( done )
- Create some basic examples to see how virtual function are being called ( 
done )
- Layout a basic `vtable_region : public region` subclass to store vtables 
found till now ( started )

Thank you
- Ankur

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

[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.

---
PROGRESS :

The plan is to use functions GCC's devirtualiser to directly find out possible 
targets functions that can be called when a virtual function is called and then 
let analyzer analyzer every single one of them by creating enodes and eedges. 

- I expanded upon my last update ( detecting calls via function pointers ), and 
figured out that in case of a vfunc call, the regional model would not be able 
to find a fn_decl for the given gcall. ( i.e. 
model->get_fndecl_for_call(call,&ctxt) would return NULL ).

- The only function I want to use from the ipa-devirt was 
possible_polymorphic_call_targets () { declared in ipa-utils.h:114, this 
function basically returns a vector of cgraph_nodes representing the possible 
callee's of an indirect polymorphic call (represented by a cgraph_edge) }, and 
to use that I needed the cgraph_edge representing the call. 

- In case of a vfunc call, we would have an indirect call edge ( an edge where 
callee is not known as compiletime ) which I obtained from the gimple call of 
the stmt.

- After that I confirmed if it is a polymorphic call or not (condition: 
edge->indirect_info->polymorphic should be exist )

- Once made sure that it's a vfunc call the analyzer is looking at, I simplay 
used the possible_polymorphic_call_targets () function to get a vector for all 
the possible targets it can call. 

- The results were amazing, not only the analyzer was now able to figure out 
which functions can be called for simple cases, but the fact that ipa-devirt 
also uses it's inheritance graph to search for possible calls was making it 
possible for analyzer(who doesn't understand inheritance yet) to even correctly 
detect calls that were happening via a base class pointer. :)

- Now all that is left is to make the analyzer speculate those calls by 
creating enodes and eedges for the calls ( similar to how it does in case for 
function pointers ).

---
STATUS AT THE END OF THE DAY :- 

- get the analyzer figure out which function to call when a vritual function is 
called. ( done )

Thank you
- Ankur

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

[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 from ipa-devirt.c ), All that was left was it to create enodes and 
  eedges for analyzeing such calls for which I took the same aproach I used to 
  detect and analyzer calls via function pointers. 

- now the analyzer was sucessfully decting and analyzing the calls via 
  functions pointers, but due to some reason it was still not giving out 
  analysis reports for such calls. 

- After a bit of digging, I found out that analyzer was also treating such 
  calls as " call to unknown funcitons " and in case of such calls, analyzer 
  plays safe by resetting all of the state-machine state for the values that 
  are reachable by the function call, to avoid false reports. ( it was also 
  mentioned in a previous discussions 
 on the list)

- I fixed the porblem by simply updating exploded_node::on_stmt () by setting
  the value of "unknown_side_effects" ( a boolean which is set true when
  analyzer thinks executing a gimple stmt would cause some side effects, and 
  acts conservatively for such cases ) to "false" when gimple call stmt is a 
  polymorphic call. Some thing like this, at the end of the definition of 
  exploded_node::on_stmt (): -

File: {src-dir}/gcc/analyzer/engine.cc
1246: /* If the statmement is a polymorphic call then assume 
1247:there are no side effects.  */
1248: gimple *call_stmt = const_cast(stmt);
1249: if (gcall *call = dyn_cast (call_stmt))
1250: {
1251:   function *fun = this->get_function();
1252:   cgraph_edge *e = cgraph_node::get (fun->decl)->get_edge (call);
1253:   if ((e && e->indirect_info) && (e->indirect_info->polymorphic))
1254: unknown_side_effects = false;
1255: }
1256: 
1257:   on_stmt_post (stmt, state, unknown_side_effects, &ctxt);
1258: 
1259:   return on_stmt_flags ();

- After this the analyzer was working as expected for virtual function calls on
  all of the examples I created. 

- Let's take example of the following program ( the same program which was
  mentioned in proposal, for which analyzer was giving out a false positive )

File: test.cpp
01: #include 
02: 
03: struct A
04: {
05: virtual int foo (void) 
06: {
07: return 42;
08: }
09: };
10: 
11: struct B: public A
12: {
13: int *ptr;
14: void alloc ()
15: {
16: ptr = (int*)malloc(sizeof(int));
17: }
18: int foo (void) 
19: { 
20: free(ptr);
21: return 0;
22: }
23: };
24: 
25: int test()
26: {
27: struct B b, *bptr=&b;
28: b.alloc();
29: bptr->foo();
30: return bptr->foo();
31: }
32: 
33: int main()
34: {
35: test();
36: }
37: 
( godbolt link of the above code (https://godbolt.org/z/n17WK4MxG) )

for the same porgram, the analyzer now generates the following warning message :

warning: double-‘free’ of ‘b.B::ptr’ [CWE-415] [-Wanalyzer-double-free]
   20 | free(ptr);
  | ^
  ‘int test()’: events 1-2
|
|   25 | int test()
|  | ^~~~
|  | |
|  | (1) entry to ‘test’
|..
|   28 | b.alloc();
|  | ~
|  ||
|  |(2) calling ‘B::alloc’ from ‘test’
|
+--> ‘void B::alloc()’: events 3-4
   |
   |   14 | void alloc ()
   |  |  ^
   |  |  |
   |  |  (3) entry to ‘B::alloc’
   |   15 | {
   |   16 | ptr = (int*)malloc(sizeof(int));
   |  | ~~~
   |  |   |
   |  |   (4) allocated here
   |
<--+
|
  ‘int test()’: events 5-6
|
|   28 | b.alloc();
|  | ~~~^~
|  ||
|  |(5) returning to ‘test’ from ‘B::alloc’
|   29 | bptr->foo();
|  | ~~~
|  |  |
|  |  (6) calling ‘B::foo’ from ‘test’
|
+--> ‘virtual int B::foo()’: events 7-8
   |
   |   18 | int foo (void)
   |  | ^~~
   |  | |
   |  | (7) entry to ‘B::foo’
   |   19 | {
   |   20 | free(ptr);
   |  | ~
   |  | |
   |  | (8) first ‘free’ here
   |
<--+
|
  ‘int test()’: events 9-10
|
|   29 | bptr->foo();
|  | ~^~
|  |  |
|  |  (9) returning to ‘test’ from ‘B::fo

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

[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 
dynamically discovered calls as I found myself using the exact same peice of 
code again to analyse vfunc calls.

2. Boostaraping and testing of these changes are underway.

3. Regarding the regress tests that have to be added to test functionality of 
vfunc extension patch :
Should I add many test files for different types of inheritences or should I 
add one ( or two ) test files, with a lot of fucntions in them testing 
different 
types of calls ?

---
Patches :


fn_ptr.patch
Description: Binary data


v_table.patch
Description: Binary data


Thank you 
- Ankur

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

[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 analyzer kind of 
"devirtualise" polymorphic calls to give a single accurate fn_decl of the 
possible target .
This makes it possible to fix the part where I had to make analyzer assume a 
call to have no side effect when it is a polymorphic call when analysing a call 
stmt.

- The way analyzer is more capable to see through a polymorphic call is the 
fact that state of the expoloded node at the time of call knows what subclass 
the pointer which is being used to call a vfunc is actually pointing to.
( here is an example showing the same https://godbolt.org/z/8MWx58dWo )

- So currently I am working on a way to extract this info from the state and 
use it to find the most accurate target amongst all possible targets of a 
polymorphic call we already have, and let the analyzer only call one function 
at the callsite.
Current idea is to evaluate both's ( the possible fn_decl and the pointee of 
the pointer used to call that is used to call vfunc ) DECL_CONTEXT to see if we 
find a match.

---
STATUS AT THE END OF THE DAY :- 

- Transfer the vfunc handling code to region_model::get_fndecl_for_call () 
(done )
- Filter out a possible targets of a polymorphic call to only one most porbable 
target ( pending )

Thank you
- Ankur

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

[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 possible functions that can be called at that callsite.

—

PROGRESS :

- 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 used to call the virtual function.

- We can access it's region to see what is the type of the object the pointer 
is actually pointing to.

- This is then used to find a call with DECL_CONTEXT of the object from the all 
the possible targets of that polymorphic call.

- The changes can be tested on refs/users/arsenic/heads/polymorphic_cal branch 
of the repository.

- I tested the changes with on the following test program ( 
https://godbolt.org/z/fqrsE1d84 )

And it successfully provided the following analysis :

```
/Users/ankursaini/Desktop/test.cpp: In member function ‘virtual int 
B::deallocate()’:
/Users/ankursaini/Desktop/test.cpp:25:13: warning: double-‘free’ of ‘b.B::ptr’ 
[CWE-415] [-Wanalyzer-double-free]
   25 | free(ptr);
  | ^
  ‘void test()’: events 1-2
|
|   35 | void test()
|  |  ^~~~
|  |  |
|  |  (1) entry to ‘test’
|..
|   40 | b.allocate();
|  | 
|  |   |
|  |   (2) calling ‘B::allocate’ from ‘test’
|
+--> ‘void B::allocate()’: events 3-4
   |
   |   19 | void allocate ()
   |  |  ^~~~
   |  |  |
   |  |  (3) entry to ‘B::allocate’
   |   20 | {
   |   21 | ptr = (int*)malloc(sizeof(int));
   |  | ~~~
   |  |   |
   |  |   (4) allocated here
   |
<--+
|
  ‘void test()’: events 5-6
|
|   40 | b.allocate();
|  | ~~^~
|  |   |
|  |   (5) returning to ‘test’ from ‘B::allocate’
|   41 | foo(aptr);
|  | ~  
|  ||
|  |(6) calling ‘foo’ from ‘test’
|
+--> ‘void foo(A*)’: events 7-8
   |
   |   30 | void foo(A *a_ptr)
   |  |  ^~~
   |  |  |
   |  |  (7) entry to ‘foo’
   |   31 | {
   |   32 | printf("%d\n",a_ptr->deallocate());
   |  | ~~
   |  |   |
   |  |   (8) calling ‘B::deallocate’ from ‘foo’
   |
   +--> ‘virtual int B::deallocate()’: events 9-10
  |
  |   23 | int deallocate (void)
  |  | ^~
  |  | |
  |  | (9) entry to ‘B::deallocate’
  |   24 | {
  |   25 | free(ptr);
  |  | ~
  |  | |
  |  | (10) first ‘free’ here
  |
   <--+
   |
 ‘void foo(A*)’: event 11
   |
   |   32 | printf("%d\n",a_ptr->deallocate());
   |  | ~~^~~~
   |  |   |
   |  |   (11) returning to ‘foo’ from ‘B::deallocate’
   |
<--+
|
  ‘void test()’: events 12-13
|
|   41 | foo(aptr);
|  | ~~~^~
|  ||
|  |(12) returning to ‘test’ from ‘foo’
|..
|   45 | foo(aptr);
|  | ~
|  ||
|  |(13) calling ‘foo’ from ‘test’
|
+--> ‘void foo(A*)’: events 14-15
   |
   |   30 | void foo(A *a_ptr)
   |  |  ^~~
   |  |  |
   |  |  (14) entry to ‘foo’
   |   31 | {
   |   32 | printf("%d\n",a_ptr->deallocate());
   |  | ~~
   |  |   |
   |  |   (15) calling ‘B::deallocate’ from ‘foo’
   |
   +--> ‘virtual int B::deallocate()’: events 16-17
  |
  |   23 | int deallocate (void)
  |  | ^~
  |  | |
  |  | (16) entry to ‘B::deallocate’
  |   24 | {
  |   25 | free(ptr);
  |  | ~

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

[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_5(D)->0) (a_ptr_5(D))"
>> where "a_ptr_5(D)" is pointer that is being used to call the virtual
>> function.
>> 
>> - We can access it's region to see what is the type of the object the
>> pointer is actually pointing to.
>> 
>> - This is then used to find a call with DECL_CONTEXT of the object
>> from the all the possible targets of that polymorphic call.
> 
> [...]
> 
>> 
>> Patch file ( prototype ) : 
>> 
> 
>> +  /* Call is possibly a polymorphic call.
>> +  
>> + In such case, use devirtisation tools to find 
>> + possible callees of this function call.  */
>> +  
>> +  function *fun = get_current_function ();
>> +  gcall *stmt  = const_cast (call);
>> +  cgraph_edge *e = cgraph_node::get (fun->decl)->get_edge (stmt);
>> +  if (e->indirect_info->polymorphic)
>> +  {
>> +void *cache_token;
>> +bool final;
>> +vec  targets
>> +  = possible_polymorphic_call_targets (e, &final, &cache_token, true);
>> +if (!targets.is_empty ())
>> +  {
>> +tree most_propbable_taget = NULL_TREE;
>> +if(targets.length () == 1)
>> +return targets[0]->decl;
>> +
>> +/* From the current state, check which subclass the pointer that 
>> +   is being used to this polymorphic call points to, and use to
>> +   filter out correct function call.  */
>> +tree t_val = gimple_call_arg (call, 0);
> 
> Maybe rename to "this_expr"?
> 
> 
>> +const svalue *sval = get_rvalue (t_val, ctxt);
> 
> and "this_sval"?

ok

> 
> ...assuming that that's what the value is.
> 
> Probably should reject the case where there are zero arguments.

Ideally it should always have one argument representing the pointer used to 
call the function. 

for example, if the function is called like this : -

a_ptr->foo(arg);  // where foo() is a virtual function and a_ptr is a pointer 
to an object of a subclass.

I saw that it’s GIMPLE representation is as follows : -

OBJ_TYPE_REF(_2;(struct A)a_ptr_5(D)->0) (a_ptr_5, arg);

> 
> 
>> +
>> +const region *reg
>> +  = [&]()->const region *
>> +  {
>> +switch (sval->get_kind ())
>> +  {
>> +case SK_INITIAL:
>> +  {
>> +const initial_svalue *initial_sval
>> +  = sval->dyn_cast_initial_svalue ();
>> +return initial_sval->get_region ();
>> +  }
>> +  break;
>> +case SK_REGION:
>> +  {
>> +const region_svalue *region_sval 
>> +  = sval->dyn_cast_region_svalue ();
>> +return region_sval->get_pointee ();
>> +  }
>> +  break;
>> +
>> +default:
>> +  return NULL;
>> +  }
>> +  } ();
> 
> I think the above should probably be a subroutine.
> 
> That said, it's not clear to me what it's doing, or that this is correct.


Sorry, I think I should have explained it earlier.

Let's take an example code snippet :- 

Derived d;
Base *base_ptr;
base_ptr = &d;
base_ptr->foo();// where foo() is a virtual function

This genertes the following GIMPLE dump :- 

Derived::Derived (&d);
base_ptr_6 = &d.D.3779;
_1 = base_ptr_6->_vptr.Base;
_2 = _1 + 8;
_3 = *_2;
OBJ_TYPE_REF(_3;(struct Base)base_ptr_6->1) (base_ptr_6);

Here instead of trying to extract virtual pointer from the call and see which 
subclass it belongs, I found it simpler to extract the actual pointer which is 
used to call the function itself (which from observation, is always the first 
parameter of the call) and used the region model at that point to figure out 
what is the type of the object it actually points to ultimately get the actual 
subclass who's function is being called here. :)

Now let me try to explain how I actually executed it ( A lot of assumptions 
here are based on observation, so please correct me wherever you think I made a 
false interpretation or forgot about a certain special case ) :

- once it is confirmed that the call that we are dealing with is a polymorphic 
call ( via the cgraph edge representing the call ), I used the 
"possible_polymorphic_call_targets ()" from ipa-utils.h ( defined in 
ipa-devirt.c ), to get the possible callee of that call. 

  function *fun = get_current_function ();
  gcall *stmt  = const_cast (call);
  cgraph_edge *e = cgraph_node::get (fun->decl)->get_edge (stmt);
  if (e->indirect_info->polymorphic)
  {
void *cache_token;
bool final;
vec  targets
  = possible_polymorphic_call_targ

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

[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 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 used to call the
 virtual
 function.
 
 - We can access it's region to see what is the type of the object
 the
 pointer is actually pointing to.
 
 - This is then used to find a call with DECL_CONTEXT of the object
 from the all the possible targets of that polymorphic call.
>>> 
>>> [...]
>>> 
 
 Patch file ( prototype ) : 
 
>>> 
 +  /* Call is possibly a polymorphic call.
 +  
 + In such case, use devirtisation tools to find 
 + possible callees of this function call.  */
 +  
 +  function *fun = get_current_function ();
 +  gcall *stmt  = const_cast (call);
 +  cgraph_edge *e = cgraph_node::get (fun->decl)->get_edge (stmt);
 +  if (e->indirect_info->polymorphic)
 +  {
 +void *cache_token;
 +bool final;
 +vec  targets
 +  = possible_polymorphic_call_targets (e, &final,
 &cache_token, true);
 +if (!targets.is_empty ())
 +  {
 +tree most_propbable_taget = NULL_TREE;
 +if(targets.length () == 1)
 +   return targets[0]->decl;
 +
 +/* From the current state, check which subclass the
 pointer that 
 +   is being used to this polymorphic call points to, and
 use to
 +   filter out correct function call.  */
 +tree t_val = gimple_call_arg (call, 0);
>>> 
>>> Maybe rename to "this_expr"?
>>> 
>>> 
 +const svalue *sval = get_rvalue (t_val, ctxt);
>>> 
>>> and "this_sval"?
>> 
>> ok
>> 
>>> 
>>> ...assuming that that's what the value is.
>>> 
>>> Probably should reject the case where there are zero arguments.
>> 
>> Ideally it should always have one argument representing the pointer
>> used to call the function. 
>> 
>> for example, if the function is called like this : -
>> 
>> a_ptr->foo(arg);  // where foo() is a virtual function and a_ptr is a
>> pointer to an object of a subclass.
>> 
>> I saw that it’s GIMPLE representation is as follows : -
>> 
>> OBJ_TYPE_REF(_2;(struct A)a_ptr_5(D)->0) (a_ptr_5, arg);
>> 
>>> 
>>> 
 +
 +const region *reg
 +  = [&]()->const region *
 +  {
 +switch (sval->get_kind ())
 +  {
 +case SK_INITIAL:
 +  {
 +const initial_svalue *initial_sval
 +  = sval->dyn_cast_initial_svalue ();
 +return initial_sval->get_region ();
 +  }
 +  break;
 +case SK_REGION:
 +  {
 +const region_svalue *region_sval 
 +  = sval->dyn_cast_region_svalue ();
 +return region_sval->get_pointee ();
 +  }
 +  break;
 +
 +default:
 +  return NULL;
 +  }
 +  } ();
>>> 
>>> I think the above should probably be a subroutine.
>>> 
>>> That said, it's not clear to me what it's doing, or that this is
>>> correct.
>> 
>> 
>> Sorry, I think I should have explained it earlier.
>> 
>> Let's take an example code snippet :- 
>> 
>> Derived d;
>> Base *base_ptr;
>> base_ptr = &d;
>> base_ptr->foo();// where foo() is a virtual function
>> 
>> This genertes the following GIMPLE dump :- 
>> 
>> Derived::Derived (&d);
>> base_ptr_6 = &d.D.3779;
>> _1 = base_ptr_6->_vptr.Base;
>> _2 = _1 + 8;
>> _3 = *_2;
>> OBJ_TYPE_REF(_3;(struct Base)base_ptr_6->1) (base_ptr_6);
> 
> I did a bit of playing with this example, and tried adding:
> 
> 1876  case OBJ_TYPE_REF:
> 1877gcc_unreachable ();
> 1878break;
> 
> to region_model::get_rvalue_1, and running cc1plus under the debugger.
> 
> The debugger hits the "gcc_unreachable ();", at this stmt:
> 
> OBJ_TYPE_REF(_2;(struct Base)base_ptr_5->0) (base_ptr_5);
> 
> Looking at the region_model with region_model::debug() shows:
> 
> (gdb) call debug()
> stack depth: 1
>  frame (index 0): frame: ‘test’@1
> clusters within frame: ‘test’@1
>  cluster for: Derived d
>key:   {bytes 0-7}
>value: ‘int (*) () *’ {(&constexpr int (* Derived::_ZTV7Derived 
> [3])(...)+(sizetype)16)}
>  cluster for: base_ptr_5: &Derived d.
>  cluster for: _2: &‘foo’
> m_called_unknown_fn: FALSE
> cons

[GSoC] Want to know more about the status of cp-demangle project

[Ankur Saini via Gcc]

I can see the project to make Cp-demangler non recursive being assigned and
accepted in GSoC 2021 project list on https://gcc.gnu.org/wiki/SummerOfCode
but no link of the work product or status of the same anywhere.

I even searched a bit in mailing list archives but still wasn't able to
find anything useful.

May I have some info about the status of the project, or a place where I
may find some info about the same ?

Thanks
Ankur

Re: GSoC: Working on the static analyzer

[Ankur Saini via Gcc]

The following can be a possible example of a case where the analyzer fails
to understand POSIX file-descriptor API.

- - -
#include 
#include 

void test()
{
int fd;
fd = open("foo.txt", O_RDONLY | O_CREAT);
}

void test_2()
{
FILE *f;
f = fopen("demo.c", "r");
}

godbolt link: https://godbolt.org/z/vbTq6fTnd
- - -

You can see that unlike the "File *” pointer ( f ), analyzer is not
tracking integer file descriptor ( fd ) which is also leaking at the end of
function "test ()” and should ideally be reported with CWE-775
( https://cwe.mitre.org/data/definitions/775.html )

If you look at the exploded graph of the given program, the analyzer is not
able to identify the call to `open ()` and treating it as a "call to
unknown function”.

- Ankur

Re: syslog: ISO C does not support the ‘%m’ gnu_printf format

[Ankur Saini via Gcc]

> On 25-Jan-2022, at 9:38 AM, Kris Andersen via Gcc  wrote:
> 
> The %m format specifier is a documented feature of syslog, but gcc gives a
> warning when -Wpedantic is used. Is this a bug?
> 
> For example, the program:
> 
> #include 
> int main(void)
> {
>syslog(LOG_ERR, "%m");
>return 0;
> }
> 
> gives:
> warning: ISO C does not support the ‘%m’ gnu_printf format [-Wformat=]

I think, the compiler is correct by complaining about it when strict
warnings are enabled.

according to GNU documentation
(http://www.gnu.org/software/libc/manual/html_node/Other-Output-Conversions.html)

“ The ‘%m’ conversion is a GNU C Library extension “

> 
> when compiled[1] with
> gcc -Wall -Wextra -Wpedantic -o test test.c
> 
> The man page for syslog(3) states that %m is supported: "the two-character
> sequence %m will be replaced by the error message string strerror(errno)."
> 
> Submitting a bug report for this feels like arguing that the answer in the
> back of the book is wrong (...rarely the right move). What am I missing
> here?

FWIW, A bug report requesting support for __format__ attribute for
syslog is already filed as bug 15338 (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15338 )

Thanks
- Ankur

[GSoC]Bypass assembler when generating LTO object files

[Ankur Saini via Gcc]

Hi,

I was browsing the list of submitted GSoC projects this year and the
project regarding bypassing assembler when generating LTO object files
caught my eye.

I already have a gcc built from source (sync-ed with trunk/master) and
launched the test-suite on it.

I am currently in process of understanding the primilary patch
(https://gcc.gnu.org/legacy-ml/gcc/2014-09/msg00340.html), and
experimenting with it.

are there any other things I should be aware of (useful Doc/blog or a
bug tracking the project) before proceeding further ?

I am Ankur Saini, a B.Tech CSE 3rd year student at USICT, GGSIPU india
and a former GSoC contributor at gcc ( worked on expanding gcc static
analyzer's C++ support in GSoC 2021
[https://gist.github.com/Arsenic-ATG/8f4ac194f460dd9b2c78cf51af39afef])

Thanks
- Ankur

Re: [GSoC]Bypass assembler when generating LTO object files

[Ankur Saini via Gcc]

> On 08-Apr-2022, at 6:32 PM, Jan Hubicka  wrote:
> 
> Ankur,
>> I was browsing the list of submitted GSoC projects this year and the
>> project regarding bypassing assembler when generating LTO object files
>> caught my eye.
> I apologize for late reply.  I would be very happy to mentor this
> project.

Thanks for the reply, but unfortunately, due to some reasons, I would not
be able to take part in GSoC this year.  
But the project seems interesting and would be amazing opportunity to
learn a lot more things for me, so would it be okay if I try to give it a
go outside GSoC if no-one else picks it as their GSoC project this year ?

>> 
>> I already have a gcc built from source (sync-ed with trunk/master) and
>> launched the test-suite on it.
>> 
>> I am currently in process of understanding the primilary patch
>> (https://gcc.gnu.org/legacy-ml/gcc/2014-09/msg00340.html), and
>> experimenting with it.
>> 
>> are there any other things I should be aware of (useful Doc/blog or a
>> bug tracking the project) before proceeding further ?
> 
> I think it is pretty much all that exists.  Basically we will need to
> implement everything that is necessary to stream out valid object file
> directly from GCC rather than going through gas.  The experimental
> prototype sort of worked but it was lacking few things.

When I try to apply that patch on my local branch ( branched from trunk ),
it seem to be incompatible with the current working tree. Is there a
specific branch that I have to apply it to ? or is it due to the recent
file rename patch ( changing extensions from .c to .cc ) ? 

```
$ git apply --check bypass_asm_patch

error: patch failed: Makefile.in:1300
error: Makefile.in: patch does not apply
error: common.opt: No such file or directory
error: langhooks.c: No such file or directory
error: lto/Make-lang.in: No such file or directory
error: lto/lto-object.c: No such file or directory
error: lto/lto.c: No such file or directory
error: lto/lto.h: No such file or directory
error: lto-streamer.h: No such file or directory
error: toplev.c: No such file or directory
```

Thanks 
- Ankur 

Updating patch regarding bypassing assembler when generating LTO object files

[Ankur Saini via Gcc]

Hi,
I have been fiddling around with the patch regarding "bypassing assmebler
while generating slim lto files" and managed to make it build with the
current trunk. Though the patch seems to be working on Linux machine, it
causes an ICE on macOS (it crashes in langhooks.cc while executing
`lhd_begin_section ()`).

here is the patch ( not fully tested and is still a prototype ), I
basically mimicked the entire previous patch (
https://gcc.gnu.org/legacy-ml/gcc/2014-09/msg00340.html ) but on current
source.

- Ankur

--- 

From e5d72a73962c34dcd818c17d440eb98ddd94e624 Mon Sep 17 00:00:00 2001
From: Ankur Saini 
Date: Sun, 8 May 2022 07:03:51 +0530
Subject: [PATCH] bypass-asm prototype: 1

---
 gcc/Makefile.in |  1 +
 gcc/common.opt  |  3 +++
 gcc/langhooks.cc| 29 +++-
 gcc/{lto => }/lto-object.cc | 29 +---
 gcc/lto-streamer.h  | 35 ++
 gcc/lto/Make-lang.in|  4 ++--
 gcc/lto/lto-common.cc   |  3 ++-
 gcc/lto/lto-lang.cc |  1 +
 gcc/lto/lto.h   | 38 -
 gcc/toplev.cc   | 19 ---
 10 files changed, 110 insertions(+), 52 deletions(-)
 rename gcc/{lto => }/lto-object.cc (94%)

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 31ff95500c9..3d1241d5819 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1509,6 +1509,7 @@ OBJS = \
lto-section-out.o \
lto-opts.o \
lto-compress.o \
+   lto-object.o \
mcf.o \
mode-switching.o \
modulo-sched.o \
diff --git a/gcc/common.opt b/gcc/common.opt
index 8a0dafc522d..6348197380d 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1158,6 +1158,9 @@ fbtr-bb-exclusive
 Common Ignore
 Does nothing.  Preserved for backward compatibility.
 
+fbypass-asm=
+Common Joined Var(flag_bypass_asm)
+
 fcallgraph-info
 Common RejectNegative Var(flag_callgraph_info) Init(NO_CALLGRAPH_INFO);
 Output callgraph information on a per-file basis.
diff --git a/gcc/langhooks.cc b/gcc/langhooks.cc
index df970678a08..abfab7a27e0 100644
--- a/gcc/langhooks.cc
+++ b/gcc/langhooks.cc
@@ -38,6 +38,10 @@ along with GCC; see the file COPYING3.  If not see
 #include "stor-layout.h"
 #include "cgraph.h"
 #include "debug.h"
+#include "function.h"
+#include "basic-block.h"
+#include "gimple.h"
+#include "lto-streamer.h"
 
 /* Do nothing; in many cases the default hook.  */
 
@@ -820,6 +824,19 @@ lhd_begin_section (const char *name)
 {
   section *section;
 
+  if (flag_bypass_asm)
+{
+  static int initialized = false;
+  if (!initialized)
+   {
+ gcc_assert (asm_out_file == NULL);
+  lto_set_current_out_file (lto_obj_file_open (asm_file_name, true));
+ initialized = true;
+   }
+  lto_obj_begin_section (name);
+  return;
+}
+
   /* Save the old section so we can restore it in lto_end_asm_section.  */
   gcc_assert (!saved_section);
   saved_section = in_section;
@@ -836,8 +853,13 @@ lhd_begin_section (const char *name)
implementation just calls assemble_string.  */
 
 void
-lhd_append_data (const void *data, size_t len, void *)
+lhd_append_data (const void *data, size_t len, void *v)
 {
+  if (flag_bypass_asm)
+{
+  lto_obj_append_data (data, len, v);
+  return;
+}
   if (data)
 {
   timevar_push (TV_IPA_LTO_OUTPUT);
@@ -854,6 +876,11 @@ lhd_append_data (const void *data, size_t len, void *)
 void
 lhd_end_section (void)
 {
+  if (flag_bypass_asm)
+{
+  lto_obj_end_section ();
+  return;
+}
   if (saved_section)
 {
   switch_to_section (saved_section);
diff --git a/gcc/lto/lto-object.cc b/gcc/lto-object.cc
similarity index 94%
rename from gcc/lto/lto-object.cc
rename to gcc/lto-object.cc
index 329bbc71fd6..8ccc917a4eb 100644
--- a/gcc/lto/lto-object.cc
+++ b/gcc/lto-object.cc
@@ -21,9 +21,17 @@ along with GCC; see the file COPYING3.  If not see
 #include "config.h"
 #include "system.h"
 #include "coretypes.h"
-#include "tm.h"
+#include "tree.h"
+#include "basic-block.h"
+#include "tree-ssa-alias.h"
+#include "internal-fn.h"
+#include "gimple-expr.h"
+#include "is-a.h"
+#include "function.h"
+#include "gimple.h"
 #include "diagnostic-core.h"
-#include "lto.h"
+#include "tm.h"
+#include "lto-streamer.h"
 #include "lto-section-names.h"
 #include "simple-object.h"
 
@@ -133,7 +141,13 @@ lto_obj_file_open (const char *filename, bool writable)
 }
   else
 {
-  gcc_assert (saved_attributes != NULL);
+  if (!saved_attributes)
+{
+  lto_file *tmp = lto_obj_file_open (flag_bypass_asm, false);
+  if (!tmp)
+goto fail;
+  lto_obj_file_close (tmp);
+}
   lo->sobj_w = simple_object_start_write (saved_attributes,
  LTO_SEGMENT_NAME,
  &errmsg, &err);
@@ -148,7 +162,8 @@ fail_errmsg:
 error ("

Re: GDC environment variable

[Ankur Saini via Gcc]

I do see make using ‘GDC' while building gcc compiler, maybe try changing that ?

- Ankur

> On 07-Dec-2022, at 11:42 AM, Dave Blanchard  wrote:
> 
> Is there an environment variable like 'CC' or 'CXX', which specifies the name 
> of the D compiler to use, which I might need to set when bootstrapping GCC? 
> Thanks.
> 
> -- 
> Dave Blanchard 

Re: Seeking to contribute to your organisation

[Ankur Saini via Gcc]

That wiki page also recommends to "put "GSoC" somewhere to the
subject”.  
Doing so should improve visibility of the message and make
it reach those who filter out GSoC related mails and ultimately help
you getting a faster and better reply from the community. :)

- Ankur

> On 09-Feb-2023, at 8:37 PM, shivansh khare via Gcc  wrote:
> 
> Hello,
> 
> I would like to ask whether I could be part of the upcoming GSoC. I have
> been wanting to contribute to the project for some time now and I think
> that this would be a nice opportunity for that.
> 
> I have looked into the different starter projects that are offered in the
> [Wiki GSoC page](https://gcc.gnu.org/wiki/SummerOfCode) and I was
> particularly interested in the `-ftime-trace` project. The following is
> what is given as a short description about the problematic:
> "Implement something similar to Clang's -ftime-trace feature which
> generates performance reports that show where the compiler spends compile
> time. For more information, please check the following blog post. There's
> also an existing bugzilla entry for this (if this becomes a GSoC project,
> the assignee will of course change). Required skills include C/C++ and
> finding a way through a large code-base."
> 
> I am looking forward to your response.
> 
> Best regards,
> Shivansh Khare

Re: GSOC 2023 Contribution Request

[Ankur Saini via Gcc]

Hi,

I am neither the org-admin for GSoC, nor a mentor for any of the
proposed projects. Just a community member like you.

Here are a few things you can do till the time you get a response from
either of those:

- Try building gcc from source if you haven't till now, refer the docs
  https://gcc.gnu.org/install/ for detailed information and try
  building with bootstrap disabled if you want to save some time. Also
  it is recommended to build a debuggable version ( see next point for
  details ) so that you can efficiently use a debugger to step through
  the source code.

- Once you have a proper version built from source, you can now use a
  debugger ( preferably gdb ) on it to get better understanding of the
  control flow. You can read the official docs (
  https://gcc.gnu.org/wiki/DebuggingGCC#gccbuilddebug ) or the
  gcc-newbies-guide by David Malcolm (
  https://gcc-newbies-guide.readthedocs.io/en/latest/debugging.html )
  for more information and instructions about debugging gcc.

- Speaking of gcc-newbies-guide by David Malcolm, it is actually an
  amazing source to get started for new-comers (
  https://gcc-newbies-guide.readthedocs.io/en/latest/index.html )

Although Google is yet to announce list of selected
organizations. Most of the stuff I mentioned is already present in the
"Before you apply" (
https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply ) section of
gcc's summer of code page.

- Ankur

> On 13-Feb-2023, at 7:04 PM, Kritika Rag via Gcc  wrote:
> 
> Hello Sir/Mam,
> 
> 
> 
> I’m Kritika Rag, a Computer Science pre-final year undergraduate student
> from India. I’m quite passionate about web development and competitive
> programming and now I’m looking forward to contributing to open-source
> projects. I believe that GSOC 2023 would provide me with the best way to
> start my open-source contribution journey.
> 
> 
> 
> Since I’m a competitive programmer, I have excellent command over Data
> Structures & Algorithms and my primary language is C++, so C++ and GCC are
> something that I use daily, therefore I would love to make my contributions
> to GCC projects. After going through all the projects listed on GCC Wiki
> , these are the
> projects(any one of them) to which I would like to contribute:
> 
>   1. Bug Patrol and primarily Analyze Failing Test Cases – Whether I'm
>   practicing algorithms on Leetcode, GFG, etc., or giving CP contests on
>   CodeChef, Codeforces, etc., Test case failures are something I encounter
>   daily. Working on the project would be an interesting dig for me to learn
>   about the inner workings of something that I see daily and make
>   improvements to it.
>   2.  Library Infrastructure - As quoted *"These tasks are about improving
>   the utility routine library used by GCC. If you like data structures, these
>   may be for you", *and being a data structures enthusiast I do believe
>   that I'll be able to put my best knowledge to use in this project.
> 
> Lastly, thank you so much for providing these opportunities, I would be
> grateful if you would provide me the opportunity to work with your
> organization. Looking forward to hearing from you soon.
> 
> Thanks and Regards,
> Kritika Rag
> 
> 
> 
> Sent from Mail  for Windows

Re: GCC 12.3 Released

[Ankur Saini via Gcc]

I think you can do that by via

https://gcc.gnu.org/mailman/listinfo/gcc-announce

> On 09-May-2023, at 7:34 PM, Hemlata Chelwani via Gcc  wrote:
> 
> how can i unsubscribe ?
> Best Regards,
> Hemlata Chelwani
> 
> 
> On Mon, 8 May 2023 at 18:52, Richard Biener via gcc-announce <
> gcc-annou...@gcc.gnu.org> wrote:
> 
>> The GNU Compiler Collection version 12.3 has been released.
>> 
>> GCC 12.3 is the first bug-fix release from the GCC 12 branch containing
>> important fixes for regressions and serious bugs in GCC 12.2 with more
>> than 127 bugs fixed since the previous release.
>> 
>> This release is available from the WWW servers listed here:
>> 
>> https://sourceware.org/pub/gcc/releases/gcc-12.3.0/
>> https://gcc.gnu.org/mirrors.html
>> 
>> Please do not contact me directly regarding questions or comments
>> about this release.  Instead, use the resources available from
>> http://gcc.gnu.org.
>> 
>> As always, a vast number of people contributed to this GCC release
>> -- far too many to thank them individually!
>>