Re: Static analysis updates in GCC 11

[Eric Gallager via Gcc]

On Sat, Jan 30, 2021 at 2:29 AM Eric Gallager  wrote:
>
> On Thu, Jan 28, 2021 at 3:24 PM 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/
> >
> > Hope this is of interest
> > Dave
> >
> >
>
> Thanks for the post! One nit: the post says: "Each of these
> corresponds to a pre-existing warning implemented in the C and C++
> front ends, but with a “-Wanalyzer” prefix rather than “-W.” As an
> example, -Wanalyzer-write-to-const corresponds to -Wwrite-to-const."
> There isn't actually a warning called "-Wwrite-to-const" though. There
> is "-Wwrite-strings" which is similar, but since it isn't actually a
> warning option itself (as per bug 61579), the warning flag that the
> warnings it provokes are actually issued by is -Wdiscarded-qualifiers.
> So, while I got what you meant, it still might confuse new programmers
> who might try to go using a flag called "-Wwrite-to-const" and then
> wonder why it doesn't exist.
>
> Thanks again!
> Eric

Oops I just realized I accidentally removed the mailing list from the
recipients; I'm adding that back now

gcc-9-20210129 is now available

[GCC Administrator via Gcc]

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

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

You'll find:

 gcc-9-20210129.tar.xzComplete GCC

  SHA256=1fb4ef46b1ebdd344b49cb20ccb4e54e1cf67b8741c5a53ebbc5f958179d830d
  SHA1=076e36aaad37b255a9cb4da26edf6e13f993fd3c

Diffs from 9-20210122 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-9
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.

-fstack-usage and -flto the stack usage report is generated

[Visda.Vokhshoori--- via Gcc]

Hello,

With link time optimization the stack usage information is determined during 
local transformation and written to program.ltrans0.ltrans.su.  There will be 
one .su file for each partition.

All ltrans files, including the .su, are removed unless –save-temps is 
indicated.

Although not obvious/not documented, but I am assuming this is working as 
designed.  Developers should include –save-temps along with -fstack-suage and 
-flto.

Or is this a bug?  That is exception should be made for the ltrans.su files and 
they should be kept around regardless.

Thanks,
Visda

Subreg spilled wrong mode in LRA

[Cooper Qu via Gcc]

Hi,


I ran into a troublesome problelm about LRA. The case is hard to 
construct, so I paste the RTL sequence first to ask for help.


---

The RTL sequence after IRA:

(insn 11 198 1633 20 (set (reg:DI 170 [ iftmp.176_92 ])
    (const_int 0 [0])) "":2099 182 {*movdi_64bit}
 (expr_list:REG_EQUAL (const_int 0 [0])
    (nil)))

(insn 1632 1633 1634 20 (set (reg:SI 973)
    (subreg:SI (reg:DI 170 [ iftmp.176_92 ]) 0)) "":2099 183 
{*movsi_internal}

 (expr_list:REG_DEAD (reg:DI 170 [ iftmp.176_92 ])
    (nil)))
(insn 1634 1632 1635 20 (set (reg:SI 974)
    (eq:SI (reg:DI 421)
    (const_int 0 [0]))) "":2099 271 {*seq_zero_disi}
 (expr_list:REG_DEAD (reg:DI 421)
    (nil)))
