GSoC proposal for extending static analyzer

[Mir Immad via Gcc]

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

Re: GSoC proposal for extending static analyzer

[David Malcolm via Gcc]

On Fri, 2022-04-15 at 19:58 +0530, Mir Immad wrote:
> 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
> <
> https://docs.google.com/document/d/188zxPUsuYcF-uGVYL_G1s2RVtHhJSZeQ4sha40H7374/edit?usp=sharing
> >).
> 
> 
> Please take a look and let me know what you think.
> 
> Thank you.

Thanks.

FWIW, I'm getting an error when trying the URL given in your github
repo: http://mirimmad.me/
but https://mirimmad.github.io/ seems to work  - but it's almost empty.

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 you with the debugger?  Looking at your github, you seem
to have relevant experience in compilers, which is great, but all your
code appears to be with "managed" languages such as Ruby, Java, and
Python  [and Zeta :)].

Also, the proposal is to extend the analyzer to cover a specific
domain: various POSIX APIs.  Can you please give a sense of your level
of expertise with these APIs?  I was pleased at your initiative in
trying to reuse the existing code to work with them.  That said, I got
the sense from your previous emails that you're not very familiar with
the APIs, and that you chose them because that was the suggestion I had
made on the wiki page.  Obviously it's something you can learn on the
way, but it would be better to accurately identify which areas you're
going need to learn along the way, and the timetable and scope should
reflect that.

Hope this is constructive
Dave

Re: GSoC proposal for extending static analyzer

[Mir Immad via Gcc]

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 you with the debugger?  Looking at your github, you seem
> to have relevant experience in compilers, which is great, but all your
> code appears to be with "managed" languages such as Ruby, Java, and
> Python  [and Zeta :)].

 I'm pretty comfortable with both C and C++ and manual mem management .
Unfortunately, I don't have any project in C/C++ to show. Maybe I can use
the time before May 20 to write something in cpp?
About the debugger, I'm okay-ish with it. In fact, it was due to the
debugger (and your blog on it) that I was initially able to walk through
the codebase.


> That said, I got
> the sense from your previous emails that you're not very familiar with
> the APIs, and that you chose them because that was the suggestion I had
> made on the wiki page.

thats right.


>  Obviously it's something you can learn on the
>  way, but it would be better to accurately identify which areas you're
> going need to learn along the way, and the timetable and scope should
> reflect that.

If I understand the statement correctly; currently I'm thinking of
extending the support for open() (for creating the fd), write/read (for
working on the fd) and close(). This is quite analogous to what we have in
sm-file. Please let me know how do you want the analyzer to be extended and
if you expect support for any other FD APIs  too as I understand there are
many other APIs for creating and working wiith FDs?

Thank you.



On Fri, Apr 15, 2022 at 9:35 PM David Malcolm  wrote:

> On Fri, 2022-04-15 at 19:58 +0530, Mir Immad wrote:
> > 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
> > <
> >
> https://docs.google.com/document/d/188zxPUsuYcF-uGVYL_G1s2RVtHhJSZeQ4sha40H7374/edit?usp=sharing
> > >).
> >
> >
> > Please take a look and let me know what you think.
> >
> > Thank you.
>
> Thanks.
>
> FWIW, I'm getting an error when trying the URL given in your github
> repo: http://mirimmad.me/
> but https://mirimmad.github.io/ seems to work  - but it's almost empty.
>
> 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 you with the debugger?  Looking at your github, you seem
> to have relevant experience in compilers, which is great, but all your
> code appears to be with "managed" languages such as Ruby, Java, and
> Python  [and Zeta :)].
>
> Also, the proposal is to extend the analyzer to cover a specific
> domain: various POSIX APIs.  Can you please give a sense of your level
> of expertise with these APIs?  I was pleased at your initiative in
> trying to reuse the existing code to work with them.  That said, I got
> the sense from your previous emails that you're not very familiar with
> the APIs, and that you chose them because that was the suggestion I had
> made on the wiki page.  Obviously it's something you can learn on the
> way, but it would be better to accurately identify which areas you're
> going need to learn along the way, and the timetable and scope should
> reflect that.
>
> Hope this is constructive
> Dave
>
>
>

GSoC thoughts on C++ static analyzer support

[Φώτης Βαλασιάδης via Gcc]

Hello all,

I am interested in said project, and I'd like to ask.

Is said project limited to providing static analysis for heap allocations
and file handles?  To be clear I am asking whether or not there are goals
beyond these two.

This pattern could pretty much be used for all resource-like objects such
as sockets, mutexes et cetera and point is that said problems in C++ are
already tackled by using RAII
. Now I understand that
RAII isn't always an option nor does it solve all problems (for example,
dangling references) so I am still fascinated by all of it and would like
to share my thoughts.

C++11 mutexes(locks, and generally speaking all thread header facilities)
could really use a static analyzer. Not only for the standard lock(),
unlock() checks but also for "enforcing" lock ordering and other important
guidelines. Read Anthony William's "Concurrency in Action" a while ago and
honestly if I had a compiler that performed all those checks he describes
in the book for me, which half of them I don't even remember anymore, THAT
would be something else.

Now I understand that this might be really complicated for a GSoC project,
but food for thought. Looking forward to hearing your thoughts on this.

Thanks for your time!

Re: GCC 11.3 Release Candidate available from gcc.gnu.org

[William Seurer via Gcc]

I tested the release candidate on power 7 and 8 BE as well as power 8, 
9, and 10 LE and saw nothing unexpected.


On 4/14/22 2:08 AM, Richard Biener via Gcc wrote:

The first release candidate for GCC 11.3 is available from

  https://gcc.gnu.org/pub/gcc/snapshots/11.3.0-RC-20220414/
  ftp://gcc.gnu.org/pub/gcc/snapshots/11.3.0-RC-20220414/

and shortly its mirrors.  It has been generated from git commit
r11-9879-g53254184bda630.

I have so far bootstrapped and tested the release candidate on
x86_64-linux.  Please test it and report any issues to bugzilla.

If all goes well, I'd like to release 11.3 on Thursday, April 21th.

gcc-10-20220415 is now available

[GCC Administrator via Gcc]

Snapshot gcc-10-20220415 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/10-20220415/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-10 revision 9646582e8e4f7b6ad01175ada9cc2482ba8007af

You'll find:

 gcc-10-20220415.tar.xz   Complete GCC

  SHA256=ca3f32cb053b98cc251cefc6341b011479d060fe74d525b2ef0e7fed42bde60a
  SHA1=772b1c5dbadbdc0eefc25d9f29438dbc22901383

Diffs from 10-20220408 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-10
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Request for comments : GSoC Project Proposal - Constant folding in Rust-GCC (Draft)

[M V V S Manoj Kumar via Gcc]

Greetings,
I am M V V S Manoj Kumar, an Open Source Contributor to Rust-GCC (GitHub
,  contributions
),
and I want to pursue a GSoC project regarding constant folding in Rust-GCC.
I have included the draft of my project proposal here
.
I would be grateful for any suggestions you have regarding it and will try
to implement them in my final submission.

Thank you.
M V V S Manoj Kumar
BTech Student, Electronics and Communication Engineering
Thapar Institute of Engineering and Technology
Patiala, Punjab
India