Re: GSoC Static Analysis

On Wed, 2020-03-25 at 15:36 -0700, Andrew Briand via Gcc wrote: > Hello, > > I am an undergrad interested in extending GCC’s static analysis pass > for GSoC 2020. In particular, I’m interested in adding C++ support. Hi Andrew, thanks for your interest in the project. > The selected project

Blog post about static analyzer in GCC 10

I wrote a blog post "Static analysis in GCC 10" giving an idea of the current status of the -fanalyzer feature: https://developers.redhat.com/blog/2020/03/26/static-analysis-in-gcc-10/ At some point I'll write up the material for our changes.html page. Dave

Re: C (not C++) compiler plugins

On Fri, 2020-04-24 at 13:03 -0600, Maurice Smulders via Gcc wrote: > Hello, > > Hugo Landau figured out why it didn't load: > Yes. > > > The reference to cp_global_trees appears to be caused by the below > code, > which only relates to C++.

Re: Help porting a plugin to more recent GCC

On Tue, 2020-05-12 at 11:12 +0200, Sebastian Kürten wrote: > Hi everybody, > > I'm trying to adapt an existing, open source GCC plugin so that it > will > work with more recent versions of GCC (it is currently working with > 4.7 > only). During my research I came across your suggestion on the >

Re: New mklog script

On Fri, 2020-05-15 at 13:20 +0200, Martin Liška wrote: > On 5/15/20 12:58 PM, David Malcolm wrote: > > On Fri, 2020-05-15 at 10:59 +0200, Martin Liška wrote: > > > Hi. > > > > > > Since we moved to git world and we're in the preparation for > > > ChangeLog messages > > > being in git commit

Re: New mklog script

On Fri, 2020-05-15 at 10:59 +0200, Martin Liška wrote: > Hi. > > Since we moved to git world and we're in the preparation for > ChangeLog messages > being in git commit messages, I think it's the right time to also > simplify mklog > script. > > I'm sending a new version (which should eventually

Re: [GSoC] Extend the static analysis pass

On Tue, 2020-03-24 at 10:18 -0500, Nader Al Awar wrote: > Hello, > > I am a master's student at UT Austin and I am interested in working > on > extending the static analysis pass project as part of GSoC. Hello, I'm the author/maintainer of the static analysis pass, and would be the mentor for

Re: ERR: file not changed in a patch:"gcc/cp/cp-tree.c"

On Tue, 2020-05-19 at 13:03 -0600, Martin Sebor via Gcc wrote: > I'm having trouble with the commit hook that tries to enforce > ChangeLog contents. It fails with an error that doesn't make > sense to me: the file it complains isn't mentioned clearly is > listed there and I can't tell what about

Re: Three issues

On Tue, 2020-07-21 at 22:49 +, Gary Oblock via Gcc wrote: > Some background: > > This is in the dreaded structure reorganization optimization that I'm > working on. It's running at LTRANS time with '-flto-partition=one'. > > My issues in order of importance are: > > 1) In gimple-ssa.h, the

Re: gcc-backport problem on Debian 9

On Mon, 2020-07-13 at 08:39 +0200, Hans-Peter Nilsson via Gcc wrote: > Again, Debian 9. Doing "git gcc-backport a4aca1edaf37d43" on > releases/gcc-10 gave me: > > [releases/gcc-10 83cf5a7c6a5] PR94600: fix volatile access to the > whole of a compound object. > Date: Sun Jul 5 20:50:52 2020

Re: Passing an string argument to a GIMPLE call

On Sat, 2020-06-27 at 21:27 +0800, Shuai Wang via Gcc wrote: > Dear Richard, > > Thanks for the info. My bad, I will need to append "\0" at the end of > the > string. Also, a follow-up question which I just cannot find an > answer: > typically in the plugin entry point: > > virtual unsigned int

The encoding of GCC's stderr

As far as I can tell, GCC's diagnostic output on stderr is a mixture of bytes from various different places in our internal representation: - filenames - format strings from diagnostic messages (potentially translated via .po files) - identifiers - quoted source code - fix-it hints - labels As

Re: GCC GSoC 2021 - Static analyzer project

