Re: Commit messages and the move to git

2019-11-08 Thread Richard Earnshaw (lists)

On 07/11/2019 14:27, Eric S. Raymond wrote:

Jeff Law :

On 11/4/19 3:29 AM, Richard Earnshaw (lists) wrote:

With the move to git fairly imminent now it would be nice if we could
agree on a more git-friendly style of commit messages; and, ideally,
start using them now so that the converted repository can benefit from
this.

Some tools, particularly gitk or git log --oneline, can use one-line
summaries from a commit's log message when listing commits.  It would be
nice if we could start adopting a style that is compatible with this, so
that in future commits are summarized in a useful way.  Unfortunately,
some of our existing commits show no useful information with tools like
this.

I'd suggest we sync policy with glibc.  They're further along on the
ChangeLog issues.  Whatever they do in this space we should follow --
aren't we going to be using some of their hooks/scripts?


Note that my reposurgeon conversion recipe runs gitify on the repository.

 From the documentation:

 Attempt to massage comments into a git-friendly form with a blank
 separator line after a summary line.  This code assumes it can insert
 a blank line if the first line of the comment ends with '.', ',', ':',
 ';', '?', or '!'.  If the separator line is already present, the comment
 won't be touched.

 Takes a selection set, defaulting to all commits and tags.



Which makes me wonder if, given a commit log of the form:


2019-10-30  Richard Biener  

PR tree-optimization/92275
* tree-vect-loop-manip.c (slpeel_update_phi_nodes_for_loops):
Copy all loop-closed PHIs.

* gcc.dg/torture/pr92275.c: New testcase.

Where the first line is a ChangeLog style date and author, we could spot 
the PR line below that and hoist it up as a more useful summary (perhaps 
by copying it rather than moving it).


It wouldn't fix all commits, but even just doing this for those that 
have PRs would be a help.


R.


Re: GCC 7.5 Release Candidate available from gcc.gnu.org

2019-11-08 Thread Bill Schmidt

On 11/7/19 5:48 AM, Matthias Klose wrote:

On 05.11.19 13:45, Richard Biener wrote:


The first release candidate for GCC 7.5 is available from

  https://gcc.gnu.org/pub/gcc/snapshots/7.5.0-RC-20191105/

and shortly its mirrors.  It has been generated from SVN revision 
277823.


I have so far bootstrapped and tested the release candidate on
{x86_64,i586,ppc64le,s390x,aarch64}-linux.  Please test it
and report any issues to bugzilla.

If all goes well, I'd like to release 7.5 on Thursday, November 14th.


With a distribution build (Ubuntu) on amd64, i386, armhf, arm64, 
ppc64el and s390x, I don't see any regressions in the GCC testsuite 
(compared to 7.4.0), except for two issues on ppc64el:


FAIL: gcc.target/powerpc/pr87532.c (test for excess errors)
Excess errors:
/build/gcc-7-8odB_r/gcc-7-7.4.0/src/gcc/testsuite/gcc.target/powerpc/pr87532.c:45:27: 
warning: format '%d' expects argument of type 'int', but argument 2 
has type 'size_t {aka long unsigned int}' [-Wformat=]


is a new test, and only caused by default hardening settings.

PASS: gcc.dg/vect/slp-perm-4.c execution test
FAIL: gcc.dg/vect/slp-perm-4.c scan-tree-dump-times vect "vectorized 1 
loops" 1
PASS: gcc.dg/vect/slp-perm-4.c scan-tree-dump-times vect "gaps 
requires scalar epilogue loop" 0
FAIL: gcc.dg/vect/slp-perm-4.c scan-tree-dump-times vect "vectorizing 
stmts using SLP" 1



I finally bisected this to r275208:


2019-08-30  Richard Biener  mailto:rguenther%40suse.de>>

Backport from mainline
2019-05-27  Richard Biener  mailto:rguenther%40suse.de>>

PR tree-optimization/90637
* tree-ssa-sink.c (statement_sink_location): Honor the
computed sink location for single-uses.

* gcc.dg/gomp/pr90637.c: New testcase.

2019-06-21  Richard Biener  mailto:rguenther%40suse.de>>

