Re: GSoC project

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 projec

GSoC 2021 - Static analyzer project

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 coupl

Re: GSoC 2021 - Static analyzer project

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

Re: static analysis above GCC (GSoC 2021)

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

Re: GSoC 2021 - Static analyzer project

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

Re: GSoC 2021 - Static analyzer project

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

Re: GSoC 2021 gcc analyzer project

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

Re: Welcome GCC GSoC 2021 participants

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

Re: Welcome GCC GSoC 2021 participants

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

progress update after initial GSoC virtual meetup

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 singl

Re: progress update after initial GSoC virtual meetup

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

Re: progress update after initial GSoC virtual meetup

> 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

progress update

> 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

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

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

daily report on extending static analyzer project [GSoC]

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 cre

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AIM for today : - update the call_string to store a vector of pair of supernode* instead of pointer to it - create a typdef to give a meaning full name to these " pair of supernode* “ - send the patch list to gcc-patches mailing list - add the example program I created to the GCC tests — PROG

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

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

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

> > On 11-Jul-2021, at 11:19 PM, David Malcolm wrote: > > On Sat, 2021-07-10 at 21:27 +0530, Ankur Saini wrote: >> AIM for today : >> >> - update the call_string to store a vector of pair of supernode* >> instead of pointer to it >> - create a typdef to give a meaning full name to these " pai

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

CURRENT STATUS OF PROJECT: - The analyzer can now sucessfully detect and analyze function calls that doesn't have a callgraph edge ( like a call via function pointer ) - A weird indentation problem caused by my text editor pointed out in one of the previous mails (https://gcc.gnu.org/piper

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

> On 15-Jul-2021, at 4:53 AM, David Malcolm wrote: > > On Wed, 2021-07-14 at 22:41 +0530, Ankur Saini wrote: >> CURRENT STATUS OF PROJECT: >> >> - The analyzer can now sucessfully detect and analyze function calls >> that >> doesn't have a callgraph edge ( like a call via function pointer

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 anyth

Re: GSoC: Working on the static analyzer

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

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

> 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

[GSoC]Bypass assembler when generating LTO object files

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 unders

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

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

Updating patch regarding bypassing assembler when generating LTO object files

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

Re: GDC environment variable

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 bootstrappi

Re: Seeking to contribute to your organisation

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

Re: GSOC 2023 Contribution Request

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

Re: GCC 12.3 Released

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