Hi David,
On Thu, Mar 30, 2023 at 2:04 AM David Malcolm <dmalc...@redhat.com> wrote: > Note that the analyzer doesn't properly work yet on C++; see: > https://gcc.gnu.org/bugzilla/showdependencytree.cgi?id=97110 > I'm hoping to address much of this in GCC 14. > > Other notes inline below... > > I'm guessing that the CFG and thus the supergraph contains edges for > handling exceptions, and the analyzer currently doesn't know anything > about these, and mishandled them: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97111 > > You might want to have a look at the supergraph (via -fdump-analyzer- > supergraph); I recently added more debugging notes here: > https://gcc.gnu.org/onlinedocs/gccint/Debugging-the-Analyzer.html > > If that's the case, then -fno-exceptions might affect the behavior. > > Thanks for the additional debugging tips! > > > > > > Another observation was in the distinction between delete and free in > > the > > case of mixing them. > > With 'a' being allocated with malloc: > > > A* a = (A*) malloc(sizeof(A)); > > > free(a); > > > delete a; // -Wanalyzer-use-after-free, OK, might expect warning > > > for > > double free though ? > > > > but with allocation through new and inversion of free/delete > > > A* a = new A(); > > > delete a; > > > free(a); // No diagnostics at all from the analyzer, got > > -Wmismatched-new-delete from the front-end though. > > > > I believe this might come from a similar issue as above, but I still > > have > > to investigate on that front. > > > > I just noticed another unexpected behavior. Let's consider > > > struct A {int x; int y;}; > > > void* foo() { A* a = (A*) __builtin_malloc(sizeof(A)); return a; } > > > int main() { > > > A* a2 = (A*) __builtin_malloc(sizeof(A)); > > > foo(); > > > return 0; > > > } > > > > Then a -Wanalyzer-malloc-leak is correctly ensued for allocation in > > foo(), > > but none is emitted for the leak in main(), although I checked the > > exploded > > graph it is correctly marked as unchecked(free). > > > > Should I file those on bugzilla ? > > > We already know that "C++ doesn't work yet". Minimal examples of > problems with C++ support might be worth filing, to isolate specific > issues. If you do, please add them to the tracker bug (by adding > "analyzer-c++" to the "Blocks" field of the new bug(s)) > > Sure will be doing that. > > > > > > Also I have taken interest in PR106388 - Support for use-after-move > > in > > -fanalyzer -. > > The prerequisite PR106386 - Reuse libstdc++ assertions - would also > > be of > > great help in extending the support of -Wanalyzer-out-of-bounds, > > as we could detect out-of-bounds on vectors through > > __glibcxx_requires_subscript used in the definition of operator[]. > > There's a bunch of other C++-enablement work (as per the tracker bug > above) that I think would need fixing before PR106388 is reasonable to > tackle. > Indeed a bunch of them, the ramification of solving that PR got me too excited. > > > > I already thought about a few ideas to implement that, but I'll > > develop > > them more and try to come up with some proof of concept before > > sending them > > to you. > > Hopefully by tomorrow I'll update on this, I'll preferably hop to bed > > now > > haha. > > Do you think this could make a suitable GSoC subject ? > > 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. > 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. 1. First thing first, extending the current C tests to cover C++ PR96395 <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96395> (1.bis ) 2. I would then go with supporting the options relative to sm-malloc: - -Wanalyser-double-free should behave properly (cf the fresh PR109365 <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109365> ) - Add proper support of the non-throwing new operators. At the moment, any new operators are supposed non-throwing (on_allocator_call, param returns_nonnull is implicitly set to false). Actually handling this would result in less false positive of -Wanalyzer-possible-null-dereference I observed by tweaking it to true. Indeed currently every throwing new operators get this warning. This would fit the bill of PR94355 <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355> and maybe the new placement sizes could be handled along the way. - -Wanalyzer-malloc-leak doesn't seem to go through the constructor chain. The reproducer struct D { int x; int y;}; class A { public: D* d = nullptr; A() : d{new D()} {} }; class B : public A { public: int b; B(int x) : b{x} {} }; B foo() {B b(4); return b;} int main() { B r = foo(); return 0; } 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. 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. - For smart pointers, it might be necessary to review the diagnostic path, as for shared_ptr they are quite long already. 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. 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. Thanks again for your review. Best, Benjamin
