Re: git conversion in progress

[Georg-Johann Lay]

Am 11.01.20 um 02:18 schrieb Joseph Myers:

I encourage people to continue to work on improving the documentation for
using git with GCC


Hi, the front page reads "Our sources are readily and freely available 
via SVN...", similar recommendation for SVN in


https://gcc.gnu.org/snapshots.html

Johann

Re: git conversion in progress

[Jonathan Wakely]

On Thu, 16 Jan 2020 at 09:55, Georg-Johann Lay  wrote:
>
> Am 11.01.20 um 02:18 schrieb Joseph Myers:
> > I encourage people to continue to work on improving the documentation for
> > using git with GCC
>
> Hi, the front page reads "Our sources are readily and freely available
> via SVN...", similar recommendation for SVN in
>
> https://gcc.gnu.org/snapshots.html

Yes, it's been said more than once that the web pages will be updated
once the docs for using git are ready.

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Joel Brobecker]

> Joel, this is definitely a question for you; it's beyond my expertise in 
> the working of the hooks.  The issue is that when a merge commit is 
> pushed, we only want mails for commits that are new *to the repository* - 
> not those that are already in the repository (accessible from some other 
> ref before the ref update being processed by the hook comes into effect), 
> but are new *to the branch*.

We used to have that kind of behavior, and found that this was causing
problems. The main problem is when you are merging a branch for which
for which a no-email policy applies to a branch for which the normal
emails are to be sent. This happens for instance when people used
development branches that they had silenced so as to avoid spamming
people. And because they have been rebasing their branch regularly,
the "merge" ended up being a fast-forward. And because it was a fast
forward, the hooks saw that the commits were already known to the
repository, and no email was sent at all for those new commits.

Beyond this specific issue of users being surprised about the missing
emails, we thought about it more, and it seemed logical that we would
want a trace for each branch a commit makes it to. It's an essential
element of being able to track where a given commit was applied.

> I think there's a similar issue not just for merges but for 
> non-fast-forward pushes as well.  As a glibc example, consider 
>  and the long 
> series of subsequent mails in the glibc-cvs archives.  It's correct that 
> the five or so rebased patches on the branch got mailed out again.  It's 
> *not* desirable that the 50 or so patches that were already on master, 
> that the branch got rebased on top of, got mailed out again.

At heart, it is really the same issue. New commits were brought into
this branch, and thus if email notification is enabled for that branch,
then those commits should trigger emails for their own as well.

Typically, branches were non-fast-forward changes are allowed are
branches that are personal and not shared. In those instances,
the typical setup is to disable emails on those development branches.
It sounds to me like turning emails off for branches that can
do non-fast-forward is the better solution here.

-- 
Joel

Re: GCC GSoC 2020: Call for mentors and project ideas

[Nathan Sidwell]

On 1/15/20 5:45 PM, Martin Jambor wrote:


Therefore, first and foremost, I would like to ask all (moderately)
seasoned GCC contributors to consider mentoring a student this year and
ideally also come up with a project that they would like to lead.  I'm
collecting proposal on our wiki page
https://gcc.gnu.org/wiki/SummerOfCode - feel free to add yours to the
top list there.  Or, if you are unsure, post your offer and project idea
as a reply here to the mailing list.


I have an idea for a GNU-Make project.

* Separate Make's job-control from the dependency walking.  Right now, 
theses are somewhat tangled up, due to history.  It would be nice to 
separate these into distinct components.  One wrinkle may be that 
single-threaded invocation might need to preserve the 
(implementation-defined) order of dependent rule execution, as makefiles 
that do not completely specify dependencies might be relying on that.


I ran into this problem with my hack to add a module-server into make, 
and hacked around it in an ugly fashion.


(I've not run this by the GNU-Make maintainers)

nathan

--
Nathan Sidwell

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Jakub Jelinek]

