Re: ChangeLog files - server and client scripts
Hi, Martin,
On May 26, 2020, Martin Liška wrote:
>> I've long used the following syntax to start ChangeLog entries:
>>
>> for /ChangeLog
> Ah, it's new for me.
>>
>> It was introduced over 20 years ago, with the (so far never formally
>> released) GNU CVS-Utilities. Among other goodies, there were scripts to
>> turn diffs for ChangeLog files into the above format, and vice-versa,
>> that I've used to this day. It went through cvs, svn and git. It would
>> be quite nice if I could keep on using it with GCC. ^^
For clarity, I meant the syntax in the last sentence above. The
ChangeLog-related functionality in the scripts now becomes mostly
obsolete.
>> The patch below seems to be enough to pass gcc-verify, and to recognize
>> and print the expected ChangeLog files.
'cept it broke cases without 'for' because I missed a '?' in the
regexp. Good thing I had to adjust for the old format to be able to
push it ;-) 2x0 ;-)
>> Do any hooks need to be adjusted to match?
> Yes, we sync the script from the GCC repository.
Here's what I'm about to push
accept for dir/ChangeLog entries
From: Alexandre Oliva
I've long introduced ChangeLog entries as "for dir/ChangeLog", a
format adopted by GNU CVS-Utilities some 20 years ago. My commits
have been formatted like this forever.
This patch makes it acceptable for git gcc-verify.
contrib/ChangeLog:
* gcc-changelog/git_commit.py (changelog_regex): Accept optional
'for' prefix.
---
contrib/gcc-changelog/git_commit.py |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/gcc-changelog/git_commit.py
b/contrib/gcc-changelog/git_commit.py
index 2cfdbc8..732a9bd8 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -144,7 +144,7 @@ misc_files = [
author_line_regex = \
re.compile(r'^(?P\d{4}-\d{2}-\d{2})\ {2}(?P.* <.*>)')
additional_author_regex = re.compile(r'^\t(?P\ *)?(?P.* <.*>)')
-changelog_regex = re.compile(r'^([a-z0-9+-/]*)/ChangeLog:?')
+changelog_regex = re.compile(r'^(?:[fF]or +)?([a-z0-9+-/]*)/ChangeLog:?')
pr_regex = re.compile(r'\tPR (?P[a-z+-]+\/)?([0-9]+)$')
dr_regex = re.compile(r'\tDR ([0-9]+)$')
star_prefix_regex = re.compile(r'\t\*(?P\ *)(?P.*)')
--
Alexandre Oliva, freedom fighterhe/himhttps://FSFLA.org/blogs/lxo/
Free Software Evangelist Stallman was right, but he's left :(
GNU Toolchain Engineer Live long and free, and prosper ethically
Re: [IMPORTANT] ChangeLog related changes
Am 26.05.20 um 00:48 schrieb Jakub Jelinek via Gcc:
I've turned the strict mode of Martin Liška's hook changes,
This means that it is no longer possible to do a git gcc-backport
followed by a git push. If there is a procedure for this, it
is not documented on https://gcc.gnu.org/gitwrite.html .
Please document this, or (even more preferred) automate the process
so that git gcc-backport does not touch the ChangeLog files.
Regards
Thomas
$ git gcc-backport r11-588-g8df7ee67f6fdc780e9453f2baa8d1bf62c000761
automatischer Merge von libgomp/ChangeLog
automatischer Merge von libgfortran/ChangeLog
automatischer Merge von gcc/fortran/ChangeLog
[releases/gcc-10 bb55bfe5871] Fixes a hang on an invalid ID in a WAIT
statement.
Date: Sat May 23 19:01:43 2020 +0200
7 files changed, 50 insertions(+)
create mode 100644 libgomp/testsuite/libgomp.fortran/async_io_9.f90
$ git push
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "de_DE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Objekte aufzählen: 31, Fertig.
Zähle Objekte: 100% (31/31), Fertig.
Delta-Kompression verwendet bis zu 16 Threads.
Komprimiere Objekte: 100% (17/17), Fertig.
Schreibe Objekte: 100% (17/17), 3.93 KiB | 3.93 MiB/s, Fertig.
Gesamt 17 (Delta 14), Wiederverwendet 0 (Delta 0), Pack wiederverwendet 0
remote: *** ChangeLog format failed:
remote: ERR: ChangeLog, DATESTAMP, BASE-VER and DEV-PHASE updates should
be done separately from normal commits
remote:
remote: Please see: https://gcc.gnu.org/codingconventions.html#ChangeLogs
remote:
remote: error: hook declined to update refs/heads/releases/gcc-10
To git+ssh://gcc.gnu.org/git/gcc.git
! [remote rejected] releases/gcc-10 -> releases/gcc-10 (hook
declined)
error: Fehler beim Versenden einiger Referenzen nach
'git+ssh://tkoe...@gcc.gnu.org/git/gcc.git'
which means that from now on no commits to the trunk or release branches
should be changing any ChangeLog files together with the other files,
ChangeLog entry should be solely in the commit message.
The DATESTAMP bumping script will be updating the ChangeLog files for you.
If somebody makes a mistake in that, please wait 24 hours (at least until
after 00:16 UTC after your commit) so that the script will create the
ChangeLog entries, and afterwards it can be fixed by adjusting the ChangeLog
files. But you can only touch the ChangeLog files in that case (and
shouldn't write a ChangeLog entry for that in the commit message).
If anything goes wrong, please let me, other RMs and Martin Liška know.
Jakub
Re: Automatically generated ChangeLog files - script
Hello Martin, First, thank you for your work on this new ChangeLog workflow. :-) I’d like to report a “regression”: I can’t push the attached patch: remote: *** ChangeLog format failed: remote: ERR: changed file not mentioned in a ChangeLog:"gcc/ada/sem_ch4.adb" remote: ERR: changed file not mentioned in a ChangeLog:"gcc/ada/sem_ch7.adb" remote: ERR: changed file not mentioned in a ChangeLog:"gcc/ada/sem_ch8.adb" remote: ERR: changed file not mentioned in a ChangeLog:"gcc/ada/sem_elab.adb" remote: ERR: changed file not mentioned in a ChangeLog:"gcc/ada/sem_type.adb" remote: ERR: changed file not mentioned in a ChangeLog:"gcc/ada/sem_util.adb" remote: remote: Please see: https://gcc.gnu.org/codingconventions.html#ChangeLogs remote: remote: error: hook declined to update refs/heads/master It looks like the hook does not accept multi-line ChangeLog entries affecting multiple files: * contracts.adb, einfo.adb, exp_ch9.adb, sem_ch12.adb, sem_ch4.adb, sem_ch7.adb, sem_ch8.adb, sem_elab.adb, sem_type.adb, sem_util.adb: Reuse Is_Package_Or_Generic_Package where possible (similarly, reuse Is_Concurrent_Type if it was possible in the same expressions). Would it be possible to enhance the hook to support that? Thanks! -- Pierre-Marie de Rodat >From 557b268fdeb0980a17411f458eee333f55c6 Mon Sep 17 00:00:00 2001 From: Piotr Trojanek Date: Thu, 12 Dec 2019 11:45:24 +0100 Subject: [PATCH] [Ada] Reuse Is_Package_Or_Generic_Package where possible 2020-05-26 Piotr Trojanek gcc/ada/ * contracts.adb, einfo.adb, exp_ch9.adb, sem_ch12.adb, sem_ch4.adb, sem_ch7.adb, sem_ch8.adb, sem_elab.adb, sem_type.adb, sem_util.adb: Reuse Is_Package_Or_Generic_Package where possible (similarly, reuse Is_Concurrent_Type if it was possible in the same expressions). --- gcc/ada/contracts.adb | 2 +- gcc/ada/einfo.adb | 22 +++--- gcc/ada/exp_ch9.adb | 2 +- gcc/ada/sem_ch12.adb | 2 +- gcc/ada/sem_ch4.adb | 2 +- gcc/ada/sem_ch7.adb | 6 +++--- gcc/ada/sem_ch8.adb | 6 +++--- gcc/ada/sem_elab.adb | 2 +- gcc/ada/sem_type.adb | 2 +- gcc/ada/sem_util.adb | 6 +++--- 10 files changed, 26 insertions(+), 26 deletions(-) diff --git a/gcc/ada/contracts.adb b/gcc/ada/contracts.adb index 981bb91..d58f136 100644 --- a/gcc/ada/contracts.adb +++ b/gcc/ada/contracts.adb @@ -213,7 +213,7 @@ package body Contracts is --Initializes --Part_Of (instantiation only) - elsif Ekind_In (Id, E_Generic_Package, E_Package) then + elsif Is_Package_Or_Generic_Package (Id) then if Nam_In (Prag_Nam, Name_Abstract_State, Name_Initial_Condition, Name_Initializes) diff --git a/gcc/ada/einfo.adb b/gcc/ada/einfo.adb index 98b508f..1df8ed0 100644 --- a/gcc/ada/einfo.adb +++ b/gcc/ada/einfo.adb @@ -713,7 +713,7 @@ package body Einfo is function Abstract_States (Id : E) return L is begin - pragma Assert (Ekind_In (Id, E_Generic_Package, E_Package)); + pragma Assert (Is_Package_Or_Generic_Package (Id)); return Elist25 (Id); end Abstract_States; @@ -837,7 +837,7 @@ package body Einfo is function Body_Entity (Id : E) return E is begin - pragma Assert (Ekind_In (Id, E_Package, E_Generic_Package)); + pragma Assert (Is_Package_Or_Generic_Package (Id)); return Node19 (Id); end Body_Entity; @@ -1424,8 +1424,8 @@ package body Einfo is function First_Private_Entity (Id : E) return E is begin - pragma Assert (Ekind_In (Id, E_Package, E_Generic_Package) - or else Ekind (Id) in Concurrent_Kind); + pragma Assert (Is_Package_Or_Generic_Package (Id) + or else Is_Concurrent_Type (Id)); return Node16 (Id); end First_Private_Entity; @@ -3044,7 +3044,7 @@ package body Einfo is function Package_Instantiation (Id : E) return N is begin - pragma Assert (Ekind_In (Id, E_Package, E_Generic_Package)); + pragma Assert (Is_Package_Or_Generic_Package (Id)); return Node26 (Id); end Package_Instantiation; @@ -3883,7 +3883,7 @@ package body Einfo is procedure Set_Abstract_States (Id : E; V : L) is begin - pragma Assert (Ekind_In (Id, E_Generic_Package, E_Package)); + pragma Assert (Is_Package_Or_Generic_Package (Id)); Set_Elist25 (Id, V); end Set_Abstract_States; @@ -4006,7 +4006,7 @@ package body Einfo is procedure Set_Body_Entity (Id : E; V : E) is begin - pragma Assert (Ekind_In (Id, E_Package, E_Generic_Package)); + pragma Assert (Is_Package_Or_Generic_Package (Id)); Set_Node19 (Id, V); end Set_Body_Entity; @@ -4593,8 +4593,8 @@ package body Einfo is procedure Set_First_Private_Entity (Id : E; V : E) is begin - pragma Assert (Ekind_In (Id, E_Package, E_Generic_Package) - or else Ekind (Id) in Concurrent_Kind); + pra
Re: New mklog script
On 25/05/2020 20:41, Jason Merrill via Gcc-patches wrote:
> On Mon, May 25, 2020 at 5:23 AM Martin Liška wrote:
>>
>> On 5/22/20 11:01 PM, Jason Merrill wrote:
>>> On Thu, May 21, 2020 at 6:03 PM Jason Merrill wrote:
On Fri, May 15, 2020 at 11:39 AM Martin Liška wrote:
>
> On 5/15/20 3:22 PM, Marek Polacek wrote:
>> On Fri, May 15, 2020 at 03:12:27PM +0200, Martin Liška wrote:
>>> On 5/15/20 2:42 PM, Marek Polacek wrote:
I actually use mklog -i all the time. But I can work around it if it
disappears.
>>>
>>> Ah, I can see a consumer.
>>> There's an updated version that supports that.
>>>
>>> For the future, will you still use the option? Wouldn't be better
>>> to put the ChangeLog content directly to commit message? Note
>>> that you won't have to copy the entries to a particular ChangeLog file.
>>
>> The way I do it is to generate a patch using format-patch, use mklog -i
>> on it, then add the ChangeLog entry to the commit message via commit
>> --amend.
>
> Hmm, you can do much better with:
>
> $ git diff | ./contrib/mklog > changelog && git commit -a -t changelog
>
> Or for an already created commit you can do:
>
> $ git diff HEAD~ | ./contrib/mklog > changelog && git commit -a --amend
> -e -F changelog
With these git aliases:
mklog-editor = "!f() { git show | git gcc-mklog >> $1; }; f"
addlog = "!f() { GIT_EDITOR='git mklog-editor' git commit
--amend; }; f"
I can 'git addlog' to append the output of mklog to the current
commit. Probably better would be to do something with
prepare-commit-msg.
>>>
>>> This is pretty rudimentary, but good enough as a start:
>>
>> I like the idea of usage of the prepare commit hook.
>>
>>>
>>> #!/bin/sh
>>>
>>> #COMMIT_MSG_FILE=$1
>>> #COMMIT_SOURCE=$2
>>> #SHA1=$3
>>
>> It's better to use the named arguments.
>>
>>>
>>> if ! [ -f "$1" ]; then exit 0; fi
>>>
>>> #echo "# $0 $1 $2 $3" >> $1
>>>
>>> if fgrep 'ChangeLog:' $1 > /dev/null 2>&1; then exit 0; fi
>>>
>>> if [ -z "$2" ]; then
>>> cmd="diff --cached"
>>> elif [ $2 == commit ]; then
>>> cmd="show $3"
>>> else
>>> exit 0
>>> fi
>>>
>>> git $cmd | git gcc-mklog >> $1
>>>
>>
>> Well, that will generate changelog entry for each commit.
>> For a user branch development, it's not desirable.
>
> It isn't that useful for intermediate commits, but I was thinking it
> wasn't harmful either. But I can remove the on-by-default aspects.
>
>> What about more explicit approach:
>>
>> 1) making an alias for: git diff | git gcc-mklog > commit.msg
>> 2) hook:
>>
>> if test -f commit.msg; then
>>cat commit.msg >> "$COMMIT_MSG_FILE"
>>rm commit.msg
>> fi
>>
>> So the changelog is created explicitly and included implicitly.
>
> How about this?
>
> +git config alias.commit-mklog '!f() { GCC_FORCE_MKLOG=1 git commit
"$@"; }; f'
> +
I thought we had a convention that aliases we added were prefixed with
'gcc-'? This seems to go against that.
R.
Re: [IMPORTANT] ChangeLog related changes
Am 26.05.20 um 11:04 schrieb Thomas Koenig via Gcc: Am 26.05.20 um 00:48 schrieb Jakub Jelinek via Gcc: I've turned the strict mode of Martin Liška's hook changes, This means that it is no longer possible to do a git gcc-backport [CC'ing fortran to warn other people against currently trying backports] ... and now I've tried to revert the ChangeLog files manually, pulled again, tried to push again, and got remote: *** ChangeLog format failed: remote: ERR: ChangeLog, DATESTAMP, BASE-VER and DEV-PHASE updates should be done separately from normal commits remote: remote: Please see: https://gcc.gnu.org/codingconventions.html#ChangeLogs remote: remote: error: hook declined to update refs/heads/releases/gcc-10 To git+ssh://gcc.gnu.org/git/gcc.git ! [remote rejected] releases/gcc-10 -> releases/gcc-10 (hook declined) error: Fehler beim Versenden einiger Referenzen nach 'git+ssh://tkoe...@gcc.gnu.org/git/gcc.git' So, I am in the quite familiar situation of a somehow inconsistent state of git that I have no idea how to get out of. So, two questions: - How do I get my gcc-10 branch back into a consistent state? - How are backports supposed to be handled using the new scripts? Regards Thomas
Re: New mklog script
On 5/26/20 12:23 PM, Richard Earnshaw wrote: I thought we had a convention that aliases we added were prefixed with 'gcc-'? This seems to go against that. You are right, but this one is so handy ;) What name do you suggest? Martin
Re: New mklog script
On 26/05/2020 12:14, Martin Liška wrote: > On 5/26/20 12:23 PM, Richard Earnshaw wrote: >> I thought we had a convention that aliases we added were prefixed with >> 'gcc-'? This seems to go against that. > > You are right, but this one is so handy ;) > What name do you suggest? > > Martin gcc-ci? R.
Re: [IMPORTANT] ChangeLog related changes
On Tue, May 26, 2020 at 12:42:41PM +0200, Thomas Koenig wrote: > Am 26.05.20 um 11:04 schrieb Thomas Koenig via Gcc: > > Am 26.05.20 um 00:48 schrieb Jakub Jelinek via Gcc: > > > > > I've turned the strict mode of Martin Liška's hook changes, > > > > This means that it is no longer possible to do a git gcc-backport > > [CC'ing fortran to warn other people against currently trying > backports] > > ... and now I've tried to revert the ChangeLog files manually, > pulled again, tried to push again, and got > > remote: *** ChangeLog format failed: > remote: ERR: ChangeLog, DATESTAMP, BASE-VER and DEV-PHASE updates should be > done separately from normal commits > remote: > remote: Please see: https://gcc.gnu.org/codingconventions.html#ChangeLogs > remote: > remote: error: hook declined to update refs/heads/releases/gcc-10 > To git+ssh://gcc.gnu.org/git/gcc.git > ! [remote rejected] releases/gcc-10 -> releases/gcc-10 (hook > declined) > error: Fehler beim Versenden einiger Referenzen nach > 'git+ssh://tkoe...@gcc.gnu.org/git/gcc.git' > > So, I am in the quite familiar situation of a somehow inconsistent > state of git that I have no idea how to get out of. > > So, two questions: > > - How do I get my gcc-10 branch back into a consistent state? git reset --hard origin/releases/gcc-10 should do it (if you want to throw all your local changes). > - How are backports supposed to be handled using the new scripts? When cherry-picking or otherwise backporting a change which changed the ChangeLog files, one needs to remove the ChangeLog changes from that commit, e.g. git diff > /tmp/P for i in `lsdiff /tmp/P | grep ChangeLog`; do filterdiff -i $i /tmp/P; done | patch -p1 -R git commit -a --amend or git checkout HEAD^ -- `git diff | lsdiff | sed -n -e 's,^[ab]/\(.*/ChangeLog\)$,\1,p'` git commit -a --amend could do that. If it is cherry-pick of an even older commit that doesn't have the commit message with properly formatted ChangeLog entry the scripts will understand, one needs to change the commit message too. Note, this obstackle will go away once you start backporting patches committed today or later, as those will not have the ChangeLog changes and will have properly formatted commit message. Jakub
Re: [IMPORTANT] ChangeLog related changes
On 26/05/2020 12:19, Jakub Jelinek via Gcc wrote: > On Tue, May 26, 2020 at 12:42:41PM +0200, Thomas Koenig wrote: >> Am 26.05.20 um 11:04 schrieb Thomas Koenig via Gcc: >>> Am 26.05.20 um 00:48 schrieb Jakub Jelinek via Gcc: >>> I've turned the strict mode of Martin Liška's hook changes, >>> >>> This means that it is no longer possible to do a git gcc-backport >> >> [CC'ing fortran to warn other people against currently trying >> backports] >> >> ... and now I've tried to revert the ChangeLog files manually, >> pulled again, tried to push again, and got >> >> remote: *** ChangeLog format failed: >> remote: ERR: ChangeLog, DATESTAMP, BASE-VER and DEV-PHASE updates should be >> done separately from normal commits >> remote: >> remote: Please see: https://gcc.gnu.org/codingconventions.html#ChangeLogs >> remote: >> remote: error: hook declined to update refs/heads/releases/gcc-10 >> To git+ssh://gcc.gnu.org/git/gcc.git >> ! [remote rejected] releases/gcc-10 -> releases/gcc-10 (hook >> declined) >> error: Fehler beim Versenden einiger Referenzen nach >> 'git+ssh://tkoe...@gcc.gnu.org/git/gcc.git' >> >> So, I am in the quite familiar situation of a somehow inconsistent >> state of git that I have no idea how to get out of. >> >> So, two questions: >> >> - How do I get my gcc-10 branch back into a consistent state? > > git reset --hard origin/releases/gcc-10 > should do it (if you want to throw all your local changes). > >> - How are backports supposed to be handled using the new scripts? > > When cherry-picking or otherwise backporting a change which changed the > ChangeLog files, one needs to remove the ChangeLog changes from that commit, > e.g. > git diff > /tmp/P > for i in `lsdiff /tmp/P | grep ChangeLog`; do filterdiff -i $i /tmp/P; done | > patch -p1 -R > git commit -a --amend > or > git checkout HEAD^ -- `git diff | lsdiff | sed -n -e > 's,^[ab]/\(.*/ChangeLog\)$,\1,p'` > git commit -a --amend > could do that. If it is cherry-pick of an even older commit that doesn't > have the > commit message with properly formatted ChangeLog entry the scripts will > understand, one needs to change the commit message too. > > Note, this obstackle will go away once you start backporting patches > committed today or later, as those will not have the ChangeLog changes and > will have properly formatted commit message. > > Jakub > I haven't investigated in detail, but could we use a merge strategy with the cherry-pick to drop ChangeLog entries? R.
Re: [IMPORTANT] ChangeLog related changes
On Tue, May 26, 2020 at 12:27:59PM +0100, Richard Earnshaw wrote: > I haven't investigated in detail, but could we use a merge strategy with > the cherry-pick to drop ChangeLog entries? If that works, sure. Note, when cherry-picking commits from before conversion to git or whenever people started to write usable ChangeLog entries in the commit messages, one will also need to reconstruct the commit message additions from the ChangeLog files. Jakub
Re: Automatically generated ChangeLog files - script
On 5/26/20 12:15 PM, Pierre-Marie de Rodat wrote: Hello Martin, First, thank you for your work on this new ChangeLog workflow. :-) Hello. Thank you. I’d like to report a “regression”: I can’t push the attached patch: remote: *** ChangeLog format failed: remote: ERR: changed file not mentioned in a ChangeLog:"gcc/ada/sem_ch4.adb" remote: ERR: changed file not mentioned in a ChangeLog:"gcc/ada/sem_ch7.adb" remote: ERR: changed file not mentioned in a ChangeLog:"gcc/ada/sem_ch8.adb" remote: ERR: changed file not mentioned in a ChangeLog:"gcc/ada/sem_elab.adb" remote: ERR: changed file not mentioned in a ChangeLog:"gcc/ada/sem_type.adb" remote: ERR: changed file not mentioned in a ChangeLog:"gcc/ada/sem_util.adb" remote: remote: Please see: https://gcc.gnu.org/codingconventions.html#ChangeLogs remote: remote: error: hook declined to update refs/heads/master It looks like the hook does not accept multi-line ChangeLog entries affecting multiple files: * contracts.adb, einfo.adb, exp_ch9.adb, sem_ch12.adb, sem_ch4.adb, sem_ch7.adb, sem_ch8.adb, sem_elab.adb, sem_type.adb, sem_util.adb: Reuse Is_Package_Or_Generic_Package where possible (similarly, reuse Is_Concurrent_Type if it was possible in the same expressions). Would it be possible to enhance the hook to support that? It's not supported right now and it will make the filename parsing much more complicated. I would recommend using ./contrib/mklog and using: * a.adb: Foo bar. * b.adb: Likewise. ... Thanks, Martin Thanks!
Re: Automatically generated ChangeLog files - script
Hi Martin, >> It looks like the hook does not accept multi-line ChangeLog entries >> affecting multiple files: >>> * contracts.adb, einfo.adb, exp_ch9.adb, sem_ch12.adb, >>> sem_ch4.adb, sem_ch7.adb, sem_ch8.adb, sem_elab.adb, >>> sem_type.adb, sem_util.adb: Reuse Is_Package_Or_Generic_Package >>> where possible (similarly, reuse Is_Concurrent_Type if it was >>> possible in the same expressions). >> >> Would it be possible to enhance the hook to support that? > > It's not supported right now and it will make the filename parsing much > more complicated. however, that's a format Emacs' ChangeLog mode uses and supports, and it's way less chatty than the one-file-per-line one, both for writers and readers. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [IMPORTANT] ChangeLog related changes
On 5/26/20 1:34 PM, Jakub Jelinek via Gcc wrote:
On Tue, May 26, 2020 at 12:27:59PM +0100, Richard Earnshaw wrote:
I haven't investigated in detail, but could we use a merge strategy with
the cherry-pick to drop ChangeLog entries?
If that works, sure.
Note, when cherry-picking commits from before conversion to git or whenever
people started to write usable ChangeLog entries in the commit messages,
one will also need to reconstruct the commit message additions from the
ChangeLog files.
Jakub
Hi.
There's a script candidate that does git cherry-pick and drops
and ChangeLog changes from both index and conflicting files.
Thoughts?
Martin
#!/usr/bin/env python3
# Copyright (C) 2020 Free Software Foundation, Inc.
#
# This file is part of GCC.
#
# GCC is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3, or (at your option)
# any later version.
#
# GCC is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with GCC; see the file COPYING. If not, write to
# the Free Software Foundation, 51 Franklin Street, Fifth Floor,
# Boston, MA 02110-1301, USA.
import argparse
import subprocess
if __name__ == '__main__':
parser = argparse.ArgumentParser(description='Backport a git revision and '
'stash all ChangeLog files.')
parser.add_argument('revision', help='Revision')
args = parser.parse_args()
r = subprocess.run('git cherry-pick -x %s' % args.revision, shell=True)
if r.returncode == 0:
subprocess.check_output('git show --name-only --pretty="" | '
'grep ChangeLog | '
'xargs git checkout HEAD~', shell=True)
subprocess.check_output('git commit --amend --no-edit', shell=True)
else:
# 1) remove all ChangeLog files from conflicts
out = subprocess.check_output('git diff --name-only --diff-filter=U',
shell=True,
encoding='utf8')
conflicts = out.strip().split('\n')
changelogs = [c for c in conflicts if c.endswith('ChangeLog')]
if changelogs:
cmd = 'git checkout --theirs %s' % '\n'.join(changelogs)
subprocess.check_output(cmd, shell=True)
# 2) remove all ChangeLog files from index
out = subprocess.check_output('git diff --name-only --diff-filter=M HEAD',
shell=True,
encoding='utf8')
out = out.strip().split('\n')
modified = [c for c in out if c.endswith('ChangeLog')]
for m in modified:
subprocess.check_output('git reset %s' % m, shell=True)
subprocess.check_output('git checkout %s' % m, shell=True)
# try to continue
if len(conflicts) == len(changelogs):
subprocess.check_output('git cherry-pick --continue', shell=True)
else:
print('Please resolve all remaining file conflicts.')
Re: Automatically generated ChangeLog files - script
On 5/26/20 2:35 PM, Rainer Orth wrote: Hi Martin, It looks like the hook does not accept multi-line ChangeLog entries affecting multiple files: * contracts.adb, einfo.adb, exp_ch9.adb, sem_ch12.adb, sem_ch4.adb, sem_ch7.adb, sem_ch8.adb, sem_elab.adb, sem_type.adb, sem_util.adb: Reuse Is_Package_Or_Generic_Package where possible (similarly, reuse Is_Concurrent_Type if it was possible in the same expressions). Would it be possible to enhance the hook to support that? It's not supported right now and it will make the filename parsing much more complicated. however, that's a format Emacs' ChangeLog mode uses and supports, and it's way less chatty than the one-file-per-line one, both for writers and readers. I see, but as mentioned it makes the parsing of the list files much more complicated. Feel free to provide a patch that will support multi-line entries. Martin Rainer
Re: New mklog script
On 5/26/20 1:18 PM, Richard Earnshaw wrote: On 26/05/2020 12:14, Martin Liška wrote: On 5/26/20 12:23 PM, Richard Earnshaw wrote: I thought we had a convention that aliases we added were prefixed with 'gcc-'? This seems to go against that. You are right, but this one is so handy ;) What name do you suggest? Martin gcc-ci? What the abbreviation stands for? Martin R.
Re: New mklog script
On 26/05/2020 14:09, Martin Liška wrote: > On 5/26/20 1:18 PM, Richard Earnshaw wrote: >> On 26/05/2020 12:14, Martin Liška wrote: >>> On 5/26/20 12:23 PM, Richard Earnshaw wrote: I thought we had a convention that aliases we added were prefixed with 'gcc-'? This seems to go against that. >>> >>> You are right, but this one is so handy ;) >>> What name do you suggest? >>> >>> Martin >> >> gcc-ci? > > What the abbreviation stands for? > > Martin > >> >> R. >> > CheckIn For those who come from the SVN days where ci was the standard abbreviation for committing :-) R.
Re: [IMPORTANT] ChangeLog related changes
On Mai 26 2020, Martin Liška wrote:
> subprocess.check_output('git show --name-only --pretty="" | '
> 'grep ChangeLog | '
git show --name-only --pretty= -- '*ChangeLog*'
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: New mklog script
On 5/26/20 3:11 PM, Richard Earnshaw wrote: On 26/05/2020 14:09, Martin Liška wrote: On 5/26/20 1:18 PM, Richard Earnshaw wrote: On 26/05/2020 12:14, Martin Liška wrote: On 5/26/20 12:23 PM, Richard Earnshaw wrote: I thought we had a convention that aliases we added were prefixed with 'gcc-'? This seems to go against that. You are right, but this one is so handy ;) What name do you suggest? Martin gcc-ci? What the abbreviation stands for? Martin R. CheckIn For those who come from the SVN days where ci was the standard abbreviation for committing :-) Ah, I see. Anyway, I prefer the original name even though it violates the naming policy. Let other express their preferences (Jason?). Martin R.
Re: New mklog script
On Tue, May 26, 2020 at 03:14:54PM +0200, Martin Liška wrote: > > > > gcc-ci? > > > > > > What the abbreviation stands for? > > > > > > Martin > > > > > > > > > > > R. > > > > > > > > > > > CheckIn > > > > For those who come from the SVN days where ci was the standard > > abbreviation for committing :-) > > Ah, I see. Anyway, I prefer the original name even though it violates > the naming policy. > > Let other express their preferences (Jason?). gcc-ci looks nice to me. Jakub
Re: [IMPORTANT] ChangeLog related changes
On 5/26/20 3:14 PM, Andreas Schwab wrote:
-- '*ChangeLog*'
Thank you for the comment.
There's a proper patch for 'git gcc-backport' alias.
Thoughts?
Martin
>From a1511dd6ccda73befe3282c43671a6c4623d5d7d Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Tue, 26 May 2020 15:32:32 +0200
Subject: [PATCH] Add new git-backport.py script.
contrib/ChangeLog:
* gcc-git-customization.sh: Use git-backport.py to drop
all changes for ChangeLog files.
* git-backport.py: New file.
---
contrib/gcc-git-customization.sh | 2 +-
contrib/git-backport.py | 60
2 files changed, 61 insertions(+), 1 deletion(-)
create mode 100755 contrib/git-backport.py
diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index dcc42683fa6..6df881ac955 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -26,7 +26,7 @@ git config alias.gcc-descr \!"f() { if test \${1:-no} = --full; then c=\${2:-mas
git config alias.gcc-undescr \!"f() { o=\$(git config --get gcc-config.upstream); r=\$(echo \$1 | sed -n 's,^r\\([0-9]\\+\\)-[0-9]\\+\$,\\1,p'); n=\$(echo \$1 | sed -n 's,^r[0-9]\\+-\\([0-9]\\+\\)\$,\\1,p'); test -z \$r && echo Invalid id \$1 && exit 1; h=\$(git rev-parse --verify --quiet \${o:-origin}/releases/gcc-\$r); test -z \$h && h=\$(git rev-parse --verify --quiet \${o:-origin}/master); p=\$(git describe --all --match 'basepoints/gcc-'\$r \$h | sed -n 's,^\\(tags/\\)\\?basepoints/gcc-[0-9]\\+-\\([0-9]\\+\\)-g[0-9a-f]*\$,\\2,p;s,^\\(tags/\\)\\?basepoints/gcc-[0-9]\\+\$,0,p'); git rev-parse --verify \$h~\$(expr \$p - \$n); }; f"
git config alias.gcc-verify '!f() { "`git rev-parse --show-toplevel`/contrib/gcc-changelog/git_check_commit.py" $@; } ; f'
-git config alias.gcc-backport '!f() { rev=$1; git cherry-pick -x $@; } ; f'
+git config alias.gcc-backport '!f() { "`git rev-parse --show-toplevel`/contrib/git-backport.py" $@; } ; f'
git config alias.gcc-mklog '!f() { "`git rev-parse --show-toplevel`/contrib/mklog.py" $@; } ; f'
diff --git a/contrib/git-backport.py b/contrib/git-backport.py
new file mode 100755
index 000..6a115c34d40
--- /dev/null
+++ b/contrib/git-backport.py
@@ -0,0 +1,60 @@
+#!/usr/bin/env python3
+
+# Copyright (C) 2020 Free Software Foundation, Inc.
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+#
+# GCC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING. If not, write to
+# the Free Software Foundation, 51 Franklin Street, Fifth Floor,
+# Boston, MA 02110-1301, USA.
+
+import argparse
+import subprocess
+
+if __name__ == '__main__':
+parser = argparse.ArgumentParser(description='Backport a git revision and '
+ 'stash all ChangeLog files.')
+parser.add_argument('revision', help='Revision')
+args = parser.parse_args()
+
+r = subprocess.run('git cherry-pick -x %s' % args.revision, shell=True)
+if r.returncode == 0:
+cmd = 'git show --name-only --pretty="" -- "*ChangeLog" |' \
+ 'xargs git checkout HEAD~'
+subprocess.check_output(cmd, shell=True)
+subprocess.check_output('git commit --amend --no-edit', shell=True)
+else:
+# 1) remove all ChangeLog files from conflicts
+out = subprocess.check_output('git diff --name-only --diff-filter=U',
+ shell=True,
+ encoding='utf8')
+conflicts = out.strip().split('\n')
+changelogs = [c for c in conflicts if c.endswith('ChangeLog')]
+if changelogs:
+cmd = 'git checkout --theirs %s' % '\n'.join(changelogs)
+subprocess.check_output(cmd, shell=True)
+# 2) remove all ChangeLog files from index
+cmd = 'git diff --name-only --diff-filter=M HEAD'
+out = subprocess.check_output(cmd, shell=True, encoding='utf8')
+out = out.strip().split('\n')
+modified = [c for c in out if c.endswith('ChangeLog')]
+for m in modified:
+subprocess.check_output('git reset %s' % m, shell=True)
+subprocess.check_output('git checkout %s' % m, shell=True)
+
+# try to continue
+if len(conflicts) == len(changelogs):
+subprocess.check_output('git cherry-pick --continue', shell=True)
+else:
+print('Please resolve all remaining file conflicts.')
--
2.26.2
Re: Automatically generated ChangeLog files - script
On 26/05/2020 15:09, Martin Liška wrote: I see, but as mentioned it makes the parsing of the list files much more complicated. Feel free to provide a patch that will support multi-line entries. Thanks! As long as there is no objection to support this, I have no problem giving it a try. :-) I just sent two patches on gcc-patches@. By the way, is there a delay between the time the gcc-changelog scripts are updated and the time they are used in pre-commit hooks? -- Pierre-Marie de Rodat
[PATCH 0/5] some vxworks patches
Hi Olivier et al I'm having quite a bit of trouble getting gcc 10 to build for our vxworks 5 (5.5.1) target. The first thing I hit is #if !defined(_WRS_VXWORKS_MAJOR) #error "VxWorks version macros needed but not defined" #endif Our version.h doesn't define that macro (however, there's a _WRS_VXWORKS_5_X defined in vxWorks.h). Amusingly, a few of the system headers do mention _WRS_VXWORKS_MAJOR, e.g. getOptLib.h:#include "vxWorks.h" /* for _WRS_VXWORKS_MAJOR, if defined. */ and everywhere in the headers that use that macro, they are careful to do "#if defined (_WRS_VXWORKS_MAJOR) && (_WRS_VXWORKS_MAJOR >= 6)". For now, I've just monkey-patched _vxworks-versions.h to get the build past that - I suppose what I should do is to patch our version.h system header instead to provide those two macros. But most of the gthread stuff simply doesn't build against our headers. These five patches, and a bogus definition of WIND_USR environment variable (-mrtp doesn't make sense for us, but vx_crtbegin-rtp.o still gets built and that fails if WIND_USR doesn't exist) get the build a little further - I then fail to build libstdc++, but I'd like some feedback on whether vxworks 5 is even supposed to be (still) supported before digging further. Rasmus Villemoes (5): libgcc: vxwors: stub out VX_ENTER_TLS_DTOR for vxworks 5 gthr-vxworks.h: fix leftover _VXW_PRE_69 gthr-vxworks.c: add include of taskLib.h libgcc: vxworks: don't set __GTHREAD_HAS_COND for vxworks 5.x libgcc: vxworks: don't set __GTHREAD_CXX0X for vxworks 5.x libgcc/config/gthr-vxworks-cond.c | 4 libgcc/config/gthr-vxworks-thread.c | 4 libgcc/config/gthr-vxworks-tls.c| 5 + libgcc/config/gthr-vxworks.c| 1 + libgcc/config/gthr-vxworks.h| 10 +++--- 5 files changed, 21 insertions(+), 3 deletions(-) -- 2.23.0
[PATCH 3/5] gthr-vxworks.c: add include of taskLib.h
Fix gcc-src/libgcc/config/gthr-vxworks.c:65:7: warning: implicit declaration of function 'taskDelay'; did you mean 'sysDelay'? [-Wimplicit-function-declaration] 65 | taskDelay (1); --- libgcc/config/gthr-vxworks.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libgcc/config/gthr-vxworks.c b/libgcc/config/gthr-vxworks.c index 9b47ec8e9e9..4e73108d907 100644 --- a/libgcc/config/gthr-vxworks.c +++ b/libgcc/config/gthr-vxworks.c @@ -33,6 +33,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see #if defined(__GTHREADS) #include +#include #ifndef __RTP__ # include -- 2.23.0
[PATCH 4/5] libgcc: vxworks: don't set __GTHREAD_HAS_COND for vxworks 5.x
The vxworks-cond.c file fails to compile for vxworks 5.x:
libgcc/config/gthr-vxworks-cond.c:29:
./gthr-default.h:274:3: error: unknown type name 'TASK_ID'
274 | TASK_ID task_id;
| ^~~
There is a TASK_ID typedef in our system headers, but (1) is is
commented out, (2) lives in some obscure header that nothing really
pulls in and (3) it is defined as a "struct wind_task *", which isn't
really consistent with taskCreate() returning an int.
In order to allow building gcc, let's just disable __GTHREAD_HAS_COND
for vxworks 5.x. To simplify the makefile fragments, keep including
gthr-vxworks-cond.c, but guard the actual code by __GTHREAD_HAS_COND -
that way, the logic for deciding whether to support gthread condition
variables is kept in gthr-vxworks.h.
---
libgcc/config/gthr-vxworks-cond.c | 4
libgcc/config/gthr-vxworks.h | 4
2 files changed, 8 insertions(+)
diff --git a/libgcc/config/gthr-vxworks-cond.c
b/libgcc/config/gthr-vxworks-cond.c
index d65d07aebc3..f0585624c05 100644
--- a/libgcc/config/gthr-vxworks-cond.c
+++ b/libgcc/config/gthr-vxworks-cond.c
@@ -31,6 +31,8 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If
not, see
/* --- Condition Variables */
+#if __GTHREAD_HAS_COND
+
void
__gthread_cond_init (__gthread_cond_t *cond)
{
@@ -81,3 +83,5 @@ __gthread_cond_wait_recursive (__gthread_cond_t *cond,
{
return __gthread_cond_wait (cond, mutex);
}
+
+#endif
diff --git a/libgcc/config/gthr-vxworks.h b/libgcc/config/gthr-vxworks.h
index e38174730bf..91e3d94ac67 100644
--- a/libgcc/config/gthr-vxworks.h
+++ b/libgcc/config/gthr-vxworks.h
@@ -234,6 +234,8 @@ extern int __gthread_setspecific (__gthread_key_t __key,
void *__ptr);
/* -- Base condition variables support --- */
+#if _VXWORKS_MAJOR_GE(6)
+
#define __GTHREAD_HAS_COND 1
typedef SEM_ID __gthread_cond_t;
@@ -254,6 +256,8 @@ extern int __gthread_cond_wait (__gthread_cond_t *cond,
extern int __gthread_cond_wait_recursive (__gthread_cond_t *cond,
__gthread_recursive_mutex_t *mutex);
+#endif /* _VXWORKS_MAJOR_GE(6) */
+
/* --- C++0x thread support - */
/* We do not support C++0x threads on that VxWorks 653, which we can
--
2.23.0
[PATCH 1/5] libgcc: vxwors: stub out VX_ENTER_TLS_DTOR for vxworks 5
Commit 806dd0472f56 (Improve the thread support for VxWorks) introduced calls of (on vxworks 5 at least) non-existing __gthread_enter_tls_dtor_context/__gthread_leave_tls_dtor_context ; the code used to call __gthread_enter_tsd_dtor_context/__gthread_leave_tsd_dtor_context. Those are simply no-ops (we simply use the definitions which are provided in contrib/gthr_supp_vxw_5x.c), so we can fix this by nop'ing out VX_ENTER_TLS_DTOR/VX_LEAVE_TLS_DTOR for vxworks 5.x. --- libgcc/config/gthr-vxworks-tls.c | 5 + 1 file changed, 5 insertions(+) diff --git a/libgcc/config/gthr-vxworks-tls.c b/libgcc/config/gthr-vxworks-tls.c index fac25e305a0..726304166fc 100644 --- a/libgcc/config/gthr-vxworks-tls.c +++ b/libgcc/config/gthr-vxworks-tls.c @@ -117,8 +117,13 @@ extern void __gthread_leave_tls_dtor_context (void); #define VX_GET_TLS_DATA() __gthread_get_tls_data() #define VX_SET_TLS_DATA(x) __gthread_set_tls_data(x) +#ifdef _VXWORKS_MAJOR_EQ(5) +#define VX_ENTER_TLS_DTOR() +#define VX_LEAVE_TLS_DTOR() +#else #define VX_ENTER_TLS_DTOR() __gthread_enter_tls_dtor_context () #define VX_LEAVE_TLS_DTOR() __gthread_leave_tls_dtor_context () +#endif #endif -- 2.23.0
[PATCH 2/5] gthr-vxworks.h: fix leftover _VXW_PRE_69
_VXW_PRE_69 was introduced in 806dd0472f, then replaced by _VXWORKS_PRE(6,9) in abb6c3eecf, but this one was missed. Fixes: abb6c3eecf (Introduce an internal API for VxWorks version checks) --- libgcc/config/gthr-vxworks.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libgcc/config/gthr-vxworks.h b/libgcc/config/gthr-vxworks.h index 8b55fc55407..e38174730bf 100644 --- a/libgcc/config/gthr-vxworks.h +++ b/libgcc/config/gthr-vxworks.h @@ -286,7 +286,7 @@ typedef struct typedef __gthread_tcb *__gthread_t; /* Typedefs specific to different vxworks versions. */ -#if _VXW_PRE_69 +#if _VXWORKS_PRE(6,9) typedef int _Vx_usr_arg_t; #define TASK_ID_NULL ((TASK_ID)NULL) #define SEM_ID_NULL ((SEM_ID)NULL) -- 2.23.0
[PATCH 5/5] libgcc: vxworks: don't set __GTHREAD_CXX0X for vxworks 5.x
gthr-vxworks-thread.c fails to compile for vxworks 5.x: libgcc/config/gthr-vxworks-thread.c:268:14: error: 'VX_USR_TASK_OPTIONS' undeclared (first use in this function) 268 | options &= VX_USR_TASK_OPTIONS; | ^~~ libgcc/config/gthr-vxworks-thread.c:282:3: error: unknown type name 'TASK_ID' 282 | TASK_ID task_id = taskCreate (NULL, | ^~~ As for __GTHREAD_HAS_COND, use __GTHREAD_CXX0X to guard the actual contents of gthr-vxworks-thread.c. That should also allow dropping the t-gthr-vxworksae fragment and simply use t-gthr-vxworks. --- libgcc/config/gthr-vxworks-thread.c | 4 libgcc/config/gthr-vxworks.h| 4 ++-- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/libgcc/config/gthr-vxworks-thread.c b/libgcc/config/gthr-vxworks-thread.c index 8544b03dd18..183198577eb 100644 --- a/libgcc/config/gthr-vxworks-thread.c +++ b/libgcc/config/gthr-vxworks-thread.c @@ -30,6 +30,8 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see #include "gthr.h" #include +#if __GTHREAD_CXX0X + #define __TIMESPEC_TO_NSEC(timespec) \ ((long long)timespec.tv_sec * 10 + (long long)timespec.tv_nsec) @@ -347,3 +349,5 @@ __gthread_detach (__gthread_t __threadid) return OK; } + +#endif diff --git a/libgcc/config/gthr-vxworks.h b/libgcc/config/gthr-vxworks.h index 91e3d94ac67..14e7d54b022 100644 --- a/libgcc/config/gthr-vxworks.h +++ b/libgcc/config/gthr-vxworks.h @@ -263,7 +263,7 @@ extern int __gthread_cond_wait_recursive (__gthread_cond_t *cond, /* We do not support C++0x threads on that VxWorks 653, which we can recognize by VTHREADS being defined. */ -#ifndef VTHREADS +#if _VXWORKS_MAJOR_GE(6) && !defined(VTHREADS) #define __GTHREADS_CXX0X 1 @@ -326,7 +326,7 @@ extern int __gthread_detach (__gthread_t thread); extern __gthread_t __gthread_self (void); -#endif +#endif /* _VXWORKS_MAJOR_GE(6) && !defined(VTHREADS) */ #ifdef __cplusplus } -- 2.23.0
Re: Automatically generated ChangeLog files - script
On 5/26/20 4:50 PM, Pierre-Marie de Rodat wrote: On 26/05/2020 15:09, Martin Liška wrote: I see, but as mentioned it makes the parsing of the list files much more complicated. Feel free to provide a patch that will support multi-line entries. Thanks! As long as there is no objection to support this, I have no problem giving it a try. :-) I just sent two patches on gcc-patches@. By the way, is there a delay between the time the gcc-changelog scripts are updated and the time they are used in pre-commit hooks? The script needs to be synced by somebody to the server. I asked Jakub to do it for me. Martin
Re: New mklog script
On 5/26/20 7:14 AM, Martin Liška wrote: On 5/26/20 3:11 PM, Richard Earnshaw wrote: On 26/05/2020 14:09, Martin Liška wrote: On 5/26/20 1:18 PM, Richard Earnshaw wrote: On 26/05/2020 12:14, Martin Liška wrote: On 5/26/20 12:23 PM, Richard Earnshaw wrote: I thought we had a convention that aliases we added were prefixed with 'gcc-'? This seems to go against that. You are right, but this one is so handy ;) What name do you suggest? Martin gcc-ci? What the abbreviation stands for? Martin R. CheckIn For those who come from the SVN days where ci was the standard abbreviation for committing :-) Ah, I see. Anyway, I prefer the original name even though it violates the naming policy. Let other express their preferences (Jason?). Personally I struggle to keep track of all the different command and function names (e.g., in GCC) and what they do. I find consistent names and behaviors helpful (and conversely, inconsistencies trip me up time and time again). So if/since there is a convention to prefix gcc Git commands with gcc- I would prefer to use it consistently, even if shorter names might seem nicer or more convenient. We don't check things in so often that typing a few extra characters should be a burden. By the way, it's nice that the existing gcc- aliases are documented on https://gcc.gnu.org/gitwrite.html. I would suggest to add this one there as well. Martin
Re: [arm] GCC validation: preferred way of running the testsuite?
On Tue, 19 May 2020 at 13:28, Richard Earnshaw
wrote:
>
> On 11/05/2020 17:43, Christophe Lyon via Gcc wrote:
> > Hi,
> >
> >
> > As you may know, I've been running validations of GCC trunk in many
> > configurations for Arm and Aarch64.
> >
> >
> > I was recently trying to make some cleanup in the new Bfloat16, MVE, CDE,
> > and
> > ACLE tests because in several configurations I see 300-400 FAILs
> > mainly in these areas, because of “testisms”. The goal is to avoid
> > wasting time over the same failure reports when checking what needs
> > fixing. I thought this would be quick & easy, but this is tedious
> > because of the numerous combinations of options and configurations
> > available on Arm.
> >
> >
> > Sorry for the very long email, it’s hard to describe and summarize,
> > but I'd like to try nonetheless, hoping that we can make testing
> > easier/more efficient :-), because most of the time the problems I
> > found are with the tests rather than real compiler bugs, so I think
> > it's a bit of wasted time.
> >
> >
> > Here is a list of problems, starting with the tricky dependencies
> > around -mfloat-abi=XXX:
> >
> > * Some targets do not support multilibs (eg arm-linux-gnueabi[hf] with
> > glibc), or one can decide not to build with both hard and soft FP
> > multilibs. This generally becomes a problem when including stdint.h
> > (used by arm_neon.h, arm_acle.h, …), leading to a compiler error for
> > lack of gnu/stub*.h for the missing float-abi. If you add -mthumb to
> > the picture, it becomes quite complex (eg -mfloat-abi=hard is not
> > supported on thumb-1).
> >
> >
> > Consider mytest.c that does not depend on any include file and has:
> > /* { dg-options "-mfloat-abi=hard" } */
> >
> > If GCC is configured for arm-linux-gnueabi --with-cpu=cortex-a9
> > --with-fpu=neon,
> > with ‘make check’, the test PASSes.
> > With ‘make check’ with --target-board=-march=armv5t/-mthumb, then the
> > test FAILs:
> > sorry, unimplemented: Thumb-1 hard-float VFP ABI
> >
> >
> > If I add
> > /* { dg-require-effective-target arm_hard_ok } */
> > ‘make check’ with --target-board=-march=armv5t/-mthumb is now
> > UNSUPPORTED (which is OK), but
> > plain ‘make check’ is now also UNSUPPORTED because arm_hard_ok detects
> > that we lack the -mfloat-abi=hard multilib. So we lose a PASS.
> >
> > If I configure GCC for arm-linux-gnueabihf, then:
> > ‘make check’ PASSes
> > ‘make check’ with --target-board=-march=armv5t/-mthumb, FAILs
> > and with
> > /* { dg-require-effective-target arm_hard_ok } */
> > ‘make check’ with --target-board=-march=armv5t/-mthumb is now UNSUPPORTED
> > and
> > plain ‘make check’ PASSes
> >
> > So it seems the best option is to add
> > /* { dg-require-effective-target arm_hard_ok } */
> > although it makes the test UNSUPPORTED by arm-linux-gnueabi even in
> > cases where it could PASS.
> >
> > Is there consensus that this is the right way?
> >
> >
> >
> > * In GCC DejaGnu helpers, the queries for -mfloat-abi=hard and
> > -march=XXX are independent in general, meaning if you query for
> > -mfloat-abi=hard support, it will do that in the absence of any
> > -march=XXX that the testcase may also be using. So, if GCC is
> > configured with its default cpu/fpu, -mfloat-abi=hard will be rejected
> > for lack of an fpu on the default cpu, but if GCC is configured with a
> > suitable cpu/fpu pair, -mfloat-abi=hard will be accepted.
> >
> > I faced this problem when I tried to “fix” the order in which we try
> > options in
> > Arm_v8_2a_bf16_neon_ok. (see
> > https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544654.html)
> >
> > I faced similar problems while working on a patch of mine about a bug
> > with IRQ handlers which has different behaviour depending on the FP
> > ABI used: I have the feeling that I spend too much time writing the
> > tests to the detriment of the patch itself...
> >
> > I also noticed that Richard Sandiford probably faced similar issues
> > with his recent fix for "no_unique_address", where he finally added
> > arm_arch_v8a_hard_ok to check arm8v-a CPU + neon-fp-armv8 FPU +
> > float-abi=hard at the same time.
> >
> > Maybe we could decide on a consistent and simpler way of checking such
> > things?
> >
> >
> > * A metric for this complexity could be the number of arm
> > effective-targets, a quick and not-fully accurate grep | sed | sort |
> > uniq -c | sort -n on target-supports.exp ends with:
> > 9 mips
> > 16 aarch64
> > 21 powerpc
> > 97 vect
> > 106 arm
> > (does not count all the effective-targets generated by tcl code, eg
> > arm_arch_FUNC_ok)
> >
> > This probably explains why it’s hard to get test directives right :-)
> >
> > I’ve not thought about how we could reduce that number….
> >
> >
> >
> > * Finally, I’m wondering about the most appropriate way of configuring
> > GCC and running the tests.
> >
> > So far, for most of the configurations I'm testing, I use different
> > --with-cpu/--with-fpu/--with-mode configure flags for each
Re: [arm] GCC validation: preferred way of running the testsuite?
On 26/05/2020 18:04, Christophe Lyon via Gcc wrote:
> On Tue, 19 May 2020 at 13:28, Richard Earnshaw
> wrote:
>>
>> On 11/05/2020 17:43, Christophe Lyon via Gcc wrote:
>>> Hi,
>>>
>>>
>>> As you may know, I've been running validations of GCC trunk in many
>>> configurations for Arm and Aarch64.
>>>
>>>
>>> I was recently trying to make some cleanup in the new Bfloat16, MVE, CDE,
>>> and
>>> ACLE tests because in several configurations I see 300-400 FAILs
>>> mainly in these areas, because of “testisms”. The goal is to avoid
>>> wasting time over the same failure reports when checking what needs
>>> fixing. I thought this would be quick & easy, but this is tedious
>>> because of the numerous combinations of options and configurations
>>> available on Arm.
>>>
>>>
>>> Sorry for the very long email, it’s hard to describe and summarize,
>>> but I'd like to try nonetheless, hoping that we can make testing
>>> easier/more efficient :-), because most of the time the problems I
>>> found are with the tests rather than real compiler bugs, so I think
>>> it's a bit of wasted time.
>>>
>>>
>>> Here is a list of problems, starting with the tricky dependencies
>>> around -mfloat-abi=XXX:
>>>
>>> * Some targets do not support multilibs (eg arm-linux-gnueabi[hf] with
>>> glibc), or one can decide not to build with both hard and soft FP
>>> multilibs. This generally becomes a problem when including stdint.h
>>> (used by arm_neon.h, arm_acle.h, …), leading to a compiler error for
>>> lack of gnu/stub*.h for the missing float-abi. If you add -mthumb to
>>> the picture, it becomes quite complex (eg -mfloat-abi=hard is not
>>> supported on thumb-1).
>>>
>>>
>>> Consider mytest.c that does not depend on any include file and has:
>>> /* { dg-options "-mfloat-abi=hard" } */
>>>
>>> If GCC is configured for arm-linux-gnueabi --with-cpu=cortex-a9
>>> --with-fpu=neon,
>>> with ‘make check’, the test PASSes.
>>> With ‘make check’ with --target-board=-march=armv5t/-mthumb, then the
>>> test FAILs:
>>> sorry, unimplemented: Thumb-1 hard-float VFP ABI
>>>
>>>
>>> If I add
>>> /* { dg-require-effective-target arm_hard_ok } */
>>> ‘make check’ with --target-board=-march=armv5t/-mthumb is now
>>> UNSUPPORTED (which is OK), but
>>> plain ‘make check’ is now also UNSUPPORTED because arm_hard_ok detects
>>> that we lack the -mfloat-abi=hard multilib. So we lose a PASS.
>>>
>>> If I configure GCC for arm-linux-gnueabihf, then:
>>> ‘make check’ PASSes
>>> ‘make check’ with --target-board=-march=armv5t/-mthumb, FAILs
>>> and with
>>> /* { dg-require-effective-target arm_hard_ok } */
>>> ‘make check’ with --target-board=-march=armv5t/-mthumb is now UNSUPPORTED
>>> and
>>> plain ‘make check’ PASSes
>>>
>>> So it seems the best option is to add
>>> /* { dg-require-effective-target arm_hard_ok } */
>>> although it makes the test UNSUPPORTED by arm-linux-gnueabi even in
>>> cases where it could PASS.
>>>
>>> Is there consensus that this is the right way?
>>>
>>>
>>>
>>> * In GCC DejaGnu helpers, the queries for -mfloat-abi=hard and
>>> -march=XXX are independent in general, meaning if you query for
>>> -mfloat-abi=hard support, it will do that in the absence of any
>>> -march=XXX that the testcase may also be using. So, if GCC is
>>> configured with its default cpu/fpu, -mfloat-abi=hard will be rejected
>>> for lack of an fpu on the default cpu, but if GCC is configured with a
>>> suitable cpu/fpu pair, -mfloat-abi=hard will be accepted.
>>>
>>> I faced this problem when I tried to “fix” the order in which we try
>>> options in
>>> Arm_v8_2a_bf16_neon_ok. (see
>>> https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544654.html)
>>>
>>> I faced similar problems while working on a patch of mine about a bug
>>> with IRQ handlers which has different behaviour depending on the FP
>>> ABI used: I have the feeling that I spend too much time writing the
>>> tests to the detriment of the patch itself...
>>>
>>> I also noticed that Richard Sandiford probably faced similar issues
>>> with his recent fix for "no_unique_address", where he finally added
>>> arm_arch_v8a_hard_ok to check arm8v-a CPU + neon-fp-armv8 FPU +
>>> float-abi=hard at the same time.
>>>
>>> Maybe we could decide on a consistent and simpler way of checking such
>>> things?
>>>
>>>
>>> * A metric for this complexity could be the number of arm
>>> effective-targets, a quick and not-fully accurate grep | sed | sort |
>>> uniq -c | sort -n on target-supports.exp ends with:
>>> 9 mips
>>> 16 aarch64
>>> 21 powerpc
>>> 97 vect
>>> 106 arm
>>> (does not count all the effective-targets generated by tcl code, eg
>>> arm_arch_FUNC_ok)
>>>
>>> This probably explains why it’s hard to get test directives right :-)
>>>
>>> I’ve not thought about how we could reduce that number….
>>>
>>>
>>>
>>> * Finally, I’m wondering about the most appropriate way of configuring
>>> GCC and running the tests.
>>>
>>> So far, for most of the configurations I'm testing, I use different
>>>
Re: [IMPORTANT] ChangeLog related changes
Hi Jakub, On Tue, May 26, 2020 at 12:42:41PM +0200, Thomas Koenig wrote: So, two questions: - How do I get my gcc-10 branch back into a consistent state? That works, thanks. git reset --hard origin/releases/gcc-10 should do it (if you want to throw all your local changes). - How are backports supposed to be handled using the new scripts? When cherry-picking or otherwise backporting a change which changed the ChangeLog files, one needs to remove the ChangeLog changes from that commit, e.g. git diff > /tmp/P for i in `lsdiff /tmp/P | grep ChangeLog`; do filterdiff -i $i /tmp/P; done | patch -p1 -R git commit -a --amend I tried that, with the slight variation of doing "git diff HEAD~1 > /tmp/P" as the first command (and installing lsdiff), and it seems I have successfully pushed r10-8187-g3633bc27f5925394ccc5dd56bb1c65b4d88b42c0 . Thanks! Just to let other people know that this works :-) Regards Thomas
Re: New mklog script
On Tue, May 26, 2020 at 11:38 AM Martin Sebor wrote: > On 5/26/20 7:14 AM, Martin Liška wrote: > > On 5/26/20 3:11 PM, Richard Earnshaw wrote: > >> On 26/05/2020 14:09, Martin Liška wrote: > >>> On 5/26/20 1:18 PM, Richard Earnshaw wrote: > On 26/05/2020 12:14, Martin Liška wrote: > > On 5/26/20 12:23 PM, Richard Earnshaw wrote: > >> I thought we had a convention that aliases we added were prefixed > >> with 'gcc-'? This seems to go against that. > > > > You are right, but this one is so handy ;) > > What name do you suggest? > > gcc-ci? > >>> > >>> What the abbreviation stands for? > >> > >> CheckIn > >> > >> For those who come from the SVN days where ci was the standard > >> abbreviation for committing :-) > > > > Ah, I see. Anyway, I prefer the original name even though it violates > > the naming policy. > > > > Let other express their preferences (Jason?). > gcc-ci suggests that it should always be used for commits to gcc, which is not my intent; the new alias is only used when you want to ask for a new ChangeLog skeleton to be added. gcc-ci-log would be better if you want something short; I'd prefer gcc-commit-mklog, and let people define their own shorter aliases as desired. > Personally I struggle to keep track of all the different command > and function names (e.g., in GCC) and what they do. I find > consistent names and behaviors helpful (and conversely, > inconsistencies trip me up time and time again). So if/since there > is a convention to prefix gcc Git commands with gcc- I would prefer > to use it consistently, even if shorter names might seem nicer or > more convenient. We don't check things in so often that typing > a few extra characters should be a burden. > And people can always create their own aliases. > By the way, it's nice that the existing gcc- aliases are documented > on https://gcc.gnu.org/gitwrite.html. I would suggest to add this > one there as well. > Definitely. Jason
GCC Testsuite patches break AIX
Alexandre, Your testsuite patches have completely broken the testsuite on AIX. 1000's of testsuite failures because the testsuite is inserting unsupported options on AIX. Complaints about -dA, -dD, -dumpbase, etc. This patch was not properly tested on all targets. Please fix or revert this patch immediately. Thanks, David
Re: dejagnu version update?
I processed the patch backlog for DejaGnu, and have gone through the bug list. It'd be nice if somebody could try master with a more complex environment, etc... if I'm going to push out a release. For cross testing all I have is a PI and QEMU. - rob -
Re: dejagnu version update?
On Tue, 26 May 2020, Rob Savoye wrote: > I processed the patch backlog for DejaGnu, and have gone through the > bug list. It'd be nice if somebody could try master with a more complex > environment, etc... if I'm going to push out a release. For cross > testing all I have is a PI and QEMU. I'll run some RISC-V remote GCC/GDB testing and compare results for DejaGnu 1.6/1.6.1 vs trunk. It will take several days though, as it takes many hours to go through these testsuite runs. Maciej
Re: dejagnu version update?
On 5/26/20 7:20 PM, Maciej W. Rozycki wrote: > I'll run some RISC-V remote GCC/GDB testing and compare results for > DejaGnu 1.6/1.6.1 vs trunk. It will take several days though, as it takes > many hours to go through these testsuite runs. That'd be great. I'd rather push out a stable release, than have to fix bugs right after it gets released. - rob -
