Re: Git ChangeLog policy for GCC Testsuite inquiry
On Thu, Feb 6, 2020 at 11:25 PM Segher Boessenkool wrote: > > On Thu, Feb 06, 2020 at 03:01:20PM +0100, Richard Biener wrote: > > On Thu, Feb 6, 2020 at 2:51 PM Segher Boessenkool > > wrote: > > > If you rebase changelog files, then yes, it's a bloody pain ;-) > > > > So do you have a script that takes a commit with a ChangeLog at its end > > and populates the appropriate ChangeLog files? > > I develop my patches in Git, no changelog whatsoever. Then I "git > format-patch" it. I write the changelog in that file (also proper white > space, which "git commit" likes to destroy, I have a patch for that but > not installed everywhere). "git send-email", wait for ack if necessary, > "git am" and copy-and-paste the changelog parts, "git add" those > changelog files, "git commit --amend", final sanity checks, and "git > commit fsf master". I store the patch file to my archive, or I queue it > for backport directly. > > > I'm trying to come up with > > one to make the process less manual ... > > Yeah, don't look at me then :-) > > I *like* having most of those steps, most of this should only be done by > people who are awake. > > > it's definitely a part that requires > > more typing compared to svn. > > Instead of "git am" I had "patch -p1 <", distributing the changelog parts > I just did in vi (as with git), then "svn ci", which pick up all modified > files directly (sometimes an "svn add" first). It's pretty much the same > for me. I'm a believer on committing from the tree I actually tested, so it was with SVN: patch, test, svn up, edit changelogs (cut&paste from the patch header), svn diff | less (check wha'ts abotu to be committed), svn commit with GIT its now: patch, test, git add/commit, git pull --rebase, edit changelogs (cut&paste from the patch header), git commit --amend, git push -n -v, git show , git push So I wonder to "optimize" this somewhat. > > ChangeLog file populating could be even > > done on the server-side I guess (and not appropriately formatted logs > > for the extraction/moving process rejected). > > Yup. As long as it's fool-proof, and we have some way to correct small > disasters (both of those!) I'd definitely prefer server-side operation, and yes, that "script" looking at the commit would need to have a "extract changelog parts" part for a pre-accept hook and the actual part amending the commit with the changelog file changes (not sure if that's even possible in a hook?). Fixing mistakes in the ChangeLog files could be as easy as allowing changes to ChangeLog files without that magic. Anyway, I hope to put sth together with bash & [g]awk Richard. > > Segher
Re: Git ChangeLog policy for GCC Testsuite inquiry
On Fri, 7 Feb 2020 at 09:20, Richard Biener wrote: > > On Thu, Feb 6, 2020 at 11:25 PM Segher Boessenkool > wrote: > > Instead of "git am" I had "patch -p1 <", distributing the changelog parts > > I just did in vi (as with git), then "svn ci", which pick up all modified > > files directly (sometimes an "svn add" first). It's pretty much the same > > for me. > > I'm a believer on committing from the tree I actually tested, so it With Git you can't really have unwanted local commits present in a tree if you use a sensible workflow, so if you tested in a tree that was at commit 1234abcd and you push from another machine that is at the same commit, you know there are no unintended differences. > was with SVN: patch, test, svn up, edit changelogs (cut&paste from the > patch header), svn diff | less (check wha'ts abotu to be committed), svn > commit > with GIT its now: patch, test, git add/commit, There is no good reason to delay add+commit until after testing. Committing locally is a completely different operation from committing to svn, because nothing is "final" until you push to gcc.gnu.org. I commit locally, and then either test locally or push to larger machines where I test, or test in both places at once. Even if you only work on one machine, keeping uncommitted changes around is error prone (it's easier to lose the work, it's easier to not realise exactly what you're testing, it's harder to verify that what you tested is what you eventually pushed). Applying somebody else's patch to test it can be done in a local branch and committed locally. You can always delete that branch later to clear up (a naming convention like "patch-20200207-foo-bar" helps to keep those branches clearly labelled so you can easily decide which to remove later). Once you've committed something it has a commit hash to identify it, so you can easily compare the state at that revision to some other revision, at any later time. tl;dr make more use of branches.
Re: Git ChangeLog policy for GCC Testsuite inquiry
Hi! On Fri, Feb 07, 2020 at 10:19:56AM +0100, Richard Biener wrote: > On Thu, Feb 6, 2020 at 11:25 PM Segher Boessenkool > wrote: > > Yeah, don't look at me then :-) > > > > I *like* having most of those steps, most of this should only be done by > > people who are awake. > > > > > it's definitely a part that requires > > > more typing compared to svn. > > > > Instead of "git am" I had "patch -p1 <", distributing the changelog parts > > I just did in vi (as with git), then "svn ci", which pick up all modified > > files directly (sometimes an "svn add" first). It's pretty much the same > > for me. > > I'm a believer on committing from the tree I actually tested, But you cannot. Depending on which machine I use, a regstrap (all languages) is between 2h and 40m, so when you push it upstream there will usually be commits by other people as well. I also test just master plus what I want to commit, which works fine most of the time. The master you test with is older than the one you commit to (and yes, this sometimes matters :-/ ). > so it > was with SVN: patch, test, svn up, edit changelogs (cut&paste from the > patch header), svn diff | less (check wha'ts abotu to be committed), svn > commit > with GIT its now: patch, test, git add/commit, git pull --rebase, edit > changelogs > (cut&paste from the patch header), git commit --amend, git push -n -v, > git show , git push > > So I wonder to "optimize" this somewhat. Having the patch as a file instead of just as a git commit makes the cut-and-paste step a little easier (and more reliable). Once you have done this many many times, you can skip some of the verification steps because you just *know* the state of everything. So things will be a little faster over time, or at least it will feel that way. Handling the changelog as you want will make things more streamlined, certainly. It also makes it easier to mess things up... We'll see what will happen, I guess :-) > > > ChangeLog file populating could be even > > > done on the server-side I guess (and not appropriately formatted logs > > > for the extraction/moving process rejected). > > > > Yup. As long as it's fool-proof, and we have some way to correct small > > disasters (both of those!) > > I'd definitely prefer server-side operation, and yes, that "script" looking > at the commit would need to have a "extract changelog parts" part > for a pre-accept hook and the actual part amending the commit with > the changelog file changes (not sure if that's even possible in a hook?). If you can think of it, it is possible. It's not even too hard I think. You want the commit hook to actually populate the changelog files, which are still normal checked-in files, aha! That's a great idea. That completely gets rid of my "fix mistakes" worries, and it will probably also get rid of the "yet another flag day" inconvenience. > Fixing mistakes in the ChangeLog files could be as easy as allowing > changes to ChangeLog files without that magic. Yeah :-) > Anyway, I hope to put sth together with bash & [g]awk gl;hf Should we require some simple markup in the commit message before the changelogs? Maybe CL gcc/ * blablalba etc. CL gcc/testsuite/ * gcc.target/... etc. (Dunno if just "^CL " is too short?) Segher
Re: Git ChangeLog policy for GCC Testsuite inquiry
On 07/02/2020 13:48, Segher Boessenkool wrote: Hi! On Fri, Feb 07, 2020 at 10:19:56AM +0100, Richard Biener wrote: On Thu, Feb 6, 2020 at 11:25 PM Segher Boessenkool wrote: Yeah, don't look at me then :-) I *like* having most of those steps, most of this should only be done by people who are awake. it's definitely a part that requires more typing compared to svn. Instead of "git am" I had "patch -p1 <", distributing the changelog parts I just did in vi (as with git), then "svn ci", which pick up all modified files directly (sometimes an "svn add" first). It's pretty much the same for me. I'm a believer on committing from the tree I actually tested, But you cannot. Depending on which machine I use, a regstrap (all languages) is between 2h and 40m, so when you push it upstream there will usually be commits by other people as well. I also test just master plus what I want to commit, which works fine most of the time. The master you test with is older than the one you commit to (and yes, this sometimes matters :-/ ). so it was with SVN: patch, test, svn up, edit changelogs (cut&paste from the patch header), svn diff | less (check wha'ts abotu to be committed), svn commit with GIT its now: patch, test, git add/commit, git pull --rebase, edit changelogs (cut&paste from the patch header), git commit --amend, git push -n -v, git show , git push So I wonder to "optimize" this somewhat. Having the patch as a file instead of just as a git commit makes the cut-and-paste step a little easier (and more reliable). Once you have done this many many times, you can skip some of the verification steps because you just *know* the state of everything. So things will be a little faster over time, or at least it will feel that way. Handling the changelog as you want will make things more streamlined, certainly. It also makes it easier to mess things up... We'll see what will happen, I guess :-) ChangeLog file populating could be even done on the server-side I guess (and not appropriately formatted logs for the extraction/moving process rejected). Yup. As long as it's fool-proof, and we have some way to correct small disasters (both of those!) I'd definitely prefer server-side operation, and yes, that "script" looking at the commit would need to have a "extract changelog parts" part for a pre-accept hook and the actual part amending the commit with the changelog file changes (not sure if that's even possible in a hook?). If you can think of it, it is possible. It's not even too hard I think. You want the commit hook to actually populate the changelog files, which are still normal checked-in files, aha! That's a great idea. That completely gets rid of my "fix mistakes" worries, and it will probably also get rid of the "yet another flag day" inconvenience. Fixing mistakes in the ChangeLog files could be as easy as allowing changes to ChangeLog files without that magic. Yeah :-) Anyway, I hope to put sth together with bash & [g]awk gl;hf Should we require some simple markup in the commit message before the changelogs? Maybe CL gcc/ * blablalba etc. CL gcc/testsuite/ * gcc.target/... etc. (Dunno if just "^CL " is too short?) I was thinking "@CL ", but ^CL would work just as well. Any script should, in addition to extracting the author and email also grep for "Co-authored-by:" annotations and add those as additional contributors, of course. R. Segher
Matching and testing against smulhsm3
Hello!
I am trying to implement the following insns for my back end: smulhssi3,
smulhshi3, smulhsqi3
According to [1], the operation should be equivalent to:
narrow op0, op1, op2;
op0 = (narrow) (((wide) op1 * (wide) op2) >> (N / 2 - 1));
...so I tried to write a corresponding matching pattern, like so:
(define_insn "smulhshi3"
[(set (match_operand:HI 0 "register_operand" "=r")
(truncate:HI
(ashiftrt:SI
(mult:SI
(sign_extend:SI (match_operand:HI 1 "register_operand" "r"))
(sign_extend:SI (match_operand:HI 2 "register_operand" "r")))
(const_int 15]
"TARGET_PACKED_OPS"
"mulq.h\\t%0, %1, %2")
However, I am unable to trigger this code path. I have tried with the
following C code:
short mulq(short op1, short op2) {
return (short) (((int) op1 * (int) op2) >> (32 / 2 - 1));
}
But I just get the regular 4-instruction result (2x sign extend, 1x mul,
1x shift).
Are there any builtins that I need to use, or anything that I need to
enable for my back end? Or should I use another pattern?
I also have similar problems with avgsi3_floor and friends.
Regards,
Marcus
[1] https://gcc.gnu.org/onlinedocs/gccint/Standard-Names.html
Re: Git ChangeLog policy for GCC Testsuite inquiry
On Fri, Feb 07, 2020 at 01:56:08PM +, Richard Earnshaw (lists) wrote: > On 07/02/2020 13:48, Segher Boessenkool wrote: > >Should we require some simple markup in the commit message before the > >changelogs? Maybe > > > >CL gcc/ > > * blablalba etc. > >CL gcc/testsuite/ > > * gcc.target/... > > >etc. > > > >(Dunno if just "^CL " is too short?) > > I was thinking "@CL ", but ^CL would work just as well. I meant ^ as in a regular expression, sorry for not being clear. > Any script should, in addition to extracting the author and email also > grep for "Co-authored-by:" annotations and add those as additional > contributors, of course. Is there no existing established practice for that? (Or is this it and so infrquent that I never have seen it :-) ) Segher
Re: Git ChangeLog policy for GCC Testsuite inquiry
On 07/02/2020 15:32, Segher Boessenkool wrote: On Fri, Feb 07, 2020 at 01:56:08PM +, Richard Earnshaw (lists) wrote: On 07/02/2020 13:48, Segher Boessenkool wrote: Should we require some simple markup in the commit message before the changelogs? Maybe CL gcc/ * blablalba etc. CL gcc/testsuite/ * gcc.target/... etc. (Dunno if just "^CL " is too short?) I was thinking "@CL ", but ^CL would work just as well. I meant ^ as in a regular expression, sorry for not being clear. Ah! I think something more syntactically explicit would help avoid the risk of mis-parsing. Any script should, in addition to extracting the author and email also grep for "Co-authored-by:" annotations and add those as additional contributors, of course. Is there no existing established practice for that? (Or is this it and so infrquent that I never have seen it :-) ) It's a convention (much like signed-off-by, etc). But it's fairly widely accepted. In the git conversion we added fields for it where we detected co-authorship in the ChangeLog entries. Git has no specific field for recording additional authors, so this approach addresses this and some tools know how to add the appropriate accreditation based on it. https://git.wiki.kernel.org/index.php/CommitMessageConventions Also "git help interpret-trailers" R. Segher
Re: Matching and testing against smulhsm3
Hi!
On Fri, Feb 07, 2020 at 03:41:25PM +0100, m wrote:
> ...so I tried to write a corresponding matching pattern, like so:
>
> (define_insn "smulhshi3"
> [(set (match_operand:HI 0 "register_operand" "=r")
> (truncate:HI
> (ashiftrt:SI
> (mult:SI
> (sign_extend:SI (match_operand:HI 1
> "register_operand" "r"))
> (sign_extend:SI (match_operand:HI 2
> "register_operand" "r")))
> (const_int 15]
> "TARGET_PACKED_OPS"
> "mulq.h\\t%0, %1, %2")
>
> However, I am unable to trigger this code path. I have tried with the
> following C code:
>
> short mulq(short op1, short op2) {
> return (short) (((int) op1 * (int) op2) >> (32 / 2 - 1));
> }
>
> But I just get the regular 4-instruction result (2x sign extend, 1x mul,
> 1x shift).
What does -fdump-rtl-combine-all show it tried? *Did* it try anything?
Segher
Re: Git ChangeLog policy for GCC Testsuite inquiry
On Fri, Feb 07, 2020 at 03:43:05PM +, Richard Earnshaw (lists) wrote: > On 07/02/2020 15:32, Segher Boessenkool wrote: > >On Fri, Feb 07, 2020 at 01:56:08PM +, Richard Earnshaw (lists) wrote: > >>Any script should, in addition to extracting the author and email also > >>grep for "Co-authored-by:" annotations and add those as additional > >>contributors, of course. > > > >Is there no existing established practice for that? (Or is this it and > >so infrquent that I never have seen it :-) ) > > It's a convention (much like signed-off-by, etc). But it's fairly > widely accepted. Apparently it is mainly a github thing. > In the git conversion we added fields for it where we > detected co-authorship in the ChangeLog entries. Git has no specific > field for recording additional authors, Yup. I think in the future we will see a lot more Suggested-by: and Reviewed-by: and Tested-by: and the like, and less of what we now mark as co-authoring (also because there will be more smaller commits). Segher
Re: Git ChangeLog policy for GCC Testsuite inquiry
> "Jonathan" == Jonathan Wakely writes: Jonathan> I have a script that does the opposite, which I've been using for Jonathan> years. I edit the ChangeLog files as before, and a Git Jonathan> prepare-commit-msg hook extracts the top changelog entry from each Jonathan> file in the commit and pre-populates my commit msg with those entries. Jonathan> To use it just put the two prepare-commit-msg* files from Jonathan> https://gitlab.com/miscripts/miscripts/-/tree/master/gcc into your Jonathan> $GCC_SRC/.git/hooks directory. I do this too, combined with scripts to handle merge ChangeLogs specially during rebase; scripts to update the dates on ChangeLog files before pushing; and a wrapper for "git send-email" that strips the ChangeLogs from the email (part of gdb patch submission rules). You can find it all here https://github.com/tromey/git-gnu-changelog Tom
Re: Git ChangeLog policy for GCC Testsuite inquiry
On Fri, Feb 7, 2020 at 1:44 PM Tom Tromey wrote: > > > "Jonathan" == Jonathan Wakely writes: > > Jonathan> I have a script that does the opposite, which I've been using for > Jonathan> years. I edit the ChangeLog files as before, and a Git > Jonathan> prepare-commit-msg hook extracts the top changelog entry from each > Jonathan> file in the commit and pre-populates my commit msg with those > entries. > > Jonathan> To use it just put the two prepare-commit-msg* files from > Jonathan> https://gitlab.com/miscripts/miscripts/-/tree/master/gcc into your > Jonathan> $GCC_SRC/.git/hooks directory. > > I do this too, combined with scripts to handle merge ChangeLogs > specially during rebase; scripts to update the dates on ChangeLog files > before pushing; and a wrapper for "git send-email" that strips the > ChangeLogs from the email (part of gdb patch submission rules). I omit ChangeLogs by adding ':!*/ChangeLog' to the end of the git send-email command. I don't remember where I found that incantation. > You can find it all here > > https://github.com/tromey/git-gnu-changelog > > Tom >
Re: Git ChangeLog policy for GCC Testsuite inquiry
> "Jason" == Jason Merrill writes: Jason> I omit ChangeLogs by adding ':!*/ChangeLog' to the end of the git Jason> send-email command. I don't remember where I found that incantation. Cool, I did not know about this. FWIW if you have the ChangeLog merger available, it's actually more convenient if the patch includes the ChangeLog, because then applying it with "git am" does the right thing. Without this you have to edit the ChangeLogs by hand instead. Tom
gcc-8-20200207 is now available
Snapshot gcc-8-20200207 is now available on https://gcc.gnu.org/pub/gcc/snapshots/8-20200207/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-8 revision aea14ca89283707f52c1cf68fb730dd158797081 You'll find: gcc-8-20200207.tar.xzComplete GCC SHA256=473e44f80dee4a48b226a42a99a9729854c159538ac18fe8e43b3130973fc641 SHA1=2e96698155deb23a28d448c4871a5386596afa77 Diffs from 8-20200131 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: Git ChangeLog policy for GCC Testsuite inquiry
On Fri, Feb 07, 2020 at 10:08:25AM +, Jonathan Wakely wrote: > With Git you can't really have unwanted local commits present in a > tree if you use a sensible workflow, so if you tested in a tree that > was at commit 1234abcd and you push from another machine that is at > the same commit, you know there are no unintended differences. Maybe I don't have a sensible workflow, but often with lots of tiddly little binutils patches I don't bother with branches for everything. (I do use branches for larger work.) I also like to test my patches. I'll test individually on a few relevant targets but do a test over a large number of targets (162 currently) for a bunch of patches. Some of those patches tested might not be ready for commit upstream (lacking comments, changelogs, even lacking that vital self review), so I'll "git rebase -i" to put the ones that are ready first, then "git push origin :master" just to push up to the relevant commit. That works quite well for me. -- Alan Modra Australia Development Lab, IBM
