Fwd: Legal Prerequisites contributions

[Michael de Lang]

Dear Sir/Madam,

I'm working on implementing pr0980r1 and people in the #gcc channel
told me to get the legal process started asap. I am willing to sign
copyright assignments as outlayed on
https://gcc.gnu.org/contribute.html

Met vriendelijke groet,
Michael de Lang

Re: Re: GSoC: some questions about the static analyzer pass

[y...@bupt.edu.cn]

Hello, David! 
 
It's so excited to receive a reply from you directedly. My name is Beenle, an 
undergraduate student in Beijing, China. 
 
I've read the analyzer internal documentation, but I'm not sure I understood 
well. The following are my thoughts about the analyzer and I’m not sure they 
are right or feasible. Would it be possible for you to give me some advice? 
 
For the detecting part, the core is the state machine. But it's working on the 
gimple-SSA representation, it’s more complex. According to the graphs and the 
state machine, we detect the problem. I wonder that since I know little about 
gimple and ssa, should I read the 12 gimple internal and 13 analysis and 
optimization of gimple tuples internal firstly so that I can understand the 
approach of the analyzer well and maybe produce some new ideas?  And the reason 
why we build the supergraph is that the gimple-SSA representation gives us the 
callgraph and CFGs of the program.
And there is a problem derived from the graph--since we have to represent the 
graph to the user (is there any other reason?), we have to simplify the graph. 
So how to prune and merge is an important part.
The last is how to represent the problem to the users. How to find a simplest 
and feasible way is important too.
For the GSoC, I would like to extend the analyzer for C++ and optimize the 
pruning and merging algorithm. I’m also interested in optimizing the region 
model, but not sure if time permitted. This is just my first thought, and I’m 
eager for your suggestion, such as on the time limitation and the urgent need 
for the project.
 
It's still a bit difficult for me to read the codes after reading the internal 
documentation. Is there any way that I can understand easier? 
 
And when I try to test the analyzer, I got a 404 when I try to open  
https://gcc.gnu.org/git/gcc even without the firewall. How can I solve this 
problem?

Thank you very much for your patience! I’m looking forward to your reply.

Best wishes!



Beenle Yi
 
From: David Malcolm
Date: 2020-02-28 10:01
To: y...@bupt.edu.cn; gcc
Subject: Re: GSoC: some questions about the static analyzer pass
On Fri, 2020-02-28 at 09:31 +0800, y...@bupt.edu.cn wrote:
> Hello everybody! I've learned about the projects in Google summer of
> code, and I'm so interested in the static analyzer pass. I wonder
> that where I can read the code of the static analyzer pass and how to
> contact with the mental David Malcolm. Can anyone help me please?
> Thank you so much.
 
Hi!
 
The code is in the gcc/analyzer subdirectory of the GCC source tree:
  https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=gcc/analyzer
 
Internal documentation is here:
  https://gcc.gnu.org/onlinedocs/gccint/Static-Analyzer.html
 
Some other notes can be seen at:
  https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer
 
 
Hope this is helpful
David
 
 
 

Re: Fwd: Legal Prerequisites contributions

[Jeff Law]

On Sun, 2020-03-01 at 14:37 +0100, Michael de Lang wrote:
> Dear Sir/Madam,
> 
> I'm working on implementing pr0980r1 and people in the #gcc channel
> told me to get the legal process started asap. I am willing to sign
> copyright assignments as outlayed on
> https://gcc.gnu.org/contribute.html
Contact ass...@gnu.org to get your paperwork started.

Thanks,
Jeff
> 

Status of C++11 Move and Using Unique_Ptr

[Nicholas Krause]

Greetings Jeff,

Sorry if I'm bugging you. I've already sent off some work on IPA passes 
with a few questions here:

https://gcc.gnu.org/ml/gcc/2020-02/msg00247.html

And locking SSA iterators:

From: Nicholas Krause

In order to start making SSA be muti-threaded safe I'm proposing
adding locks as implemented in this patch. There are two ways
of doing the locking and both have there advantage/disadvantage:
1.Rewrite the marcos to be functions and make the locking internal
to SSA iterators themselves. This removes possible inlining of the
marcos as currently implemented.
2. Don't change the marcos but add the proposed locks and update
the manual to warn about locking/unlocking the correct lock or
series of locks when iterating over SSA or other similar nodes.

Not sure which is better. Comments are also welcome.
Signed-off-by: Nicholas Krause
---
 gcc/ssa-iterators.h | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/gcc/ssa-iterators.h b/gcc/ssa-iterators.h