On Fri, 2021-01-22 at 20:46 +0530, Adharsh Kamath wrote: > Hi David. Thank you for the reply. > On Tue, Jan 19, 2021 at 2:12 AM David Malcolm > wrote: > > On Thu, 2021-01-14 at 10:45 +0530, Adharsh Kamath wrote: > > > Hello, > > > I came across the list of possible project ideas for GSoC 2021 > >

Re: GCC GSoC 2021 - Static analyzer project

On Thu, 2021-01-14 at 10:45 +0530, Adharsh Kamath wrote: > Hello, > I came across the list of possible project ideas for GSoC 2021 and > I'd > like to contribute to the project regarding the static analysis pass > in GCC. > How can I get started with this project? Hi Adharsh Sorry about the

Static analysis updates in GCC 11

I wrote a blog post covering what I've been working on in the analyzer in this release: https://developers.redhat.com/blog/2021/01/28/static-analysis-updates-in-gcc-11/ Hope this is of interest Dave

Re: Static analysis updates in GCC 11

On Thu, 2021-01-28 at 22:06 +0100, David Brown wrote: > On 28/01/2021 21:23, David Malcolm via Gcc wrote: > > I wrote a blog post covering what I've been working on in the > > analyzer > > in this release: > >   > > https://developers.redhat.com/blog/2021/01/28/

Re: progress update after initial GSoC virtual meetup

On Tue, 2021-06-08 at 21:20 +0530, Ankur Saini wrote: > > > > On 01-Jun-2021, at 6:38 PM, David Malcolm > > wrote: > > [...snip...] > > 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

Re: progress update after initial GSoC virtual meetup

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

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

On Mon, 2021-06-21 at 14:22 +0530, Ankur Saini wrote: > 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 >

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

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

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

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

Re: progress update

On Tue, 2021-06-15 at 19:42 +0530, Ankur Saini wrote: > > > > 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 > > > > mailto:dmalc...@redhat.com>> > > > > wrote:

[PATCH] MAINTAINERS: create DCO section; add myself to it

On Tue, 2021-06-01 at 10:00 -0400, David Edelsohn via Gcc wrote: > GCC was created as part of the GNU Project but has grown to operate > as > an autonomous project. > > The GCC Steering Committee has decided to relax the requirement to > assign copyright for all changes to the Free Software

Re: progress update after initial GSoC virtual meetup

On Sun, 2021-05-30 at 20:38 +0530, Ankur Saini wrote: > hello Hi Ankur, sorry about the delayed reply (it was a long weekend here in the US) > I was successfully able to build gcc with bootstrapping disabled and > using xgcc directly from the build directory instead ( reducing the > overall

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

On Wed, 2021-07-07 at 19:22 +0530, Ankur Saini wrote: > > > > 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 > > >

Re: where is PRnnnn required again?

On Wed, 2021-07-07 at 16:58 -0600, Martin Sebor via Gcc wrote: > On 7/7/21 4:24 PM, Jonathan Wakely wrote: > > > > > > On Wed, 7 Jul 2021, 23:18 Martin Sebor, > > wrote: > > > >     On 7/7/21 3:53 PM, Marek Polacek wrote: > > > I'm not sure why you keep hitting so

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

On Tue, 2021-06-29 at 22:04 +0530, Ankur Saini wrote: > 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 > > — > >

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

On Mon, 2021-06-28 at 20:23 +0530, Ankur Saini wrote: > > > > 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 ? > >

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

On Sat, 2021-06-26 at 20:50 +0530, Ankur Saini wrote: > > > 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 > > >

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

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

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

On Sun, 2021-07-11 at 22:31 +0530, Ankur Saini wrote: > 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 < >

Re: Benefits of using Sphinx documentation format

On Mon, 2021-07-12 at 15:25 +0200, Martin Liška wrote: > Hello. > > Let's make it a separate sub-thread where we can discuss motivation > why > do I want moving to Sphinx format. > > Benefits: > 1) modern looking HTML output (before: [1], after: [2]): "modern looking" is rather subjective; I'd

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

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

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

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

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

On Mon, 2021-07-05 at 21:45 +0530, Ankur Saini wrote: > 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 )

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

