On Sat, 2023-04-01 at 01:33 +0200, Benjamin Priour wrote: > Hi David, > > > On Thu, Mar 30, 2023 at 2:04 AM David Malcolm <dmalc...@redhat.com> > wrote: > > I think working on the C++ enablement prerequisites in the analyzer > > would make more sense. I'd planned to do this myself for GCC 14, > > but > > there are plenty of other tasks I could work on if you want to > > tackle > > C++ support as a GSoC project for GCC 14. > > > > Yes, I gladly would.
Great. > > > > A good C++ project might be: enable enough C++ support in the > > analyzer > > for it to be able to analyze itself. This could be quite a large, > > difficult project, though it sidesteps having to support exception- > > handling, since we build ourselves with exception-handling > > disabled. > > > > Hope this is helpful > > Dave > > > > > To that purpose, the following order of resolutions would make sense > into > achieving that: > 0. An emphasis on reducing the amount of exploded nodes will have to > be put > from the beginning. All of my C++ samples produce graphs quite dense. 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. > 1. First thing first, extending the current C tests to cover C++ > PR96395 > <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96395> I wonder to what extent doing this would uncover issues that we don't yet know about with C++ support, so yes - a good one to do first. > (1.bis ) > 2. I would then go with supporting the options relative to sm-malloc: > - -Wanalyser-double-free should behave properly (cf the fresh} [...snip...] > Emits nothing. The state is 'nonnull' is properly tracked though > along the > constructors back to foo, so I will have to dive deeper into this > tomorrow. Indeed - you'll have to do a lot of looking at gimple IR dumps, what the supergraph looks like, etc, for all of this. > 3. Improve the scope of -Wanalyzer-null-dereference > - For the analyzer, -Wanalyzer[-possible]-null-dereference should > fully > support smart pointers. That is not the case currently (see PR109366 > <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109366> ), even though > shared > pointers are promising. Good point. > - For smart pointers, it might be necessary to review the > diagnostic > path, as for shared_ptr they are quite long already. Yeah. > 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) > > 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. Good luck! Dave
