[GSoC][analyzer-c++] Enable enough C++ support for self-analysis

[GSoC][analyzer-c++] Enable enough C++ support for self-analysis

[Benjamin Priour]

[-- Attachment #1: Type: text/plain, Size: 6770 bytes --]

Hi David,


On Thu, Mar 30, 2023 at 2:04 AM David Malcolm <dmalcolm@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

Re: [GSoC][analyzer-c++] Enable enough C++ support for self-analysis

[David Malcolm]

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 <dmalcolm@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

Re: [GSoC][analyzer-c++] Submission of a draft proposal

[Benjamin Priour]

[-- Attachment #1: Type: text/plain, Size: 5381 bytes --]

Hi David,

On Mon, Apr 3, 2023 at 12:38 AM David Malcolm <dmalcolm@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}.

Re: [GSoC][analyzer-c++] Submission of a draft proposal

[Benjamin Priour]

[-- Attachment #1: Type: text/plain, Size: 5856 bytes --]

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.be@gmail.com> wrote:

> Hi David,
>
> On Mon, Apr 3, 2023 at 12:38 AM David Malcolm <dmalcolm@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}.
>

Re: [GSoC][analyzer-c++] Submission of a draft proposal

[David Malcolm]

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.be@gmail.com>
> wrote:
> 
> > Hi David,
> > 
> > On Mon, Apr 3, 2023 at 12:38 AM David Malcolm <dmalcolm@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}.
> >