On Thu, Jan 16, 2020 at 12:40:02PM +0100, Joel Brobecker wrote:
> > I think there's a similar issue not just for merges but for 
> > non-fast-forward pushes as well.  As a glibc example, consider 
> >  and the long 
> > series of subsequent mails in the glibc-cvs archives.  It's correct that 
> > the five or so rebased patches on the branch got mailed out again.  It's 
> > *not* desirable that the 50 or so patches that were already on master, 
> > that the branch got rebased on top of, got mailed out again.
> 
> At heart, it is really the same issue. New commits were brought into
> this branch, and thus if email notification is enabled for that branch,
> then those commits should trigger emails for their own as well.
> 
> Typically, branches were non-fast-forward changes are allowed are
> branches that are personal and not shared. In those instances,
> the typical setup is to disable emails on those development branches.
> It sounds to me like turning emails off for branches that can
> do non-fast-forward is the better solution here.

Couldn't it be then per-branch setting, whether to mail even commits
that aren't new to the repository or not (like I understood it is already
possible to decide per-branch whether to send mails at all)?
E.g. for GCC, I'd certainly like to see mails for all commits on the
trunk and release branches (but we don't allow merge commits on them
anyway), and for other branches (personal, vendor, devel) I think mailing
only about new commits not already in the repository would be better over
not mailing at all.

Jakub

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Richard Earnshaw (lists)]

On 16/01/2020 14:11, Jakub Jelinek wrote:

On Thu, Jan 16, 2020 at 12:40:02PM +0100, Joel Brobecker wrote:

I think there's a similar issue not just for merges but for
non-fast-forward pushes as well.  As a glibc example, consider
 and the long
series of subsequent mails in the glibc-cvs archives.  It's correct that
the five or so rebased patches on the branch got mailed out again.  It's
*not* desirable that the 50 or so patches that were already on master,
that the branch got rebased on top of, got mailed out again.


At heart, it is really the same issue. New commits were brought into
this branch, and thus if email notification is enabled for that branch,
then those commits should trigger emails for their own as well.

Typically, branches were non-fast-forward changes are allowed are
branches that are personal and not shared. In those instances,
the typical setup is to disable emails on those development branches.
It sounds to me like turning emails off for branches that can
do non-fast-forward is the better solution here.


Couldn't it be then per-branch setting, whether to mail even commits
that aren't new to the repository or not (like I understood it is already
possible to decide per-branch whether to send mails at all)?
E.g. for GCC, I'd certainly like to see mails for all commits on the
trunk and release branches (but we don't allow merge commits on them
anyway), and for other branches (personal, vendor, devel) I think mailing
only about new commits not already in the repository would be better over
not mailing at all.

Jakub



The alternative I suggested to Joseph yesterday was a separate mailing 
list for all the personal and vendor commits.  But I think that would 
need a change to the hooks infrastructure.


R.

Re: GCC GSoC 2020: Call for mentors and project ideas

[Nicholas Krause]

On 1/16/20 8:33 AM, Nathan Sidwell wrote:

On 1/15/20 5:45 PM, Martin Jambor wrote:


Therefore, first and foremost, I would like to ask all (moderately)
seasoned GCC contributors to consider mentoring a student this year and
ideally also come up with a project that they would like to lead.  I'm
collecting proposal on our wiki page
https://gcc.gnu.org/wiki/SummerOfCode - feel free to add yours to the
top list there.  Or, if you are unsure, post your offer and project idea
as a reply here to the mailing list.


I have an idea for a GNU-Make project.

* Separate Make's job-control from the dependency walking.  Right now, 
theses are somewhat tangled up, due to history.  It would be nice to 
separate these into distinct components.  One wrinkle may be that 
single-threaded invocation might need to preserve the 
(implementation-defined) order of dependent rule execution, as 
makefiles that do not completely specify dependencies might be relying 
on that.


I ran into this problem with my hack to add a module-server into make, 
and hacked around it in an ugly fashion.


(I've not run this by the GNU-Make maintainers)

nathan


Martin,
I've been looking into something similar to the scheduler for GCC 
parallelizing. Its a lot harder
than it seems due to IPA passes and other things like IPO. Not sure how 
Richard was planning to
handle that and unfortunately I've been busy and unable to write up my 
ideas for scaling GCC.


Since it may be awhile before it reaches the wiki page here is a link to 
a rough draft of my

ideas:https://docs.google.com/document/d/1po_RRgSCtRyYgMHjV0itW8iOzJXpTdHYIpC9gUMjOxk/edit?usp=sharing

I will be exploring the tooling issues when I'm time as that was my next 
step.


Sorry if there are grammar issues as its a rough draft,
Nick

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Jakub Jelinek]

