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