On Wed, 2021-06-30 at 21:39 +0530, Ankur Saini wrote: > > > > On 30-Jun-2021, at 1:23 AM, David Malcolm > > wrote: > > > > On Tue, 2021-06-29 at 22:04 +0530, Ankur Saini wrote: > > [...] > > > P.S. it has been over a week since I sent a mail to    > > > overse...@gcc.gnu.org 

RFC: attributes for marking security boundaries (system calls/ioctls, user vs kernel pointers etc)

I've been going through old Linux kernel CVEs, trying to prototype some possible new warnings for -fanalyzer in GCC 12 (and, alas, finding places where the analyzer internals need work...) I think I want a way for the user to be able to mark security boundaries in their code: for example: * in

Re: "musttail" statement attribute for GCC?

On Fri, 2021-04-23 at 12:44 -0700, Josh Haberman via Gcc wrote: > Would it be feasible to implement a "musttail" statement attribute in > GCC to get a guarantee that tail call optimization will be performed? > > Such an attribute has just landed in the trunk of Clang >

Re: Some really strange GIMPLE

On Tue, 2021-04-27 at 20:10 +, Gary Oblock via Gcc wrote: > I'm chasing a bug and I used Creduce to produce a > reduced test case. However, that's really beside to > point. > > I this file: > > typedef struct basket { > } a; > long b; > a *basket; > int d, c,

Re: GCC GSoC 2021 - Static analyzer project

On Thu, 2021-02-11 at 22:35 +0530, Adharsh Kamath wrote: > Hi David, > > > Building GCC from source and stepping through it in the > > debugger would be good next steps.  You'll need plenty of disk > > space. > >  "run_checkers" is a good breakpoint to set if you're looking for > > the > >

Re: Remove RMS from the GCC Steering Committee

On Fri, 2021-03-26 at 20:51 +, Jonathan Wakely via Gcc wrote: > On Fri, 26 Mar 2021, 20:03 Nathan Sidwell, wrote: > > > > > Dear members of the GCC Steering Committee (SC),  I ask you to > > remove > > Richard > > Stallman (RMS) from the SC, or, should you chose not to do so, make > > a > >

Re: [GSoC-2021] Interested in project `Extend the static analysis pass`