On Thu, Jan 16, 2020 at 02:15:21PM +, Richard Earnshaw (lists) wrote:
> The alternative I suggested to Joseph yesterday was a separate mailing list
> for all the personal and vendor commits.  But I think that would need a
> change to the hooks infrastructure.

Would that solve it?  We have around 7500 to 8000 trunk commits a year
lately, so on the trunk+release branch mailing list it would be say 12000
mails a year, but if there are say 30 long lived devel/personal/vendor
branches that track trunk that would already mean 24 mails alone in
those merge commits.  Sure, for branches tracking release branches it will
be less than that.  As a random sample, I've picked a random gcc trunk test
added in June and it got merged into 5 tracking branches later on 6 branches
tracking release branches.  That was with svn (but that one sent one mail
per merge, not hundreds), but git encourages that people push their devel
branches upstream.

Jakub

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Joseph Myers]

On Thu, 16 Jan 2020, Joel Brobecker wrote:

> emails are to be sent. This happens for instance when people used
> development branches that they had silenced so as to avoid spamming
> people. And because they have been rebasing their branch regularly,
> the "merge" ended up being a fast-forward. And because it was a fast
> forward, the hooks saw that the commits were already known to the
> repository, and no email was sent at all for those new commits.

The approach used by post-receive-email is to send a summary email but 
without resending the already-sent commits.  That seems appropriate to me.

> Beyond this specific issue of users being surprised about the missing
> emails, we thought about it more, and it seemed logical that we would
> want a trace for each branch a commit makes it to. It's an essential
> element of being able to track where a given commit was applied.

A summary email just listing the commits merged seems much better than 
sending email maybe dozens of times for every commit to master.

> Typically, branches were non-fast-forward changes are allowed are
> branches that are personal and not shared. In those instances,
> the typical setup is to disable emails on those development branches.
> It sounds to me like turning emails off for branches that can
> do non-fast-forward is the better solution here.

I think it's desirable for development that *happens on* the personal and 
vendor branches to be visible in gcc-cvs - that is different from things 
getting merged into them.

