GSoC: Working on the static analyzer

Hi everyone, I intend to work on the static analyzer. Are these documents enough to get started: https://gcc.gnu.org/onlinedocs/gccint and https://gcc.gnu.org/onlinedocs/gccint/Analyzer-Internals.html#Analyzer-Internals . Thank you.

Re: GSoC: Working on the static analyzer

rote: > On Tue, 2022-01-11 at 11:03 +0530, Mir Immad via Gcc wrote: > > Hi everyone, > > Hi, and welcome. > > > I intend to work on the static analyzer. Are these documents enough to > > get > > started: https://gcc.gnu.org/onlinedocs/gccint and > > > h

Re: GSoC: Working on the static analyzer

accept SARIF files as an >> *input* format, and emit them as diagnostics; that might help with >> debugging SARIF output. (I have a old patch for adding JSON parsing >> support to GCC that could be used as a starting point for this). >> >> Hope the above makes

Re: GSoC: Working on the static analyzer

gt; all of the static analyzer's output is passing through the > > > > diagnostics > > > > subsystem - though the static analyzer is probably the only GCC > > > > component generating diagnostic paths. > > > > > > > > I'm happy to

Re: GSoC: Working on the static analyzer

> > > On Fri, 2022-01-14 at 22:15 +0530, Mir Immad wrote: > > > > > > > HI David, > > > > > > > I've been tinkering with the static analyzer for the last > > > > > > > few > > > > > > > days. I &

Re: Compiling GCC source

Make sure to use all the cores available. make -j N e.g; make -j 8 On Mon, Feb 7, 2022, 12:26 AM Mohamed Atef via Gcc wrote: > Hello everyone, > I built gcc from the repo and it took around 2 hours but I am > wondering should I wait two hours after every modification? > Is there any w

Re: Compiling GCC source

Yes, that is right. On Mon, Feb 7, 2022, 12:38 AM Mohamed Atef wrote: > Hello, > Only modified files will be recompiled, won't it? > > > في الأحد، ٦ فبراير، ٢٠٢٢ ٩:٠٥ م Mir Immad كتب: > >> Make sure to use all the cores available. >> >> make -j N >> >> e.g; make -j 8 >> >> >> On Mon, Feb

Re: Compiling GCC source

The build system probably first tries to make sure if everything is in place and if there were any changes and re-compiles the new/changed files. How much time does it take when you try to rebuild? On Mon, Feb 7, 2022, 12:43 AM Mohamed Atef wrote: > After i built it > I tried make - j 8 and it'

Re: GSoC: Working on the static analyzer

t;> > > > > analyzer >> > > > > should >> > > > > have done) so that I can attempt to add such a checker to the >> > > > > analyzer. >> > > > > >> > > > > Also, I didn't realize the complexity o

Re: GSoC: Working on the static analyzer

> > > > > when I > > > > > > > > mentioned > > > > > > > > it. > > > > > > > > I'd rather work on adding more checkers. > > > > > > > > > > > > > > Fair enough. > > > > > > > >

GSoC proposal for extending static analyzer

I've submitted a proposal for extending the static analyzer to support posix fd APIs on GSoC website. Here is the Google docs link (gdocs ). Please take a look and let me know what you think. Thank

Re: GSoC proposal for extending static analyzer

I've updated the link on the repo -- https://mirimmad.github.io/zeta-lang. > You don't give many specifics in your personal decription. One thing > I'm not seeing is a sense of how proficient you are in various > programming languages. In particular, how is your C and C++? How > familiar are yo

GSoC: Getting started

HI everyone, I'm Immad Mir -- one of the GSoC students this year. I'll be working on adding static analysis support for POSIX file description APIs this summer. The plan is to let the static analyzer know about the FD APIs through the use of function attributes, although initially we might hardco

[PATCH] static analysis support for posix file desccriptor APIs

diff --git a/gcc/Makefile.in b/gcc/Makefile.in index b6dcc45a58a..04631f737ea 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -1269,6 +1269,7 @@ ANALYZER_OBJS = \ analyzer/region-model-reachability.o \ analyzer/sm.o \ analyzer/sm-file.o \ + analyzer/sm-fd.o \ analyzer/sm-malloc.o \

