Re: ChangeLog files - server and client scripts
On 5/23/20 12:14 AM, Ian Lance Taylor wrote:
Sure, I can wait. Thanks for looking at it.
Hello.
Thank you for patience. There's a patch that fixes that,
I'm going to install it.
Martin
>From 76e18b91250f265a37d85063860fb38aa8f6aac3 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Mon, 25 May 2020 09:40:50 +0200
Subject: [PATCH] Allow only ignored files in ChangeLog entries.
contrib/ChangeLog:
2020-05-25 Martin Liska
* gcc-changelog/git_commit.py: Add trailing '/'
for libdruntime. Allow empty changelog for
only ignored files.
* gcc-changelog/test_email.py: New test for go
patch in ignored location.
* gcc-changelog/test_patches.txt: Add test.
---
contrib/gcc-changelog/git_commit.py| 5 +--
contrib/gcc-changelog/test_email.py| 4 +++
contrib/gcc-changelog/test_patches.txt | 43 ++
3 files changed, 50 insertions(+), 2 deletions(-)
diff --git a/contrib/gcc-changelog/git_commit.py b/contrib/gcc-changelog/git_commit.py
index 8c5fa2c0fc9..2cfdbc83d09 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -130,7 +130,7 @@ ignored_prefixes = [
'gcc/go/gofrontend/',
'gcc/testsuite/go.test/test/',
'libgo/',
-'libphobos/libdruntime',
+'libphobos/libdruntime/',
'libphobos/src/',
'libsanitizer/',
]
@@ -233,7 +233,8 @@ class GitCommit:
project_files = [f for f in self.modified_files
if self.is_changelog_filename(f[0])
- or f[0] in misc_files]
+ or f[0] in misc_files
+ or self.in_ignored_location(f[0])]
if len(project_files) == len(self.modified_files):
# All modified files are only MISC files
return
diff --git a/contrib/gcc-changelog/test_email.py b/contrib/gcc-changelog/test_email.py
index d522e6ef7e3..aa516c6e6d1 100755
--- a/contrib/gcc-changelog/test_email.py
+++ b/contrib/gcc-changelog/test_email.py
@@ -276,3 +276,7 @@ class TestGccChangelog(unittest.TestCase):
def test_dr_entry(self):
email = self.from_patch_glob('0001-c-C-20-DR-2237.patch')
assert email.changelog_entries[0].prs == ['DR 2237']
+
+def test_changes_only_in_ignored_location(self):
+email = self.from_patch_glob('0001-go-in-ignored-location.patch')
+assert not email.errors
diff --git a/contrib/gcc-changelog/test_patches.txt b/contrib/gcc-changelog/test_patches.txt
index 3445c3d9f11..58fd81c85c9 100644
--- a/contrib/gcc-changelog/test_patches.txt
+++ b/contrib/gcc-changelog/test_patches.txt
@@ -2568,3 +2568,46 @@ index a6a5d975af3..a8082d39aca 100644
@@ -1 +1,2 @@
+
+
+=== 0001-go-in-ignored-location.patch ===
+From 81994eab700da7fea6644541c163aa0f0f3b8cf1 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Cl=C3=A9ment=20Chigot?=
+Date: Tue, 19 May 2020 16:03:54 +0200
+Subject: libgo: update x/sys/cpu after gccgo support added
+
+Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/234597
+---
+ gcc/go/gofrontend/MERGE | 2 +-
+ .../sys/cpu/{cpu_aix_ppc64.go => cpu_aix.go} | 2 +-
+ .../golang.org/x/sys/cpu/syscall_aix_gccgo.go | 27 +++
+ 3 files changed, 29 insertions(+), 2 deletions(-)
+ rename libgo/go/golang.org/x/sys/cpu/{cpu_aix_ppc64.go => cpu_aix.go} (96%)
+ create mode 100644 libgo/go/golang.org/x/sys/cpu/syscall_aix_gccgo.go
+
+diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
+index bc9c1f07eda..284374820b0 100644
+--- a/gcc/go/gofrontend/MERGE
b/gcc/go/gofrontend/MERGE
+@@ -1 +1,2 @@
+
++
+diff --git a/libgo/go/golang.org/x/sys/cpu/cpu_aix_ppc64.go b/libgo/go/golang.org/x/sys/cpu/cpu_aix.go
+similarity index 96%
+rename from libgo/go/golang.org/x/sys/cpu/cpu_aix_ppc64.go
+rename to libgo/go/golang.org/x/sys/cpu/cpu_aix.go
+index b0ede112d4e..02d03129e50 100644
+--- a/libgo/go/golang.org/x/sys/cpu/cpu_aix_ppc64.go
b/libgo/go/golang.org/x/sys/cpu/cpu_aix.go
+@@ -1 +1,2 @@
+
++
+diff --git a/libgo/go/golang.org/x/sys/cpu/syscall_aix_gccgo.go b/libgo/go/golang.org/x/sys/cpu/syscall_aix_gccgo.go
+new file mode 100644
+index 000..2609cc49ae7
+--- /dev/null
b/libgo/go/golang.org/x/sys/cpu/syscall_aix_gccgo.go
+@@ -0,0 +1 @@
++
+
+--
+2.27.0.rc0.183.gde8f92d652-goog
--
2.26.2
Re: New mklog script
On 5/22/20 6:43 PM, Martin Sebor wrote: On 5/21/20 2:16 AM, Martin Liška wrote: Hello Martin. Can you please compare the current mklog.py. Is there anything you miss compared to your current script? Nope, it matches the format I get with my script and even works better and runs faster. Very nice! I'll be happy to switch to using it instead. Great, good to hear! Thanks! Martin PS A couple of ideas for future enhancements are to have the script print "New function." or "New type." for newly added functions and types, and to print "Adjust comments." for changes to comments alone. Feel free to send patches for the new script ;) Martin
Re: ChangeLog files - server and client scripts
On 5/21/20 5:14 PM, Rainer Orth wrote: * In changelog_location, you allow only (among others) "a/b/c/" and "\ta/b/c/". Please also accept the "a/b/c:" and "\ta/b/c:" forms here: especially the second seems quite common. Ok, I believe these formats are supported as well. Feel free to mention some git revisions that are not recognized. Thanks, Martin
Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe
Hi, >> >> PRs from the second group were filed by me, so if there's consensus to >> >> close all >> >> of them, the ones from this second group I can close myself. I don't have >> >> the >> >> right permissions to modify PRs reported by someone else, so I'd like to >> >> ask a >> >> volunteer to step up and close the ones from the first group. >> >> >> >> WDYT? >> > >> > I can do both, if you want, or just the first group? Your choice. >> > >> > But let's hear other opinions first. >> >> Thanks. I think I'll close the second group myself, as they constitute almost >> half of the total amount. > > Okido, thanks! Two full weeks have passed without any new input from either former port maintainer or global maintainers, so it's probably about time to go ahead and wrap it up.
Re: New mklog script
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.
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.
Martin
Re: AVR CC0 transition
Hello! > I'm thinking about attempting to do the CC0 transition for the > AVR port in my spare time. I've read the CC0Transition gcc wiki > page, and as the AVR ISA does not have non-condition-code > clobbering arithmetic instructions, concluded that I'd have to > follow the steps outlined for case #2. If you are working on it, it might be a good idea to log in to Bountysource.com and mark the issue as being worked on [1], so you can get the bounty in case the conversion has been successful. Adrian > [1] > https://www.bountysource.com/issues/84630749-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Writing automated tests for the GCC driver
Hi, On 05/22, Richard Biener wrote: > On Thu, May 21, 2020 at 11:00 PM Giuliano Belinassi via Gcc > wrote: > > > > Hi, all. > > > > GCC have a extensive testsuite, that is no news at all. However they are > > focused on the compiler (cc1*) or in libraries, and I can't find tests > > related to the GCC driver. > > > > Are there tests to the GCC driver? If yes, is there any docs about how > > to write them? > > I think all tests to the driver eventually exercise a compiler in the end. > One obvious I can find is gcc.dg/driver-specs.c which tests > -specs=not-a-file properly diagnoses the missing file. Yes, but that does not cover all driver features. > > So the question back would be what kind of "driver" tests do you have? > That is, what makes them not, for example, "C compiler driven by driver" > tests? GCC driver supports several modes which are required for bootstrapping but there is no quick automated test for it. For instance. gcc a.c b.o -o a.out gcc a.c b.c gcc a.S and so on. So if you do some radical change to the GCC driver, making sure everything is correct get somewhat painful because you have to do a clean bootstrap and find out what is going wrong. If we had a dedicated testsuite for that, bootstrap could be avoided for development and only done at a last time, reducing development time. Thank you, Giuliano. > > Thanks, > Richard. > > > Thank you, > > Giuliano.
Re: Writing automated tests for the GCC driver
On Mon, May 25, 2020 at 4:37 PM Giuliano Belinassi wrote: > > Hi, > > On 05/22, Richard Biener wrote: > > On Thu, May 21, 2020 at 11:00 PM Giuliano Belinassi via Gcc > > wrote: > > > > > > Hi, all. > > > > > > GCC have a extensive testsuite, that is no news at all. However they are > > > focused on the compiler (cc1*) or in libraries, and I can't find tests > > > related to the GCC driver. > > > > > > Are there tests to the GCC driver? If yes, is there any docs about how > > > to write them? > > > > I think all tests to the driver eventually exercise a compiler in the end. > > One obvious I can find is gcc.dg/driver-specs.c which tests > > -specs=not-a-file properly diagnoses the missing file. > > Yes, but that does not cover all driver features. > > > > > So the question back would be what kind of "driver" tests do you have? > > That is, what makes them not, for example, "C compiler driven by driver" > > tests? > > GCC driver supports several modes which are required for bootstrapping > but there is no quick automated test for it. For instance. > > gcc a.c b.o -o a.out > gcc a.c b.c > gcc a.S > > and so on. So if you do some radical change to the GCC driver, making > sure everything is correct get somewhat painful because you have to do > a clean bootstrap and find out what is going wrong. If we had a > dedicated testsuite for that, bootstrap could be avoided for > development and only done at a last time, reducing development time. Hmm, indeed. I don't think we have specific tests for all variants above. Most of them get exercised one way or another of course but the testsuite usually separates the compile and link steps. I would think writing a dedicated dejagnu .exp file would be possible here, sth in a new gcc.dg/driver/, have a driver.exp driving things and using test files in that directory. Sharing stuff from testsuite/lib to find the driver and figure how to invoke it, gcc-dg.exp has gcc-dg-test which might be enough to drive things. > Thank you, > Giuliano. > > > > > Thanks, > > Richard. > > > > > Thank you, > > > Giuliano.
Website and Mobile App Development
We have ✅ 500+ clone ScriptHi, I am Reena From HW Infotech. Please share your phone number or Skype id, Whatsapp if you are looking to develop a clone of any website. Work in the following area : ✅ Clone Script for any Website and Mobile APP -Development and Digital Marketing for App, Web, Software Clone Scripts ✅Readymade Script for useful product -Shop Website Templates, Clone Scripts, & Marketplace Software | HW Infotech ✅Software Requirement Specification Documentation ✅A wireframe design for Website, ERP, Product &Mobile app ✅PHP Framework & MYSQL, HTML5, CSS3, JavaScript, jQuery, XML, JSON. ✅eCommerce, WordPress,Magento,Open Cart, Joomla, Magento 2, Prestashop ✅Mobile APP- Android, IOS, Phone Gap and Flutter ✅SEO, SMO, and PPC ✅Install and config the project ✅Plugin: Customize and create a new plugin ✅Migrate & Upgrade: sustainable development and long-term ✅WHM Panel server configuration ✅Server Optimization ✅Website and Server Penetration testing ✅Load Balancing and Failover clustering Server ✅Mail Server configuration for bulk emailing Contact us - Hire A Developer | Web and App Development Services | HW Infotech Regards Reena www.hwinfotech.com Gurugram | California |London|Vancouver|Abuja | Melbourne http://app.hwinfotech.net/index.php/lists/ce490wfctx887/unsubscribe/wc827k5p7ocb8/pd4964gyp085d
Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe
On 5/25/20, Arseny Solokha wrote: > Hi, > > >>> >> PRs from the second group were filed by me, so if there's consensus to >>> >> close all >>> >> of them, the ones from this second group I can close myself. I don't >>> >> have the >>> >> right permissions to modify PRs reported by someone else, so I'd like >>> >> to ask a >>> >> volunteer to step up and close the ones from the first group. >>> >> >>> >> WDYT? >>> > >>> > I can do both, if you want, or just the first group? Your choice. >>> > >>> > But let's hear other opinions first. >>> >>> Thanks. I think I'll close the second group myself, as they constitute >>> almost >>> half of the total amount. >> >> Okido, thanks! > > Two full weeks have passed without any new input from either former port > maintainer or global maintainers, so it's probably about time to go ahead > and > wrap it up. > Agreed; a reduction in the number of open bugs in my searches will be most welcome.
Re: How to update .debug_frame CFA offset for function epilogues?
Hi Segher, On Tue, Mar 31, 2020 at 04:49:53PM -0500, Segher Boessenkool wrote: > Hi Jozef, > > On Thu, Mar 26, 2020 at 12:33:38PM +, Jozef Lawrynowicz wrote: > > In some cases, I can fix the CFA offset by marking these epilogue insns as > > frame_related anyway, and adding reg notes which describe the stack pointer > > operations. For some other epilogue insns, marking them frame_related > > results in > > an ICE, which I'm assuming comes back to the fact that epilogue insns > > shouldn't > > be marked frame related. > > > What is the standard way for updating the CFA offset in the epilogue? > > What you already say you do: add notes, and often frame_related is set > as well. I agree that shouldn't be done, but it often is harmless. > > You need reg_notes for more than just the stack updates: importantly, > also for the restores of any saved register. Thanks for the advice, indeed the reason I was having problems was because not all stack operations were properly annotated with reg notes. The reason I was seeing the ICE was because of unspec insns which were marked as frame related but didn't have accompanything reg notes, of course it is now clear that stack modifications in an unspec need to be explicitly described. (Apologies for the late response, but I figure I may as well document the conclusion came to with this.) Jozef > > > Segher
Re: How to update .debug_frame CFA offset for function epilogues?
Hi! On Mon, May 25, 2020 at 06:20:49PM +0100, Jozef Lawrynowicz wrote: > On Tue, Mar 31, 2020 at 04:49:53PM -0500, Segher Boessenkool wrote: > > You need reg_notes for more than just the stack updates: importantly, > > also for the restores of any saved register. > > Thanks for the advice, indeed the reason I was having problems was > because not all stack operations were properly annotated with reg notes. > > The reason I was seeing the ICE was because of unspec insns which were marked > as frame related but didn't have accompanything reg notes, of course it > is now clear that stack modifications in an unspec need to be explicitly > described. One thing that helps debugging this is readelf -wframe (but there are other methods). A bit late for help to you ;-) > (Apologies for the late response, but I figure I may as well document > the conclusion came to with this.) No, thanks, it is good to hear it helped! Segher
Re: New mklog script
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?
commit 787893dc41fb8288994a2350943c22e2388476e7
Author: Jason Merrill
Date: Fri May 22 18:40:35 2020 -0400
gcc-git: Add prepare-commit-msg.
This patch introduces a prepare-commit-msg hook that appends a ChangeLog
skeleton to a commit message when the GCC_FORCE_MKLOG environment variable
is set, and a 'git commit-mklog' command set that variable while running
'git commit'.
contrib/ChangeLog:
* prepare-commit-msg: New file.
* gcc-git-customization.sh: Install it. Add commit-mklog alias.
diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index 7a950ae5f38..a3f7da8d20b 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -30,6 +30,11 @@ git config alias.gcc-backport '!f() { rev=$1; git cherry-pick -x $@; } ; f'
git config alias.gcc-mklog '!f() { "`git rev-parse --show-toplevel`/contrib/mklog.py" $@; } ; f'
+hookdir=`git rev-parse --git-path hooks`
+install "`git rev-parse --show-toplevel`/contrib/prepare-commit-msg" "$hookdir"
+
+git config alias.commit-mklog '!f() { GCC_FORCE_MKLOG=1 git commit "$@"; }; f'
+
# Make diff on MD files use "(define" as a function marker.
# Use this in conjunction with a .gitattributes file containing
# *.mddiff=md
diff --git a/contrib/prepare-commit-msg b/contrib/prepare-commit-msg
new file mode 100644
index 000..b06080b927c
--- /dev/null
+++ b/contrib/prepare-commit-msg
@@ -0,0 +1,43 @@
+#!/bin/sh
+
+COMMIT_MSG_FILE=$1
+COMMIT_SOURCE=$2
+SHA1=$3
+
+#echo "# $*" > $HOME/prepare-commit-msg-args
+
+# Can't do anything if $COMMIT_MSG_FILE isn't a file.
+if ! [ -f "$COMMIT_MSG_FILE" ]; then exit 0; fi
+
+# Don't do anything unless requested to.
+if [ -z "$GCC_FORCE_MKLOG" ]; then exit 0; fi
+
+if [ -z "$COMMIT_SOURCE" ] || [ $COMMIT_SOURCE = template ]; then
+# No source or "template" means new commit.
+cmd="diff --cached"
+
+elif [ $COMMIT_SOURCE = message ]; then
+# "message" means -m, assume a new commit if there are any changes staged.
+if ! git diff --cached --quiet; then
+ cmd="diff --cached"
+else
+ cmd="diff --cached HEAD^"
+fi
+
+# Add a blank line before th
Re: ChangeLog files - server and client scripts
On Mon, May 25, 2020 at 12:48 AM Martin Liška wrote: > > On 5/23/20 12:14 AM, Ian Lance Taylor wrote: > > Sure, I can wait. Thanks for looking at it. > > Hello. > > Thank you for patience. There's a patch that fixes that, > I'm going to install it. Thanks. I was able to push my change to master. Ian
[no subject]
تنزيل الغه العربيه
[IMPORTANT] ChangeLog related changes
Hi! I've turned the strict mode of Martin Liška's hook changes, 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: [IMPORTANT] ChangeLog related changes
On Tue, May 26, 2020 at 6:49 AM Jakub Jelinek via Gcc-patches wrote: > > Hi! > > I've turned the strict mode of Martin Liška's hook changes, > 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. Oh, no wonder my patch was rejected by git hook with error message --- ChangeLog files, DATESTAMP, BASE-VER and DEV-PHASE can be modified only separately from other files --- > If somebody makes a mistake in that, please wait 24 hours (at least until i commit a separate patch alone only for ChangeLog files, should i revert it? > 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 > -- BR, Hongtao
Re: ChangeLog files - server and client scripts
On May 25, 2020, Martin Liška wrote:
> On 5/21/20 5:14 PM, Rainer Orth wrote:
>> * In changelog_location, you allow only (among others) "a/b/c/" and
>> "\ta/b/c/". Please also accept the "a/b/c:" and "\ta/b/c:" forms
>> here: especially the second seems quite common.
> Ok, I believe these formats are supported as well. Feel free to mention
> some git revisions that are not recognized.
I've long used the following syntax to start ChangeLog entries:
for /ChangeLog
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.
The patch below seems to be enough to pass gcc-verify, and to recognize
and print the expected ChangeLog files. I suppose I'll have to adjust
the formatting to be able to push it, but, aside from that, is it ok to
install?
Do any hooks need to be adjusted to match?
I'm also a little concerned about '*/ChangeLog.*' files. Are we no
longer supposed to introduce them, or new ChangeLog entries to them? Or
should the scripts be extended to cover them?
for contrib/ChangeLog
* gcc-changelog/git_commit.py (changelog_regex): Accept optional
'for' prefix.
diff --git a/contrib/gcc-changelog/git_commit.py
b/contrib/gcc-changelog/git_commit.py
index 2cfdbc8..b8362c1 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: Writing automated tests for the GCC driver
Hello, Giuliano, On May 25, 2020, Giuliano Belinassi via Gcc wrote: > gcc a.c b.o -o a.out > gcc a.c b.c > gcc a.S > and so on. So if you do some radical change to the GCC driver, making > sure everything is correct get somewhat painful because you have to do > a clean bootstrap and find out what is going wrong. I'm about to install a patch that introduces significant changes to the GCC driver and a large number of tests that covers some of the above. Its main focus was to check that aux outputs got named as per the changes introduced in the patch, but I added some baseline tests that would cover some of the above. Feel free to extend gcc/testsuite/gcc.misc-tests/outputs.exp to cover other such baseline cases you may think of. -- 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
On 5/26/20 7:22 AM, Hongtao Liu via Gcc wrote: i commit a separate patch alone only for ChangeLog files, should i revert it? Hello. I've just done it. Martin
Re: [IMPORTANT] ChangeLog related changes
Great, thanks! On Tue, May 26, 2020 at 2:08 PM Martin Liška wrote: > > On 5/26/20 7:22 AM, Hongtao Liu via Gcc wrote: > > i commit a separate patch alone only for ChangeLog files, should i revert > > it? > > Hello. > > I've just done it. > > Martin -- BR, Hongtao
Re: ChangeLog files - server and client scripts
On 5/26/20 7:31 AM, Alexandre Oliva wrote:
On May 25, 2020, Martin Liška wrote:
On 5/21/20 5:14 PM, Rainer Orth wrote:
* In changelog_location, you allow only (among others) "a/b/c/" and
"\ta/b/c/". Please also accept the "a/b/c:" and "\ta/b/c:" forms
here: especially the second seems quite common.
Ok, I believe these formats are supported as well. Feel free to mention
some git revisions that are not recognized.
Hello.
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.
Sure. Starting from now, you don't need to put ChangeLog entries to their
corresponding files, it will be done automatically.
The patch below seems to be enough to pass gcc-verify, and to recognize
and print the expected ChangeLog files. I suppose I'll have to adjust
the formatting to be able to push it, but, aside from that, is it ok to
install?
I'm fine with the patch. Alternative approach is to start using
./contrib/mklog.py (a.k.a. git mklog).
Do any hooks need to be adjusted to match?
Yes, we sync the script from the GCC repository.
I'm also a little concerned about '*/ChangeLog.*' files. Are we no
longer supposed to introduce them, or new ChangeLog entries to them? Or
should the scripts be extended to cover them?
Right now we cover only ChangeLog files, so e.g. ChangeLog.dataflow is not
affected
(and checked). For newly added ChangeLog files, we can add them, but they must
first
appear in the git_commit.py script where we list all allowed locations.
Martin
for contrib/ChangeLog
* gcc-changelog/git_commit.py (changelog_regex): Accept optional
'for' prefix.
diff --git a/contrib/gcc-changelog/git_commit.py
b/contrib/gcc-changelog/git_commit.py
index 2cfdbc8..b8362c1 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.*)')
