analyzer: Weekly update and questions on extending c++ support.

analyzer: Weekly update and questions on extending c++ support.

[Benjamin Priour]

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

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.

Re: analyzer: Weekly update and questions on extending c++ support.

[David Malcolm]

On Mon, 2023-07-31 at 14:19 +0200, Benjamin Priour wrote:
> Hi David,

Hi Benjamin

> 
> (subject's line totally stolen inspired from Eric's)

:)

> Last week as you know had some special circumstances therefore not
> much has
> been done.

FWIW you still seem to have got a lot 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.

Great.  Are patches still taking a long time to test?  If so, feel free
to post the patches before the testing is done (but acknowledge that in
the blurb of the patch).  Do you need an account on the compiler farm?

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

I think I covered this in my reply to your other email.

> 
> 
> 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+).

Excellent; thanks.

> 
> 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
> ?

"git log" tells me that testcase goes all the way back to the initial
commit of the analyzer.  I think that my concern with that test was the
signedness of the strings, not the constness, so feel free to add a
"const" to the type of s (and now I look at it, maybe make "t" be
explicitly signed char, rather than just char?)


Thanks
Dave