(insn 1635 1634 1636 20 (set (reg:SI 972)
    (if_then_else:SI (eq (reg/v:DI 173 [ i ])
    (const_int 0 [0]))
    (reg:SI 974)
    (reg:SI 973))) "":2099 238 {*cmovzsi}
 (expr_list:REG_DEAD (reg:SI 974)
    (expr_list:REG_DEAD (reg:SI 973)
    (nil
(insn 1636 1635 212 20 (set (subreg:SI (reg:DI 170 [ iftmp.176_92 ]) 0)
    (reg:SI 972)) "":2099 183 {*movsi_internal}
 (expr_list:REG_DEAD (reg:SI 972)
    (nil)))

...

(jump_insn 1022 1021 1023 104 (set (pc)
    (if_then_else (eq (reg:DI 170 [ iftmp.176_92 ])
    (const_int 0 [0]))
    (label_ref 1051)
    (pc))) "":1467 252 {*branch_zerodi}
 (expr_list:REG_DEAD (reg:DI 170 [ iftmp.176_92 ])
    (int_list:REG_BR_PROB 354334804 (nil)))

---

The RTL sequence after LRA RELOAD:

(insn 11 198 2025 20 (set (reg:DI 13 a3 [orig:170 iftmp.176_92 ] [170])
    (const_int 0 [0])) "":2099 182 {*movdi_64bit}
 (expr_list:REG_EQUAL (const_int 0 [0])
    (nil)))
(insn 1633 2025 1632 20 (set (reg:DI 15 a5 [421])
    (minus:DI (reg:DI 15 a5 [orig:125 _13 ] [125])
    (reg:DI 14 a4 [orig:254 pretmp_372 ] [254]))) "":2099 11 
{*subdi3}

 (nil))
(insn 1632 1633 1634 20 (set (reg:SI 13 a3 [973])
    (reg:SI 13 a3 [orig:170 iftmp.176_92 ] [170])) "":2099 183 
{*movsi_internal}

 (nil))
(insn 1634 1632 1635 20 (set (reg:SI 15 a5 [974])
    (eq:SI (reg:DI 15 a5 [421])
    (const_int 0 [0]))) "":2099 271 {*seq_zero_disi}
 (nil))
(insn 1635 1634 1636 20 (set (reg:SI 15 a5 [972])
    (if_then_else:SI (eq (reg/v:DI 19 s3 [orig:173 i ] [173])
    (const_int 0 [0]))
    (reg:SI 15 a5 [974])
    (reg:SI 13 a3 [973]))) "":2099 238 {*cmovzsi}
 (nil))
(insn 1636 1635 212 20 (set (mem/c:SI (plus:DI (reg/f:DI 2 sp)
    (const_int 24 [0x18])) [349 %sfp+-3496 S4 A64])
    (reg:SI 15 a5 [972])) "":2099 183 {*movsi_internal}
 (nil))

...

(insn 1926 1021 1022 104 (set (reg:DI 15 a5 [orig:170 iftmp.176_92 ] [170])
    (mem/c:DI (plus:DI (reg/f:DI 2 sp)
    (const_int 24 [0x18])) [349 %sfp+-3496 S8 A64])) 
"":1467 182 {*movdi_64bit}

 (nil))
(jump_insn 1022 1926 1023 104 (set (pc)
    (if_then_else (eq (reg:DI 15 a5 [orig:170 iftmp.176_92 ] [170])
    (const_int 0 [0]))
    (label_ref 1051)
    (pc))) "":1467 252 {*branch_zerodi}
 (int_list:REG_BR_PROB 354334804 (nil))

---

The REG 170 spilled to memory, but it emits a SImode store and a DImode 
load. I tried to debug and find some related code in lra.c, in 
add_regs_to_insn_regno_info function,   the following code is about to 
check SUBREG


        if (GET_CODE (x) == SUBREG)
        {
      mode = wider_subreg_mode (x);
      if (read_modify_subreg_p (x))
            subreg_p = true;
      x = SUBREG_REG (x);
      code = GET_CODE (x);
        }

If read_modify_subreg_p (x) is true, the subreg_p flag will be set. But 
if SUBREG's mode is narrower than register mode, the subreg_p flag will 
not be set just like the case I wrote.


If I let read_modify_subreg_p (x) return true, my case will turn right. 
But I'm not sure if it's appropriate, because it may decrease target 
performance.



Hope someone can help me.


Best Regards,

Cooper

Re: Static analysis updates in GCC 11

[David Brown]

On 29/01/2021 01:03, Martin Sebor wrote:

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

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




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.



That could be nice - and it could be useful for all sorts of other 
resource management, not just memory pools and allocators.


One thing that always concerns me about the "malloc" attribute and 
memory pools is that the source of the pool has to come from somewhere 
(such as an OS memory allocation, or perhaps statically memory blocks) 
and your allocator will generally have pointers to keep track of it. 
That means the pointer given out by the malloc-type function /is/ 
aliased to existing memory theoretically accessible via other methods. 
I've never felt entirely comfortable that home-made allocators are 
actually completely safe and correct for all possible alias analysis. 
(And I suspect the move towards provenance based alias tracking will not 
make this easier.)


Perhaps if there are tags for malloc-like function attributes, there 
could be attributes that use the same tags to mark data blocks or 
pointers as being the source for the allocator pools.

Re: Static analysis updates in GCC 11

[David Brown]

On 28/01/2021 22:27, David Malcolm 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).

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



Thanks for the feedback.

Just to be clear, I am not particularly tied to the syntax I suggested 
in the bugzilla suggestion - it is merely a starting point for ideas. 
"caller_tag" and "callee_tag", for example, are probably too similar and 
easily mixed up by people using the attributes.  "needs_tag" and 
"limit_to_tag" might be a better second suggestion.  Or perhaps someone 
else will think of a completely different arrangement to get a similar 
end result.


Yes, I believe tying an attribute to a compound statement might be a new 
idea, but that could just be because the only "statement attribute" 
currently in gcc (AFAIK, from reading the manual) is "fallthrough" - and 
it is generally applied to a null statement.


I suggested the possibility of attaching attributes to statements within 
a function, so that the developer can make it clear when the tag is 
acquired and released.  But it is not essential - it would be fine to 
simply say that the whole function is tagged, if that makes an 
implementation simpler.


At least some of the potential uses here could be handled by C++ strong 
typing and tag structs (carrying no data, but with restrictions on how 
they can be created and copied around).  But tag attributes, or an 
equivalent mechanism, would let you do this in C as well, and it would 
be less strict and structured - and thus easier to add to existing code.

Re: PR numbers from Changelogs do not arrive in bugzilla

[Martin Liška]

On 1/28/21 9:55 PM, Thomas Koenig via Gcc wrote:

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.


Hello.

You are right, it was sent to gcc cvs mailing list:
https://gcc.gnu.org/pipermail/gcc-cvs/2021-January/341037.html

but not into the gcc-bugs mailing list.
We had some issue some time ago 
(https://github.com/AdaCore/git-hooks/issues/18),
but should be resolved.

I've tried to push your change to gcc-reposurgeon-8 and it worked:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98559#c5

So I'm sorry, right now I don't see how to reproduce it :/
Martin



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