PR tree-optimization/90930
* tree-ssa-reassoc.c (rewrite_expr_tree_parallel): Set visited
flag on new stmts to avoid re-processing them.

2019-05-15  Richard Biener  mailto:rguenther%40suse.de>>

PR c/90474
* c-common.c (c_common_mark_addressable_vec): Also mark
a COMPOUND_LITERAL_EXPR_DECL addressable similar to
c_mark_addressable.

2019-04-25  Richard Biener  mailto:rguenther%40suse.de>>

PR middle-end/90194
* match.pd: Add pattern to simplify view-conversion of an
empty constructor.

* g++.dg/torture/pr90194.C: New testcase.

2019-04-24  Richard Biener  mailto:rguenther%40suse.de>>

PR middle-end/90213
* gimple-fold.c (fold_const_aggregate_ref_1): Do multiplication
by size and BITS_PER_UNIT on poly-wide-ints.

2019-04-15  Richard Biener  mailto:rguenther%40suse.de>>

PR tree-optimization/90071
* tree-ssa-reassoc.c (init_range_entry): Do not pick up
abnormal operands from def stmts.

* gcc.dg/torture/pr90071.c: New testcase.

2019-03-13  Richard Biener  mailto:rguenther%40suse.de>>

PR middle-end/89677
* tree-scalar-evolution.c (simplify_peeled_chrec): Do not
throw FP expressions at tree-affine.

* gcc.dg/torture/pr89677.c: New testcase.


This looks rather familiar, actually.  I seem to recall an SLP 
degradation from a change to tree-ssa-sink.c on trunk this release.  
Richi, could there be a missing backport here?



Bill




Matthias


gcc-8-20191108 is now available

2019-11-08 Thread gccadmin
Snapshot gcc-8-20191108 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/8-20191108/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8-branch 
revision 277993

You'll find:

 gcc-8-20191108.tar.xzComplete GCC

  SHA256=97ed351232b7c141e1c34b45423dd14d0269fa78898712b3b2e40129dcf6a385
  SHA1=e0c1218004f11f40cae96c3757b960a7ba908632

Diffs from 8-20191101 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: Commit messages and the move to git

2019-11-08 Thread Eric S. Raymond
Richard Earnshaw (lists) :
> Which makes me wonder if, given a commit log of the form:
> 
> 
> 2019-10-30  Richard Biener  
> 
> PR tree-optimization/92275
> * tree-vect-loop-manip.c (slpeel_update_phi_nodes_for_loops):
> Copy all loop-closed PHIs.
> 
> * gcc.dg/torture/pr92275.c: New testcase.
> 
> Where the first line is a ChangeLog style date and author, we could spot the
> PR line below that and hoist it up as a more useful summary (perhaps by
> copying it rather than moving it).
> 
> It wouldn't fix all commits, but even just doing this for those that have
> PRs would be a help.

Speaking from lots of experience with converting old repositories that
exhibited similar comment conventions, I would be nervous about trying
to do this entirely mechanically.  I think the risk of mangling text
that is not fornatted as you expect - and not noticing that until the 
friction cost of fixing it has escalated - is rather high.

On the other hand, reposurgeon allows a semi-neechanized attack on
the problem that I think would work well, because I've done similar 
things in ither coversions.

There's a pair of commands that allow you to (a) extract comments from
a range of commits into a message list that looks like an RFC822
mailbox file, (b) modify those comments, and (c) weave the the message
list reliably back into the repository.

If it were me doing this job, I'd write a reposurgeon command that
extracts all the comments containing PR strings into a message box
Then I'd write an Emacs macro that moves to the next nessage and
hoists its PR line.

Then I'd walk through the comments applying the macro and keeping an eye on 
them for cases where what the macro doesn't do quite the right thing and 
using undo and hand-editing to recover.  Human eyes are very good at 
spotting anomalies in an expected flow of textm and once you've gotten
into the rhythm of a task like this is is easily possible to filter
approximately a message per second. In round numbers, providing
the anomaly rate isn't high, that's upwards of 3000 messages per hour.

The point is that for this kind of task a hnman being who undertands 
what he's reading is likely to have a lower rate of mangling errors than
a program that doesn't.
-- 
http://www.catb.org/~esr/";>Eric S. Raymond