Hi David,

(subject's line totally stolen inspired from Eric's)
Last week as you know had some special circumstances therefore not much has
been done.

I've changed my in-progress patch about trimming the system headers event
to fit your suggestions from
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625245.html.
I had suggested that we keep events (1) (2) (11) and (12) in the reproducer
https://godbolt.org/z/sb9dM9Gqa
but after comparing it to your first suggestion of only keeping (11), I
don't know which one to keep.
Just (11) has the benefit of being really concise and verbose enough in
this case, mimicking the behavior of a raw pointer.
However having the call site and return site might be helpful for the user,
e.g. to understand what template arguments were deduced.

I think we could still have events (11) and (12): what if for call and
> return events we consider the location of both the call site and the
> called function: we suppress if both are in a system header, but don't
> suppress if only one is a system header.  That way by default we'd show
> the call into a system header and show the return from the system
> header, but we'd suppress all the implementation details within the
> system header.
>
> Does that seem like it could work?


It works and is one the two implementations I have.
Now we just have to decide which is better, and I'll submit the patch to
the mail list.

Some updates too on the added support of placement new

What do you think of "null-dereference" superceding
"use-of-unitialized-value" ?
Both can occur at the same statement (see
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625844.html)
If you think adding this supercedes_p to null-deref is acceptable, then
I'll fix PR 110830 <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110830>
before submitting the placement new patch.


Otherwise, I've been working on what we talked about last time, i.e. moving
the tests under gcc.dg/analyzer
to c-c++-common/analyzer. It is still in progress (about 100 tests done out
of 700+).

A question on that front:
What is the purpose of test gcc.dg/analyzer/data-model-11.c ?

int test (void)
{
  unsigned char *s = (unsigned char *) "abc";
  char *t = "xyz";
  return s[1] + t[1];
}

Are the non-constness of the strings being tested or only their sign ?

Thanks
Benjamin.