Likewise for the refs/heads/devel/* development branches - 
non-fast-forward pushes are not permitted there, but such branches can 
expect to have lots of merges from master, and it's the actual development 
taking place *on* the branches - the new commits - that is of interest to 
see on gcc-cvs, not the merging of existing commits.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Joseph Myers]

On Thu, 16 Jan 2020, Jakub Jelinek wrote:

> Couldn't it be then per-branch setting, whether to mail even commits
> that aren't new to the repository or not (like I understood it is already
> possible to decide per-branch whether to send mails at all)?

Feel free to add such suggestions to the issues at 
 (this one is 
).  Those issues are meant 
to track all the cases where we think some changes to the hooks would be 
useful for GCC (whether or not we've currently addressed them with local 
changes to the hooks).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: PPC64 libmvec implementation of sincos

[GT]

‐‐‐ Original Message ‐‐‐
On Wednesday, January 15, 2020 3:20 PM, GT  wrote:

> ‐‐‐ Original Message ‐‐‐
> On Thursday, January 9, 2020 8:42 AM, Richard Biener 
> richard.guent...@gmail.com wrote:
>
> > As for the other question for testing you probably want to provide a
> > OMP simd declaration
> > of a function like
> > _Complex double mycexpi (double);
> > and make a testcase like
> > void foo (_Complex double * __restrict out, double *in)
> > {
> > for (int i = 0; i < 1024; ++i)
> > {
> > out[i] = mycexpi (in[i]);
> > }
> > }
> > or eventually with two output arrays and explicit __real/__imag
> > processing. The real
> > and main question is how is the OMP SIMD declaration of mycexpi looking 
> > like?
> > So I'd completely side-step sincos() and GCCs sincos() ->
> > __builtin_cepxi transform
> > and concentrate on OMP SIMD of a function with the signature we need to 
> > handle.
> > Richard.
>
> I think what is required here is to attach either #pragma omp declare simd 
> orattribute ((simd))
> to the declaration of builtin cexpi. In gcc/builtins.def, some attributes are 
> provided during
> creation of cexpi (line 656, call containing BUILT_IN_CEXPI). Attaching the 
> simd attributes to
> function declarations is how sin, cos, and the other math functions were 
> handled in math-vector.h
> glibc header file.

You probably intended that we first teach GCC how to vectorize any function 
which returns a
_Complex double and has a single parameter of type double. When that's done, 
move on to solving
the specific vectorization of __builtin_cexpi. Right?

Bert.

1-800-GIT-HELP: Fixing a commit message?

[Gerald Pfeifer]

It turns out I fumbled the commit message on the commit below to wwwdocs.

Instead of 
Redirect cvswrite.html to gitwrite.html instead of svnwrite.html.
I committed this with a message of 
Redirect cvs.html to git.html instead of svn.html.
and pushed already.

In CVS I could manually edit the ,v files; in SVN I believe we did
not want to allow for fixing commit messages a posteriori -- how 
about our Git setup?  Policy-wise and practically?

Gerald

== from gcc-patches ==
From: Gerald Pfeifer 
To: gcc-patc...@gcc.gnu.org
Date: Thu, 16 Jan 2020 19:15:28 +0100 (CET)
Subject: [PATCH] Redirect cvswrite.html to gitwrite.html instead of 
svnwrite.html.

I doubt there's many references to https://gcc.gnu.org/cvs.html 
left, but just in case - Git is the new SVN is the new CVS. :-)

Gerald
---
 htdocs/.htaccess | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/htdocs/.htaccess b/htdocs/.htaccess
index acaac093..a28af129 100644
--- a/htdocs/.htaccess
+++ b/htdocs/.htaccess
@@ -58,7 +58,7 @@ Redirect permanent /java/ 
https://gcc.gnu.org/
 
 Redirect permanent /bugs.html  https://gcc.gnu.org/bugs/
 Redirect permanent /c9xstatus.html 
https://gcc.gnu.org/c99status.html
-Redirect permanent /cvswrite.html  
https://gcc.gnu.org/svnwrite.html
+Redirect permanent /cvswrite.html  
https://gcc.gnu.org/gitwrite.html
 Redirect permanent /gnats.html https://gcc.gnu.org/bugs/
 Redirect permanent /proj-bp.html   
https://gcc.gnu.org/projects/bp/main.html
 Redirect permanent /proj-cpplib.html   
https://gcc.gnu.org/projects/cpplib.html
-- 
2.24.1

Re: 1-800-GIT-HELP: Fixing a commit message?

[Jakub Jelinek]

On Thu, Jan 16, 2020 at 07:51:37PM +0100, Gerald Pfeifer wrote:
> It turns out I fumbled the commit message on the commit below to wwwdocs.
> 
> Instead of 
> Redirect cvswrite.html to gitwrite.html instead of svnwrite.html.
> I committed this with a message of 
> Redirect cvs.html to git.html instead of svn.html.
> and pushed already.
> 
> In CVS I could manually edit the ,v files; in SVN I believe we did
> not want to allow for fixing commit messages a posteriori -- how 
> about our Git setup?  Policy-wise and practically?

In SVN one could do it and various people have done it (I see 96 svn:log
changed mails since we started using svn in gcc-cvs).
In Git, one can do it before pushing (git rebase -i), but it is highly
undesirable to do it after pushing (for some branches disallowed completely,
for wwwdocs maybe not but it will break everybody else who has checked it
out, including sourceware's automatic copy).

Jakub

Re: git conversion in progress

[Gerald Pfeifer]

On Thu, 16 Jan 2020, Jonathan Wakely wrote:
> On Thu, 16 Jan 2020 at 09:55, Georg-Johann Lay  wrote:
>> Hi, the front page reads "Our sources are readily and freely available
>> via SVN...", similar recommendation for SVN in
> Yes, it's been said more than once that the web pages will be updated
> once the docs for using git are ready.

I've been replacing references to SVN by ones to Git as time permits,
and hit that instance this evening:

  https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00990.html

Given that SVN does not work any more (in the sense that it's not
updated any longer, it still appears accessible if frozen), I don't
think that's harmful, and I believe what we have in place now isn't
actually too bad?

Gerald