index 65d8e3b..1c8c2ad 100644
--- a/gcc/ssa-iterators.h
+++ b/gcc/ssa-iterators.h
@@ -16,11 +16,11 @@ FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General 
Public License
 You should have received a copy of the GNU General Public License
 along with GCC; see the file COPYING3.  If not see
 .  */
-#include 
 
 #ifndef GCC_SSA_ITERATORS_H

 #define GCC_SSA_ITERATORS_H
 
+#include 

 /* Immediate use lists are used to directly access all uses for an SSA
name and get pointers to the statement for each use.
 
@@ -70,9 +70,9 @@ struct imm_use_iterator

 };
 
 /*IMM Iterator Mutex*/

-pthread_mutex_t imm_iteration_mutex;
+extern pthread_mutex_t imm_iteration_mutex;
 /*IMM_STMT Iterator Mutex*/
-pthread_mutex_t imm_stmt_iterator_mutex;
+extern pthread_mutex_t imm_stmt_iterator_mutex;
 
 /* Use this iterator when simply looking at stmts.  Adding, deleting or

modifying stmts will cause this iterator to malfunction.  */
@@ -153,11 +153,11 @@ struct ssa_op_iter
 };
 
 /*SSA Iterator Mutex*/

-pthread_mutex_t ssa_iteration_mutex;
+extern pthread_mutex_t ssa_iteration_mutex;
 /*PHI Iterator Mutex*/
-pthread_mutex_t phi_iteration_mutex;
+extern pthread_mutex_t phi_iteration_mutex;
 /*PHI_STMT Iterator Mutex*/
-pthread_mutex_t phi_stmt_iterator_mutex;
+extern pthread_mutex_t phi_stmt_iterator_mutex;
 
 /* NOTE: Keep these in sync with doc/tree-ssa.texi.  */

 /* These flags are used to determine which operands are returned during
-- 1.8.3.1



I was wondering and maybe its a dumb idea but seems removing the garbage 
collector for the most
part is going to be possible and I'm going to investigate into it 
further this week.


Seems that GTY() wrappers are really just one of two use cases after 
looking through a few

files:
Empty Wrappers that don't have a pointer can just be removed due to them 
now allocating
memory themselves  but callers doing so. Or the second case of having a 
pointer(s) which

need a destructor for them.

However for the other wrappers which take arguments I was wondering if 
its possible to
just use unique_ptr with a custom allocater. Seems that's basically what 
the internal
garbage collector is. I'm not sure of the current status of the C++11 
move and sorry

if I did not help out as much with that under than the early discussion.


Take care,
Nick

Re: Status of C++11 Move and Using Unique_Ptr

[Jonathan Wakely]

On Sun, 1 Mar 2020 at 20:24, Nicholas Krause wrote:
> I'm not sure of the current status of the C++11
> move

We're in the middle of GCC 10's stage 4 and not doing anything like that now.

As has been said several times, it's in scope for GCC 11, but not before.

Re: Fwd: Legal Prerequisites contributions

[Jonathan Wakely]

On 01/03/20 14:37 +0100, Michael de Lang wrote:

Dear Sir/Madam,

I'm working on implementing pr0980r1 and people in the #gcc channel
told me to get the legal process started asap. I am willing to sign
copyright assignments as outlayed on
https://gcc.gnu.org/contribute.html

Met vriendelijke groet,
Michael de Lang


Form sent offlist.

Re: Status of C++11 Move and Using Unique_Ptr

[nick]

On 2020-03-01 4:28 p.m., Jonathan Wakely wrote:
> On Sun, 1 Mar 2020 at 20:24, Nicholas Krause wrote:
>> I'm not sure of the current status of the C++11
>> move
> 
> We're in the middle of GCC 10's stage 4 and not doing anything like that now.
> 
> As has been said several times, it's in scope for GCC 11, but not before.
> 
Jonathan,
Sorry my memory was a bit bad about that :(. I don't recall what C++ features
we decided on limiting to as that was still under discussion. I would really
like unique_ptr and stl library features like that. however I don't cecall if
there was a discussion on allowing C++ STL 11 library features in gcc.

At least it was not a definite yes on allowing STL libraries,
Nick

gcc-10-20200301 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch master 
revision 151bf47e78f5d919f6cc591d11cc1f6aff61078f

You'll find:

 gcc-10-20200301.tar.xz   Complete GCC

  SHA256=c32fa4848976306358110bd0e1bda582280601a7564b67400356ede89de285ca
  SHA1=aba18dc4d6fcb7437ed98b22d4299ad767898add

Diffs from 10-20200223 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-10
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: Status of C++11 Move and Using Unique_Ptr

[David Malcolm]

On Sun, 2020-03-01 at 15:24 -0500, Nicholas Krause wrote:
> Greetings Jeff,
> 
> Sorry if I'm bugging you.

[Dropping Jeff from CC since it appears the answer is "yes, you are"]

>  I've already sent off some work on IPA passes 
> with a few questions here:
> https://gcc.gnu.org/ml/gcc/2020-02/msg00247.html
> 
> And locking SSA iterators:
> 
> From: Nicholas Krause
> 
> In order to start making SSA be muti-threaded safe I'm proposing
> adding locks as implemented in this patch. There are two ways
> of doing the locking and both have there advantage/disadvantage:
> 1.Rewrite the marcos to be functions and make the locking internal
> to SSA iterators themselves. This removes possible inlining of the
> marcos as currently implemented.
> 2. Don't change the marcos but add the proposed locks and update
> the manual to warn about locking/unlocking the correct lock or
> series of locks when iterating over SSA or other similar nodes.
> 
> Not sure which is better. Comments are also welcome.
> Signed-off-by: Nicholas Krause
> ---
>   gcc/ssa-iterators.h | 12 ++--
>   1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/gcc/ssa-iterators.h b/gcc/ssa-iterators.h
> index 65d8e3b..1c8c2ad 100644
> --- a/gcc/ssa-iterators.h
> +++ b/gcc/ssa-iterators.h
> @@ -16,11 +16,11 @@ FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> General Public License
>   You should have received a copy of the GNU General Public License
>   along with GCC; see the file COPYING3.  If not see
>   ;.  */
> -#include 