Re: [PATCH] static analysis support for posix file desccriptor APIs

This is a patch for extending static analysis support for posix file descriptor APIs which is a part of my GSoC project. I've written a few testcases, which are all passing. There are a few TODOs like adding the copyright header and adding docs to gcc/doc/invoke.texi. I'm looking for suggestions

Re: [PATCH] static analysis support for posix file desccriptor APIs

Hi Dave, Thanks for the suggestions, I changed most of the things that you suggested, however reporting for warnings like close of known invalid fd was problematic: consider the following code: if (fd >= 0) { write (fd,...); } close(fd); As I was checking the exploded graph for this; the "clos

[PATCH] analyzer PR 106003

diff --git gcc/Makefile.in gcc/Makefile.in index b6dcc45a58a..04631f737ea 100644 --- gcc/Makefile.in +++ gcc/Makefile.in @@ -1269,6 +1269,7 @@ ANALYZER_OBJS = \ analyzer/region-model-reachability.o \ analyzer/sm.o \ analyzer/sm-file.o \ + analyzer/sm-fd.o \ analyzer/sm-malloc.o \ analyzer

[PATCH] analyzer PR 106003

diff --git a/gcc/Makefile.in b/gcc/Makefile.in index b6dcc45a58a..04631f737ea 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -1269,6 +1269,7 @@ ANALYZER_OBJS = \ analyzer/region-model-reachability.o \ analyzer/sm.o \ analyzer/sm-file.o \ + analyzer/sm-fd.o \ analyzer/sm-malloc.o \

Re: [PATCH] analyzer PR 106003

Thanks for the suggestions, Dave. +} > + else > +{ > + /* FIXME: add leak reporting */ > +} > +} > + > Please add a testcase for this, with an "xfail" in the dg-warning > directive. I fixed it and made other suggested changes. All the tests (for fds) are passing. Sending an up

[PATCH] analyzer PR 106003

diff --git a/gcc/Makefile.in b/gcc/Makefile.in index b6dcc45a58a..04631f737ea 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -1269,6 +1269,7 @@ ANALYZER_OBJS = \ analyzer/region-model-reachability.o \ analyzer/sm.o \ analyzer/sm-file.o \ + analyzer/sm-fd.o \ analyzer/sm-malloc.o \

[PATCH] PR 106003

>From 62b7b7736975172f03b30783436fbc9217324223 Mon Sep 17 00:00:00 2001 From: mir Date: Sat, 2 Jul 2022 15:04:37 +0530 Subject: [PATCH] analyzer: implement five new warnings for misuse of POSIX file descriptor APIs [PR106003]. This patch adds a new state machine to the analyzer for checking usag

Re: [PATCH] PR 106003

Hi everyone, This is a patch for PR 106003 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003; tested on x86_64. On Sat, Jul 2, 2022 at 7:34 PM Mir Immad wrote: > From 62b7b7736975172f03b30783436fbc9217324223 Mon Sep 17 00:00:00 2001 > From: mir > Date: Sat, 2 Jul 2022 15:04:37 +0530 > Subjec

Re: [PATCH] PR 106003

Thank you. I've committed the patch, and it is covered by the Developer Certificate of Origin (DCO). Immad. On Sat, Jul 2, 2022 at 9:02 PM David Malcolm wrote: > On Sat, 2022-07-02 at 19:34 +0530, Mir Immad wrote: > > From 62b7b7736975172f03b30783436fbc9217324223 Mon Sep 17 00:00:00 2001 > > F

Re: [PATCH] filedescriptor attribute

Hi everyone, This is an in-progress patch for adding three new function attributes to GCC for static analysis of file descriptor APIs (which is a part of my GSoC project) 1) __attribute__((accesses_fd(N))) This attribute expected argument N of a function to be an open file descriptor. (see test_

Re: Adding file descriptor attribute(s) to gcc and glibc

Hi everyone, Reading through the thread, I feel the following attributes look good and similar to what I've done: __attribute__ ((fd_arg(N))) __attribute__ ((fd_arg_read(N))) __attribute__ ((fd_arg_write(N))) I believe how to annotate the glibc headers is a separate discussion. Dave: From the