On Mon, 2023-04-03 at 18:46 +0200, Benjamin Priour wrote: > Following last mail, a classic I forgot to link my draft ! > https://docs.google.com/document/d/1MaLDo-Rt8yrJIvC1MO8SmFc6fp4eRQM_JeSdv-1kbsc/edit?usp=sharing
Some notes: * The document still has some notes in italics marked "[RFC]" which you'll want to fix before formally submitting it. * "Project Goals": item 4: you give a reproducer; perhaps add a link to godbolt.org (Compiler Explorer) demonstrating the overlong diagnostic path? * Part 1: as part of moving the test cases to c-c++-common you'll probably have to debug/write a little .exp code (in Tcl) so that it actually runs the tests, probably in analyzer.exp. So you might want to allow some time to read up on Tcl, which is the language our testsuite is written in (I wish it was in Python, but fixing that would be a different project, alas) * Part 2: your grep for unique_ptr found 2903 uses, but I guess many of these are in libstdc++-v3. As i understand it, this is compiled for the target (as a library for use by the compiler user), whereas I'm much more interested in the code below "gcc", which is compiled for the host into the compiler itself. You might want so split out these numbers. One task is to try adding -fanalyzer to the build flags for the compiler itself, and see what happens: is it usable? is it unusably slow on some of our source files? does it find true problems? does it report false positives? The current document suggests doing this in part 3 as the last 20% of the project; I think it makes more sense to do the initial attempt at this much earlier, to get an earlier idea of what the problems might be. "Motivation and Skill set": the first paragraph is poorly worded; for example the 2nd sentence seems to just stop halfway through. "Mentor": yes, I would be the mentor Other than that, looks good. The deadline for formally submitting this to the GSoC website is April 4th at 18:00 UTC (less than 24 hours from now), and Google are strict about this deadline. Good luck! Dave > > Best, > Benjamin. > > On Mon, Apr 3, 2023 at 6:44 PM Benjamin Priour <priour...@gmail.com> > wrote: > > > Hi David, > > > > On Mon, Apr 3, 2023 at 12:38 AM David Malcolm <dmalc...@redhat.com> > > wrote: > > > > > > > > To be fair, C ones can be as well; the analyzer's exploded graphs > > > tend > > > to get very big on anything but the most trivial examples. > > > > > > > > > > > [...snip...] > > > > > > > > > > Indeed - you'll have to do a lot of looking at gimple IR dumps, > > > what > > > the supergraph looks like, etc, for all of this. > > > > > > > > Yep. I have already tried my hands on them, but to be fair I'm > > still often > > troubled by them. Still, > > doing so have already provided essential insight on the analyzer. > > > > [...snip...] > > > > > > > > 4. Extension of out-of-bounds > > > > ( - Extending -Wout-of-bounds to the many vec<...> might be a > > > > requirement. > > > > However I have to look into more details for that one, I don't > > > > see > > > > yet how > > > > it could be done without a similar reuse of the assertions as > > > > for the > > > > libstdc++.) > > > > > > > > From what I saw, despite the bugs not being FIXED, vfuncs seem > > > > to be > > > > working nicely enough after the fix from GSoC 2021. > > > > > > IIRC I was keeping those bugs open because there's still a little > > > room > > > for making the analyzer smarter about the C++ type system e.g. if > > > we > > > "know" that a foo * is pointing at a particular subclass, maybe > > > we know > > > things about what vfunc implementations could be called. > > > > > > We could even try an analysis mode where we split the analysis > > > path at > > > a vfunc call, where we could create an out-edge in the egraph for > > > each > > > known concrete subclass for foo *, so that we can consider all > > > the > > > possible subclasses and the code that would be called. (I'm not > > > sure > > > if this is a *good* idea, but it intrigues me) > > > > > > > Like adding a flag to run in a non-standard mode, to debug when an > > unexpected vfunc analysis occurs ? TBH I didn't look that much into > > vfuncs > > support, as my dummy tests behave OK and I assumed it was fixed > > after last > > GSoC. > > > > > > > > > > > > > > > Unfortunately I couldn't devote as much time as I wanted to gcc > > > > yesterday, > > > > I plan to send a proposal draft tomorrow evening. Sincerely > > > > sorry for > > > > the > > > > short time frame before the deadline. > > > > > > Sound promising. Note that the deadline for submitting proposals > > > to > > > the official GSoC website is April 4 - 18:00 UTC (i.e. this > > > coming > > > Tuesday) and that Google are very strict about that deadline; > > > see: > > > https://developers.google.com/open-source/gsoc/timeline > > > > > > I believe you've already had a go at posting gcc patches to our > > > mailing > > > list: that's a great thing to mention in your application. > > > > > Thanks for the tip, I added it to my draft ! > > > > > > > > Good luck! > > > Dave > > > > > > Thanks ! BTW here is my draft proposal (in a google doc, I hope > > > this is > > OK). > > If you can find the time to give me some feedback (as always), I > > would > > greatly appreciate it ! > > Below I will dump the "project goals" part, so that it's openly > > available > > on the mail list. > > Note that I've annotated some sections with [RFC], it's for your > > easy-of-use when reviewing part I'm explicitly asking for feedback. > > Just do > > a Ctrl-F on the string [RFC] > > > > A bit out of context, but since you always sign your mails 'Dave', > > should > > I address you that way ? Unsure about that. > > > > Best, > > Benjamin. (see below for the dump) > > > > The aim of this project is to enable the analyzer to self-analyze > > itself. > > To do so, the following items should be implemented (m: minor, M: > > Major > > feature) > > > Generalize gcc.dg/analyzer tests to be run with both C and C++ > > > [PR96395] > > [M] > > > Support the options relative to checker sm-malloc > > -Wanalyser-double-free should behave properly for C++ > > allocations > > pairs new, new[], delete and delete[] both throwing and non- > > throwing > > versions. > > At the moment, only their non-throwing counterparts are > > somewhat > > handled, yet incorrectly as the expected -Wanalyzer-double-free is > > replaced > > by -Wanalyzer-use-after-free [m] and an incorrect > > -Wanalyzer-possible-null-dereference is emitted [fixed]. > > I filed it as bug PR109365 [2]. > > > Add support for tracking unique_ptr null-dereference [M]. While > > smart_ptr is correctly handled, the code snippet below demonstrates > > that > > this warning is not emitted for unique_ptr [4]. > > Figure 1 - First test case for unique_ptr support > > struct A {int x; int y;}; > > int main () { > > std::unique_ptr<A> a; > > a->x = 12; /* -Wanalyzer-null-dereference missing */ > > return 0; > > } > > > Improve the diagnostic path for the standard library, with > > > shared_ptr as > > a comparison point, so that they do not wander through the standard > > library > > code. [M] > > Figure 2 - Reproducer to demonstrate unnecessarily long diagnostic > > paths > > when using the standard library. > > struct A {int x; int y;}; > > int main () { > > std::shared_ptr<A> a; > > a->x = 4; /* Diagnostic path should stop here rather than going > > to > > shared_ptr_base.h */ > > return 0; > > } > > [RFC] I believe this could be a 350-hours project as time flies by > > quickly, but I’m more than open to your suggestions to support > > self-analysis. I’ve read your idea on splitting at vfunc points, > > I’m > > currently looking into it. > > An additional goal I have considered is to add out-of-bounds > > support for > > the auto_vec. This would include supporting templates, but a > > shallow > > testing on my box proved them to be somewhat handled already. > > > > May-be solved alongside > > > > > Support of new placements sizes, emitting warning on incorrect > > > pairing > > of placement new/delete, as part of goal {2}. > >