ssa-iterators.h does not currently include , so this patch
appears to be against something other than master.  It looks like
you've posted a patch relative to a change you have locally.

This isn't helpful.

[...snip...]
  
>   /*SSA Iterator Mutex*/
> -pthread_mutex_t ssa_iteration_mutex;
> +extern pthread_mutex_t ssa_iteration_mutex;
>   /*PHI Iterator Mutex*/
> -pthread_mutex_t phi_iteration_mutex;
> +extern pthread_mutex_t phi_iteration_mutex;
>   /*PHI_STMT Iterator Mutex*/
> -pthread_mutex_t phi_stmt_iterator_mutex;
> +extern pthread_mutex_t phi_stmt_iterator_mutex;


Again, this patch is making "extern" various pthread_mutex_t vars that
aren't in GCC; it looks like you're generating a patch against a patch.
  
>   /* NOTE: Keep these in sync with doc/tree-ssa.texi.  */
>   /* These flags are used to determine which operands are returned
> during
> -- 1.8.3.1
> 
> 
> 
> I was wondering and maybe its a dumb idea but seems removing the
> garbage 
> collector for the most
> part is going to be possible and I'm going to investigate into it 
> further this week.

[...snip...]

This seems ludicrously overambitious for a first patch.  The text of
your email suggests that you don't a sense of how difficult what you're
suggesting actually is.

Even if somehow you managed to generate a working patch that eliminated
the garbage collector without regressing the performance of the
compiler, it's difficult for us to trust that your patch would work, as
you seem to demonstrate a lack of real understanding of the code.

I normally attempt to be welcoming to new contributors, but I see that
some years ago you submitted a series of apparently nonsensical patches
to the Linux kernel; see e.g.:
  https://lkml.org/lkml/2014/8/4/206
and there was speculation within that development community as to
whether you were deliberately trolling them.

If you want to be involved in GCC development, please select something
small and well-focused for an initial task - to gain experience, and to
build trust with the other developers.

Otherwise you're wasting your time and ours.

Sorry to be blunt.

I hope this is constructive, and I don't want to scare off other
potential contributors.

David

Re: Re: GSoC: some questions about the static analyzer pass

[David Malcolm]

On Sun, 2020-03-01 at 23:48 +0800, y...@bupt.edu.cn wrote:
> Hello, David! 
>  
> It's so excited to receive a reply from you directedly. My name is
> Beenle, an undergraduate student in Beijing, China. 

Hello Beenle.

> I've read the analyzer internal documentation, but I'm not sure I
> understood well. The following are my thoughts about the analyzer and
> I’m not sure they are right or feasible. Would it be possible for you
> to give me some advice? 

I'll try.

> For the detecting part, the core is the state machine. But it's
> working on the gimple-SSA representation, it’s more complex.
> According to the graphs and the state machine, we detect the problem.
> I wonder that since I know little about gimple and ssa, should I read
> the 12 gimple internal and 13 analysis and optimization of gimple
> tuples internal firstly so that I can understand the approach of the
> analyzer well and maybe produce some new ideas?

Yes: it's worth reading through the GCC internals manual - in
particular the sections about gimple-SSA.

You should definitely also read "7 Testsuites": I tend to follow Test-
Driven Development with the analyzer: I create some simple test files
that demonstrate bugs that the analyzer ought to detect, and turn them
into DejaGnu tests.

>   And the reason why we build the supergraph is that the gimple-SSA
> representation gives us the callgraph and CFGs of the program.
> And there is a problem derived from the graph--since we have to
> represent the graph to the user (is there any other reason?), we have
> to simplify the graph. So how to prune and merge is an important
> part.

There are several "graphs":

- the supergraph combines the CFGs and the callgraph
- the exploded_graph combines the supergraph with state (and call
strings)
- the graph within a region_model at a node within the exploded_graph,
expressing pointers to regions.

Pruning within region_model instances, and merging them is indeed very
important, to avoid the analysis "exploding".

I've been working on a rewrite of how region_models are pruned, which I
hope to land in "master" in the next week.

> The last is how to represent the problem to the users. How to find a
> simplest and feasible way is important too.

Yes.  diagnostic-manager.cc generates events, and then tries to purge
them (a kind of peephole optimization, but optimizing for readability
to the end-user, rather than optimizing code).

> For the GSoC, I would like to extend the analyzer for C++ and
> optimize the pruning and merging algorithm. I’m also interested in
> optimizing the region model, but not sure if time permitted. This is
> just my first thought, and I’m eager for your suggestion, such as on
> the time limitation and the urgent need for the project.

All of these ideas sound very worthwhile.

Perhaps it's worth focusing on C++ support.  For example:
- extending the malloc/free checking to cover new/delete and 
new[]/delete[] (and mismatches between them)
- exception-handling
- properly handling constructors and destructors
- virtual functions
- ...etc

The above could easily take the whole summer, and would be self-
contained.

> It's still a bit difficult for me to read the codes after reading the
> internal documentation. Is there any way that I can understand
> easier? 

FWIW I wrote some notes on GCC for newcomers here:
  https://dmalcolm.fedorapeople.org/gcc/newbies-guide/index.html

I would recommend building the code from source, and trying to step
through the analyzer.

Use "--disable-bootstrap" when building from source: it's much quicker.
Build it, and change to the "gcc" subdirectory (containing the built
"cc1" and "xgcc" binaries).
I wrote some instructions on debugging here:
  https://dmalcolm.fedorapeople.org/gcc/newbies-guide/debugging.html

The entrypoint to the analyzer is ana::run_checkers, so try putting a
breakpoint there and stepping through it.

Also, -fdump-analyzer and -fdump-analyzer-stderr may prove useful for
seeing what's going on.


> And when I try to test the analyzer, I got a 404 when I try to open  
> https://gcc.gnu.org/git/gcc even without the firewall. How can I
> solve this problem?

I don't know where you got that URL; I get a 404 for it as well.

I hope you're able to access the links I gave above.  Some of it is on
github, if that's accessible from China.


Try the instructions here for obtaining a git clone of the latest
sources:
  https://gcc.gnu.org/git.html


> Thank you very much for your patience! I’m looking forward to your
> reply.
> 
> Best wishes!
> 
> Beenle Yi

I hope the above was helpful
David


> >  
> > From: David Malcolm
> > Date: 2020-02-28 10:01
> > To: y...@bupt.edu.cn; gcc
> > Subject: Re: GSoC: some questions about the static analyzer pass
> > On Fri, 2020-02-28 at 09:31 +0800, y...@bupt.edu.cn wrote:
> > > Hello everybody! I've learned about the projects in Google summer
> > of
> > > code, and I'm so interested in the static analyzer pass. I wonder
> > > that where I can read the code o

GSoC 2020

[Yusuke Izawa]

Hi,

I'd like to participate in Google Summer of Code 2020 at GCC.
In particular, I'm interested in the idea: "Fortran – run-time argument 
checking.".
It seems that there are still many projects written in Fortran, thus improving 
Fortran itself
is worthwhile for those who do high performance computing using Fortran.
Would you tell me more information about the project?

Best Regargs,
Yusuke Izawa