On Thu, 2021-03-25 at 14:52 +0530, Saloni Garg via Gcc wrote: > Hi all, > I am an undergraduate student in AMU, Aligarh. I am interested in the > project* `Extend the static analysis pass`. *I have followed this( > https://gcc.gnu.org/pipermail/gcc/2021-March/234941.html) and been > able to >

Re: [GSoC-2021] Interested in project `Extend the static analysis pass`

On Sun, 2021-03-28 at 18:06 +0530, Saloni Garg wrote: > Hi, I have tried the following examples with the fanalyzer option in > g++. > > 1 (a) > void myFunction() > { >     char *p =new char; > } > int main() > { >    func(); >    return 0; > } BTW, are you familiar with Compiler Explorer

Re: [GSoC-2021] Interested in project `Extend the static analysis pass`

On Tue, 2021-03-30 at 16:06 +0530, Saloni Garg wrote: > On Sun, Mar 28, 2021 at 8:03 PM David Malcolm > wrote: > > > On Sun, 2021-03-28 at 18:06 +0530, Saloni Garg wrote: > > > Hi, I have tried the following examples with the fanalyzer option > > > in > > > g++. > > > > > > 1 (a) > > > void

Re: GSoC 2021 - Static analyzer project

On Tue, 2021-03-30 at 16:36 +0530, Ankur Saini wrote: > 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

Re: Protest against removal of RMS from GCC Steering Committee

On Thu, 2021-04-01 at 17:23 +0200, Andrea G. Monaco wrote: > > I strongly disagree with the removal of Dr. Stallman from the > Steering > Committee. RMS was not removed from the GCC Steering Committee; his name was removed from the *web page* of the steering committee. Based on the discussion

Re: Interested In extend the static analysis pass

On Wed, 2021-03-31 at 16:59 +0530, Gagandeep Bhatia via Gcc wrote: > Hey Team GNU Compiler, I'm Gagandeep Bhatia, currently pursuing the > 2nd year at Christ University, Bangalore, India. You can reach me at > gagandeepbhatia2...@gmail.com  > or +919466935025.

Re: [GSoC-2021] Interested in project `Extend the static analysis pass`

On Wed, 2021-03-31 at 21:41 +0530, Saloni Garg wrote: > On Tue, Mar 30, 2021 at 6:42 PM David Malcolm > wrote: > > > On Tue, 2021-03-30 at 16:06 +0530, Saloni Garg wrote: > > > On Sun, Mar 28, 2021 at 8:03 PM David Malcolm < > > > dmalc...@redhat.com> > > > wrote: [...snip...] > > > > No,

Re: Remove RMS from the GCC Steering Committee

On Wed, 2021-03-31 at 16:18 +0200, Christopher Dimech via Gcc wrote: [...snip...] > As for the "safe spaces" phase, this is about eliminating anything > and > everything that could emotionally troubling students. This assumes a > high > degree of fragility among western students.  I work as a

[committed] MAINTAINERS: add myself as static analyzer maintainer

On Tue, 2021-03-23 at 08:44 -0600, Jeff Law wrote: > > I am pleased to announce that the GCC Steering Committee has > appointed > David Malcolm as maintainer of the GCC static analyzer. > > > David, please update your listing in the MAINTAINERS file. Thanks. I've pushed the following to

Re: GSoC 2021 - Static analyzer project

On Tue, 2021-04-06 at 17:56 +0530, Ankur Saini wrote: Hi Ankur. Various replies inline below throughout. > > 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 > > > ? > >

Re: GSoC project idea

On Thu, 2021-03-11 at 12:59 +0530, srishty bedi via Gcc wrote: > Greetings, Hi Srishty Various remarks inline below... > First of all Congratulations to the gcc community on being selected > for > GSOC 2021. > > My name is Srishty Bedi, I am a sophomore pursuing btech CSE in > India. .I > am

Re: [PATCH] docs: add interactive vs batch distinction to UX guidelines

On Mon, 2021-02-22 at 21:26 -0500, David Malcolm wrote: > On Sat, 2021-02-20 at 17:49 +0100, David Brown wrote: > > > > > > On 20/02/2021 16:46, David Malcolm wrote: > > > On Sat, 2021-02-20 at 15:25 +0100, David Brown wrote: > > > > > > > > > > I think we need to think about both of these

Re: GSOC-2021

On Sun, 2021-03-21 at 00:31 +0530, Namitha S via Gcc wrote: > Hi, > I am Namitha S, an undergrad from Amrita University. This mail is > regarding > GSOC-2021, I wanted to know more about the project "Extend the static > analysis pass". I've gone through the wiki and finished the tasks > listed >

Re: GSoC

Hi Isitha (and Philip!) If I'm reading Isitha's email correctly, it talks about static analysis, whereas Philip's talks about GCC Rust, so some wires got crossed somewhere. I'm the author of the GCC static analysis pass. I should confess that I still feel like I'm learning static analysis

Re: Constraints and branching in -fanalyzer

On Fri, 2021-02-26 at 04:23 +, brian.sobulefsky wrote: > Hi, > > I have implemented the discussed change, bootstrapped, and run the > testsuite. I > would be submitting except to my disappointment I saw failures > increase by 4. As > it turns out, these "failures" are actually passes that had

Re: Constraints and branching in -fanalyzer

On Sun, 2021-02-21 at 05:27 +, brian.sobulefsky wrote: > To be clear, I only solved the lesser problem > > if(idx-- > 0) >   __analyzer_eval(idx >= 0); > > which is a stepping stone problem. I correctly surmised that this was > failing > (with the prefix operator and -= operator working as

[PATCH] docs: add interactive vs batch distinction to UX guidelines

On Sat, 2021-02-20 at 17:49 +0100, David Brown wrote: > > > On 20/02/2021 16:46, David Malcolm wrote: > > On Sat, 2021-02-20 at 15:25 +0100, David Brown wrote: > > > > > > I think we need to think about both of these use-cases e.g. as we > > implement our diagnostics, and that we should

Re: GSoC 2021 - Static analyzer project

On Fri, 2021-03-05 at 17:04 +0530, Ankur Saini via Gcc wrote: > Hello, Hi Ankur > 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

Re: GCC association with the FSF

On Wed, 2021-04-07 at 10:51 -0400, Alfred M. Szmidt via Gcc wrote: >    [...]  That "gnu-stucture" document was written by RMS a couple of >    months ago and doesn't represent how the GNU project and its >    maintainers have worked for years. > > It reflects the same message that has been sent

Re: GCC association with the FSF

On Wed, 2021-04-07 at 00:22 +0200, Mark Wielaard wrote: > Hi, > > Lets change the subject now that this is about GCC and the FSF. > > On Wed, Mar 31, 2021 at 01:46:29PM +0100, Jonathan Wakely via Gcc > wrote: > > Probably unintentionally, but he has allowed the GNU Project to > > become > > a

Re: GCC association with the FSF

On Thu, 2021-04-08 at 20:21 +0200, John Darrington wrote: > On Thu, Apr 08, 2021 at 10:54:25AM -0400, David Malcolm wrote: [...] > Some of us don't want RMS in a leadership position in a project > we're > associated with (be it the FSF or GNU, and thus, GCC). > > RMS was the

Re: GCC association with the FSF

On Wed, 2021-04-07 at 18:24 +0200, John Darrington wrote: > On Wed, Apr 07, 2021 at 11:15:14AM -0400, David Malcolm via Gcc > wrote: > > > It reflects the same message that has been sent to new GNU > > maintainers > > for the decades. The GNU structur

Re: [GSoC-2021] Interested in project `Extend the static analysis pass`

On Wed, 2021-04-07 at 01:59 +0530, Saloni Garg wrote: > Hi, apologies for the delayed reply. I was having some college > commitments. > On Wed, Mar 31, 2021 at 11:22 PM David Malcolm > wrote: > > > On Wed, 2021-03-31 at 21:41 +0530, Saloni Garg wrote: > > > On Tue, Mar 30, 2021 at 6:42 PM David

Re: removing toxic emailers

On Thu, 2021-04-15 at 09:49 -0400, Eric S. Raymond wrote: > Joseph Myers : > > On Wed, 14 Apr 2021, Eric S. Raymond wrote: > > > > > I'm not judging RMS's behavior (or anyone else's) one way or > > > another. I am simply pointing out that there is a Schelling point > > > in > > > possible

Re: removing toxic emailers

On Thu, 2021-04-15 at 16:26 -0400, Chris Punches wrote: > What I see here in sum is another high level tightly integrated Red > Hat > employee saying the gist of "I'm really not saying it out of my > employer's interest and it has nothing to do with my personal > feelings". I'm not sure I'm "high

Re: Gcc as callable libraries (was: removing toxic emailers)

On Thu, 2021-04-15 at 17:31 -0400, David Malcolm via Gcc wrote: > On Thu, 2021-04-15 at 21:48 +0200, Thomas Koenig wrote: [...snip...] > >  > Perhaps a pronouncement like: "try to make everything be > > consumable as > >  > libraries with APIs, as well as as sta

Re: Gcc as callable libraries (was: removing toxic emailers)

On Thu, 2021-04-15 at 21:48 +0200, Thomas Koenig wrote: > David, > > for some reason or other, I did not get your mail, so I will > just reply copying in from the archive. > > First, thanks for injecting some sanity into the discussion. Thanks Thomas > I will not discuss RMS' personal

Re: [GSoC-2021] Interested in project `Extend the static analysis pass`

On Sun, 2021-04-11 at 17:06 +0530, Saloni Garg wrote: > On Sun, Apr 11, 2021 at 12:14 AM David Malcolm > wrote: > > > On Sat, 2021-04-10 at 21:18 +0530, Saloni Garg wrote: > > > On Thu, Apr 8, 2021 at 8:19 AM David Malcolm > > > > > > wrote: > > > > > > > On Wed, 2021-04-07 at 01:59 +0530,

Re: GCC association with the FSF

On Sat, 2021-04-10 at 08:17 -0700, Thomas Rodgers wrote: > On 2021-04-09 14:34, Christopher Dimech wrote: > > > > On the contrary, I eagerly await each and every one of your > > > missives > > > on > > > this topic, hoping for exactly that very  thing to occur. [...] > On 2021-04-10 07:49,

Re: [GSoC-2021] Interested in project `Extend the static analysis pass`

On Sat, 2021-04-10 at 21:18 +0530, Saloni Garg wrote: > On Thu, Apr 8, 2021 at 8:19 AM David Malcolm > wrote: > > > On Wed, 2021-04-07 at 01:59 +0530, Saloni Garg wrote: [...] > > Looking at: > >   https://gcc.gnu.org/wiki/SummerOfCode#Application > > we don't have a specific format to be

Re: On rms controversy

On Wed, 2021-04-14 at 08:01 +0100, Jonathan Wakely via Gcc wrote: > On Wed, 14 Apr 2021, 07:50 pawel k. via Gcc, wrote: > > [...snip...] > Very logical argument, thanks for sharing. Jonathan, it's clear to me that you're being sarcastic, but it might not be clear to others. Please avoid

Re: removing toxic emailers

On Sun, 2021-04-18 at 09:10 -0400, Eric S. Raymond wrote: Sorry for prolonging this thread-of-doom; I'm loathe to reply to Eric because I worry that it will encourage him. I wrote a long rebuttal to his last email to me about his great insights into the minds of women but didn't send it in the

Re: GCC association with the FSF

On Sun, 2021-04-11 at 14:07 +0100, Frosku wrote: > On Sun Apr 11, 2021 at 11:08 AM BST, Didier Kryn wrote: > > Le 08/04/2021 à 17:00, David Brown a écrit : > > > At some point, someone in the public relations > > > department at IBM, Google, Facebook, ARM, or other big supporters > > > of the > >

Re: GCC association with the FSF

On Thu, 2021-04-08 at 08:45 +0200, John Darrington wrote: > On Wed, Apr 07, 2021 at 06:34:12PM -0400, David Malcolm wrote: > > > > What you're describing sounds like a dictatorship to me. > > > > I cannot see how you reach that conclusion. > > Having

Constraints and branching in -fanalyzer

[Moving this discussion from offlist to the GCC mailing list (with permission) and tweaking the subject] On Sat, 2021-02-20 at 02:57 +, brian.sobulefsky wrote: > Yeah, its a lot to take in. For the last one, it was just about > storing and retrieving data and I ignored everything else about

Re: using undeclared function returning bool results in wrong return value

On Sat, 2021-02-20 at 15:25 +0100, David Brown wrote: > On 19/02/2021 12:18, Jonathan Wakely via Gcc wrote: > > On Fri, 19 Feb 2021 at 09:42, David Brown wrote: > > > Just to be clear - I am not in any way suggesting that this > > > situation is > > > the fault of any gcc developers.  If configure

Re: Analyzer tests fail on windows

On Mon, 2021-08-23 at 22:36 -0400, NightStrike wrote: > On Mon, Aug 23, 2021 at 8:16 PM NightStrike > wrote: > > On Mon, Aug 23, 2021 at 4:09 PM David Malcolm > > wrote: > > > Which tests are failing, specifically? > > Here's the full list of all 37 failures that fail for any reason: > > FAIL:

Re: Analyzer tests fail on windows

On Mon, 2021-08-23 at 09:52 -1000, NightStrike wrote: > David, > > Many of the analyzer tests fail on windows because they hardcode in > the > typedef of size_t to be unsigned long. This is not a platform > independent > definition, though, and is wrong for 64 bit windows. This causes > extra >

Re: Error when accessing git read-only archive

On Mon, 2021-09-13 at 14:03 +0100, Jonathan Wakely via Gcc wrote: > On Mon, 13 Sept 2021 at 14:01, Jonathan Wakely > wrote: > > > > On Mon, 13 Sept 2021 at 13:53, Thomas Koenig via Gcc < > > gcc@gcc.gnu.org> wrote: > > > > > > Hi, > > > > > > I just got an error when accessing the gcc git

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

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

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

On Mon, 2021-07-12 at 22:07 +0530, Ankur Saini wrote: > > > > On 11-Jul-2021, at 11:19 PM, David Malcolm > > wrote: > > > > On Sat, 2021-07-10 at 21:27 +0530, Ankur Saini wrote: [...] > > > > > > - for the callstring patch, I created a patch file ( using git > > > format- > > > patch ) and

Re: Noob question about simple customization of GCC.

On Wed, 2021-08-04 at 00:17 -0700, Alacaster Soi via Gcc wrote: > How hard would it be to add a tree-like structure and > headers/sections to > the -v gcc option so you can see the call structure. Would this be a > reasonable first contribution/customization for a noob? It'll be a > while > before

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

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

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

On Thu, 2021-07-29 at 18:20 +0530, Ankur Saini wrote: > 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

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

On Fri, 2021-07-30 at 18:11 +0530, Ankur Saini wrote: > > > > On 30-Jul-2021, at 5:35 AM, David Malcolm > > wrote: > > > > On Thu, 2021-07-29 at 18:20 +0530, Ankur Saini wrote: [..snip...] > > > > > > > > > @@ -1242,6 +1243,17 @@ exploded_node::on_stmt (exploded_graph , > > >

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

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

Re: Extracting function name from the gimple call statement

On Sun, 2021-10-10 at 23:04 +0530, Shubham Narlawar via Gcc wrote: > Hello, > > Is there a direct way to print the name of the function call in gimple > call > statement? > > For example - > > void bar() { > a = foo();    //gimple* stmt > } > > I want to print "foo" from the above gimple*.

Re: C-family selftests in language-independant source files

On Fri, 2021-11-05 at 10:38 +0100, cohenarthur.dev via Gcc wrote: > Hi everyone, > > We have been trying to enable the use of selftests for the rust > frontend > over at gccrs. While doing this, I have realized that a few tests from > language-independant source files such as `opt-problem.c` and

Re: odd internal failure

On Thu, 2021-12-02 at 12:40 +0100, Richard Biener via Gcc wrote: > On Wed, Dec 1, 2021 at 9:56 PM Gary Oblock > wrote: > > > > Richard, > > > > I rebuilt at "-O0" and that particular call now works but on a call > > to > > the same function with a different offset it fails.  > > use a

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

On Wed, 2021-07-21 at 21:44 +0530, Ankur Saini wrote: > > > > 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

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

On Thu, 2021-07-22 at 22:40 +0530, Ankur Saini wrote: > 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

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

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

Re: Mass rename of C++ .c files to .cc suffix?

On Fri, 2022-01-07 at 11:25 +0100, Martin Jambor wrote: > Hi, > > Would anyone be terribly against mass renaming all *.c files (that are > actually C++ files) within the gcc subdirectory to ones with .cc > suffix? > > We already have 47 files with suffix .cc directly in the gcc > subdirectory

Re: GCC GSoC 2022: Call for project ideas and mentors

On Thu, 2022-01-06 at 17:20 +0100, Martin Jambor wrote: > Hello, > > another year is upon us and Google has announced there will be again > Google Summer of Code 2022 (though AFAIK there is no specific timeline > yet).  I'd like to volunteer to be the main Org Admin for GCC again so > let me know

Re: Many analyzer failures on non-Linux system (x86_64-apple-darwin)

On Mon, 2022-01-10 at 17:13 +0100, FX wrote: > Hi David, > > May I kindly ping you on that? Or anyone with knowledge of the static > analyzer? Sorry about the delay in responding; I was on vacation and am still getting caught up. Various answers inline below... > > Thanks, > FX > > > > Le

Re: GSoC: Working on the static analyzer

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 >

Re: Request easy bug fix

On Tue, 2022-02-15 at 12:55 +, Jonathan Wakely via Gcc wrote: > On Tue, 15 Feb 2022 at 12:34, Baruch Burstein via Gcc < > gcc@gcc.gnu.org> > wrote: > > > Hi, > > > > I hope it is not inappropriate to call attention to a specific bug. > > https://gcc.gnu.org/bugzilla//show_bug.cgi?id=85487.

Re: GSoC: Working on the static analyzer

On Sun, 2022-02-13 at 21:16 +0530, Mir Immad wrote: > Hi, > > I wanted some clarification on bifurcating the exploded graph at call > to > open(). > Should the analyzer warn for code like this "when open fails" (like > strchr > does when  'strchr' returns NULL) > > int fd = open("NOFILE",

Re: GSoC: Working on the static analyzer

On Sun, 2022-02-13 at 17:57 -0500, David Malcolm wrote: > On Sun, 2022-02-13 at 21:16 +0530, Mir Immad wrote: > > Hi, > > > > I wanted some clarification on bifurcating the exploded graph at > > call > > to > > open(). > > Should the analyzer warn for code like this "when open fails" (like > >

  1   2   3   4   5   6   7   8   9   10   >