Re: Commit messages and the move to git
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
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
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
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