Re: Static analysis updates in GCC 11

[Martin Sebor via Gcc]

On 1/28/21 2:27 PM, David Malcolm via Gcc wrote:

On Thu, 2021-01-28 at 22:06 +0100, David Brown wrote:

On 28/01/2021 21:23, David Malcolm via Gcc wrote:

I wrote a blog post covering what I've been working on in the
analyzer
in this release:
  
https://developers.redhat.com/blog/2021/01/28/static-analysis-updates-in-gcc-11/



As a gcc user, I am always glad to hear of more static analysis and
static warning work.  My own work is mostly on small embedded
systems,
where "malloc" and friends are severely frowned upon in any case and
there is no file system, so most of the gcc 10 -fanalyzer warnings
are
of no direct use to me.  (I still think they are great ideas - even
if
/I/ don't write much PC code, everyone benefits if there are fewer
bugs
in programs.)  I will get more use for the new warnings you've added
for
gcc 11.


I wrote a feature request for gcc a while back, involving adding tag
attributes to functions in order to ensure that certain classes of
functions are only used from specific allowed functions.  The feature
request attracted only a little interest at the time.  But I suspect
it
could work far better along with the kind of analysis you are doing
with
-fanalyzer than with the normal syntactical analyser in gcc.




Interesting.  The attribute ideas seem designed to work with the
callgraph: partitioning the callgraph into families of functions for
which certain kinds of inter-partition edges are disallowed.  Can a
function change its tag internally, or is it assumed that a function
has a single tag throughout its whole body?  I see that you have a case
in example 3 where a compound statement is marked with an attribute
(which may be an extension of our syntax).


Florian suggested a similar approach (tags) as an enhancement to
the malloc attribute extension we've just added, to avoid having
to exhaustively associate every allocator with every deallocator.

Martin



One thing I forgot to mention in the blog post is that the analyzer now
supports plugins; there's an example of a mutex-checking plugin here:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=66dde7bc64b75d4a338266333c9c490b12d49825
which is similar to your examples 1 and 3.  Your example 2 is also
reminiscent of the async-signal-unsafe checking that the analyzer has
(where it detects code paths that are called within a signal handler
and complains about bad calls within them).  Many of the existing
checks in the analyzer are modelled as state machines (either global
state for things like "are we in a signal handler", or per-value state
for things like "has this pointer been freed"), and your examples could
be modelled that way too (e.g. "what sections are in RAM" could be a
global state) - so maybe it could all be done as analyzer plugins, in
lieu of implementing the RFE you posted.

Hope this is constructive
Dave

gcc-8-20210128 is now available

[GCC Administrator via Gcc]

Snapshot gcc-8-20210128 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/8-20210128/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 8 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-8 
revision dd1537924e18e87a44abbd4063de89f7b48c60d5

You'll find:

 gcc-8-20210128.tar.xzComplete GCC

  SHA256=22fae260f512b51b8745c30a5b15d913cf102153d52cb4a694d36d287874006d
  SHA1=70bd7edbb46443972cc5878307c1dd144909187d

Diffs from 8-20210121 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-8
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Static analysis updates in GCC 11

[David Malcolm via Gcc]

On Thu, 2021-01-28 at 22:06 +0100, David Brown wrote:
> On 28/01/2021 21:23, David Malcolm via Gcc wrote:
> > I wrote a blog post covering what I've been working on in the
> > analyzer
> > in this release:
> >  
> > https://developers.redhat.com/blog/2021/01/28/static-analysis-updates-in-gcc-11/
> > 
> 
> As a gcc user, I am always glad to hear of more static analysis and
> static warning work.  My own work is mostly on small embedded
> systems,
> where "malloc" and friends are severely frowned upon in any case and
> there is no file system, so most of the gcc 10 -fanalyzer warnings
> are
> of no direct use to me.  (I still think they are great ideas - even
> if
> /I/ don't write much PC code, everyone benefits if there are fewer
> bugs
> in programs.)  I will get more use for the new warnings you've added
> for
> gcc 11.
> 
> 
> I wrote a feature request for gcc a while back, involving adding tag
> attributes to functions in order to ensure that certain classes of
> functions are only used from specific allowed functions.  The feature
> request attracted only a little interest at the time.  But I suspect
> it
> could work far better along with the kind of analysis you are doing
> with
> -fanalyzer than with the normal syntactical analyser in gcc.
> 
> 

Interesting.  The attribute ideas seem designed to work with the
callgraph: partitioning the callgraph into families of functions for
which certain kinds of inter-partition edges are disallowed.  Can a
function change its tag internally, or is it assumed that a function
has a single tag throughout its whole body?  I see that you have a case
in example 3 where a compound statement is marked with an attribute
(which may be an extension of our syntax).

One thing I forgot to mention in the blog post is that the analyzer now
supports plugins; there's an example of a mutex-checking plugin here:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=66dde7bc64b75d4a338266333c9c490b12d49825
which is similar to your examples 1 and 3.  Your example 2 is also
reminiscent of the async-signal-unsafe checking that the analyzer has
(where it detects code paths that are called within a signal handler
and complains about bad calls within them).  Many of the existing
checks in the analyzer are modelled as state machines (either global
state for things like "are we in a signal handler", or per-value state
for things like "has this pointer been freed"), and your examples could
be modelled that way too (e.g. "what sections are in RAM" could be a
global state) - so maybe it could all be done as analyzer plugins, in
lieu of implementing the RFE you posted.

Hope this is constructive
Dave

Re: Static analysis updates in GCC 11

[David Brown]

On 28/01/2021 21:23, David Malcolm via Gcc wrote:
> I wrote a blog post covering what I've been working on in the analyzer
> in this release:
>  
> https://developers.redhat.com/blog/2021/01/28/static-analysis-updates-in-gcc-11/
> 

As a gcc user, I am always glad to hear of more static analysis and
static warning work.  My own work is mostly on small embedded systems,
where "malloc" and friends are severely frowned upon in any case and
there is no file system, so most of the gcc 10 -fanalyzer warnings are
of no direct use to me.  (I still think they are great ideas - even if
/I/ don't write much PC code, everyone benefits if there are fewer bugs
in programs.)  I will get more use for the new warnings you've added for
gcc 11.


I wrote a feature request for gcc a while back, involving adding tag
attributes to functions in order to ensure that certain classes of
functions are only used from specific allowed functions.  The feature
request attracted only a little interest at the time.  But I suspect it
could work far better along with the kind of analysis you are doing with
-fanalyzer than with the normal syntactical analyser in gcc.



David

PR numbers from Changelogs do not arrive in bugzilla

[Thomas Koenig via Gcc]

Hi,

I committed a test case for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67539
with

https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=80198c701a7fc09e736ccffe470ee5033ca59a69

but that commit did not make it into the PR, I put it
in by hand.

I had this problem previously, then it was thought that the
messed-up spellling of my name caused this.  That has been
fixed by now.

Any ideas what could be going wrong?

Best regards

Thomas

Static analysis updates in GCC 11

[David Malcolm via Gcc]

I wrote a blog post covering what I've been working on in the analyzer
in this release:
 
https://developers.redhat.com/blog/2021/01/28/static-analysis-updates-in-gcc-11/

Hope this is of interest
Dave