Following last mail, a classic I forgot to link my draft ! https://docs.google.com/document/d/1MaLDo-Rt8yrJIvC1MO8SmFc6fp4eRQM_JeSdv-1kbsc/edit?usp=sharing
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}. >
