Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On 22/01/2020 16:28, Marek Polacek wrote: On Wed, Jan 22, 2020 at 04:05:37PM +, Richard Sandiford wrote: "Richard Earnshaw (lists)" writes: On 21/01/2020 17:20, Jason Merrill wrote: On 1/21/20 10:40 AM, Richard Earnshaw (lists) wrote: On 21/01/2020 15:39, Jakub Jelinek wrot

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On 22/01/2020 16:28, Marek Polacek wrote: On Wed, Jan 22, 2020 at 04:05:37PM +, Richard Sandiford wrote: "Richard Earnshaw (lists)" writes: On 21/01/2020 17:20, Jason Merrill wrote: On 1/21/20 10:40 AM, Richard Earnshaw (lists) wrote: On 21/01/2020 15:39, Jakub Jelinek wrot

wwwdocs: Document the gcc git repository layout

The GCC git repository makes use of some non-standard refs so that by default only the most active and useful branches and tags are fetched by a git clone. This patch documents the additional branch and tag spaces that exist on the server. Joseph, have I got all of these right? R. diff

Add News-feed item for git transition

We're missing a statement on the main news feed about the git transition. diff --git a/htdocs/index.html b/htdocs/index.html index 41bcfe18..ef85cc97 100644 --- a/htdocs/index.html +++ b/htdocs/index.html @@ -54,6 +54,10 @@ mission statement. News +GCC source repository converted to git. +

Add News-feed item for git transition

We're missing a statement on the main news feed about the git transition. diff --git a/htdocs/index.html b/htdocs/index.html index 41bcfe18..ef85cc97 100644 --- a/htdocs/index.html +++ b/htdocs/index.html @@ -54,6 +54,10 @@ mission statement. News +GCC source repository converted to git. +

Re: [patch] contrib: script to create a new vendor branch

On 22/01/2020 10:04, Richard Earnshaw (lists) wrote: On 21/01/2020 23:23, Hans-Peter Nilsson wrote: From: "Richard Earnshaw (lists)" Date: Tue, 21 Jan 2020 14:36:32 +0100 Correction, the branch should be named /, so the push should be git push vendors/ / For example, for the

Re: [patch] contrib: script to create a new vendor branch

On 21/01/2020 23:23, Hans-Peter Nilsson wrote: From: "Richard Earnshaw (lists)" Date: Tue, 21 Jan 2020 14:36:32 +0100 Correction, the branch should be named /, so the push should be git push vendors/ / For example, for the ARM vendor, the push would be git push vendors/A

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On 21/01/2020 19:26, Segher Boessenkool wrote: Hi! Thanks for doing this. On Tue, Jan 21, 2020 at 02:52:00PM +, Richard Earnshaw (lists) wrote: This patch proposes some new (additional) rules for email subject lines when contributing to GCC. The goal is to make sure that, as far

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On 21/01/2020 19:26, Segher Boessenkool wrote: Hi! Thanks for doing this. On Tue, Jan 21, 2020 at 02:52:00PM +, Richard Earnshaw (lists) wrote: This patch proposes some new (additional) rules for email subject lines when contributing to GCC. The goal is to make sure that, as far

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On 22/01/2020 09:07, Jakub Jelinek wrote: On Tue, Jan 21, 2020 at 06:50:13PM +, Richard Earnshaw (lists) wrote: Doesn't this use of [] have the same problem with git am? No, because only 'leading' [] blocks are removed - git mailinfo --help I've used openmp: Teach omp_code_to_statement

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On 22/01/2020 09:07, Jakub Jelinek wrote: On Tue, Jan 21, 2020 at 06:50:13PM +, Richard Earnshaw (lists) wrote: Doesn't this use of [] have the same problem with git am? No, because only 'leading' [] blocks are removed - git mailinfo --help I've used openmp: Teach omp_code_to_statement

[PATCH] wwwdocs: document scripts to access personal and vendor spaces

This patch documents some of the scripts that I've published for managing the personal and vendor spaces on the server. It also covers some of the other features that those scripts enable, so that it's all in one place. This is a complete rewrite of the material I had written previously

[PATCH] wwwdocs: document scripts to access personal and vendor spaces

This patch documents some of the scripts that I've published for managing the personal and vendor spaces on the server. It also covers some of the other features that those scripts enable, so that it's all in one place. This is a complete rewrite of the material I had written previously

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On 21/01/2020 17:20, Jason Merrill wrote: On 1/21/20 10:40 AM, Richard Earnshaw (lists) wrote: On 21/01/2020 15:39, Jakub Jelinek wrote: On Tue, Jan 21, 2020 at 03:33:22PM +, Richard Earnshaw (lists) wrote: Some examples would be useful I'd say, e.g. it is unclear in what way you want

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On 21/01/2020 17:20, Jason Merrill wrote: On 1/21/20 10:40 AM, Richard Earnshaw (lists) wrote: On 21/01/2020 15:39, Jakub Jelinek wrote: On Tue, Jan 21, 2020 at 03:33:22PM +, Richard Earnshaw (lists) wrote: Some examples would be useful I'd say, e.g. it is unclear in what way you want

Re: git: remote: *** The first line of a commit message should be a short description of the change, not a single word.

On 21/01/2020 16:43, Nathan Sidwell wrote: On 1/21/20 11:38 AM, Richard Earnshaw (lists) wrote: On 21/01/2020 16:14, Jonathan Wakely wrote: On Tue, 21 Jan 2020 at 16:03, Martin Liška wrote: Can you please remove the hook for user branches likes: $ git push origin me/filter-non-common

Re: git: remote: *** The first line of a commit message should be a short description of the change, not a single word.

On 21/01/2020 16:14, Jonathan Wakely wrote: On Tue, 21 Jan 2020 at 16:03, Martin Liška wrote: Can you please remove the hook for user branches likes: $ git push origin me/filter-non-common Enumerating objects: 27, done. Counting objects: 100% (27/27), done. Delta compression using up to 16

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On 21/01/2020 15:39, Jakub Jelinek wrote: On Tue, Jan 21, 2020 at 03:33:22PM +, Richard Earnshaw (lists) wrote: Some examples would be useful I'd say, e.g. it is unclear in what way you want the PR number to be appended, shall it be something: whatever words describe it PR12345 or something

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On 21/01/2020 15:39, Jakub Jelinek wrote: On Tue, Jan 21, 2020 at 03:33:22PM +, Richard Earnshaw (lists) wrote: Some examples would be useful I'd say, e.g. it is unclear in what way you want the PR number to be appended, shall it be something: whatever words describe it PR12345 or something

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On 21/01/2020 15:04, Jakub Jelinek wrote: On Tue, Jan 21, 2020 at 02:52:00PM +, Richard Earnshaw (lists) wrote: [updated, following some comments from Gerald, main differences are slight tweaks to the html markup and changing "email" to "e-mail"] This patch proposes

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On 21/01/2020 15:04, Jakub Jelinek wrote: On Tue, Jan 21, 2020 at 02:52:00PM +, Richard Earnshaw (lists) wrote: [updated, following some comments from Gerald, main differences are slight tweaks to the html markup and changing "email" to "e-mail"] This patch proposes

[PATCH, v2] wwwdocs: e-mail subject lines for contributions

[updated, following some comments from Gerald, main differences are slight tweaks to the html markup and changing "email" to "e-mail"] This patch proposes some new (additional) rules for email subject lines when contributing to GCC. The goal is to make sure that, as far as possible, the

[PATCH, v2] wwwdocs: e-mail subject lines for contributions

[updated, following some comments from Gerald, main differences are slight tweaks to the html markup and changing "email" to "e-mail"] This patch proposes some new (additional) rules for email subject lines when contributing to GCC. The goal is to make sure that, as far as possible, the

Re: [patch] contrib: script to create a new vendor branch

On 21/01/2020 13:29, Richard Earnshaw (lists) wrote: This script is intended to create a new vendor branch.  Doing so is not completely obvious if you are not familiar with the upstream structure, so this takes the pain out of getting it right. It doesn't check out the branch locally

[patch] contrib: script to create a new vendor branch

This script is intended to create a new vendor branch. Doing so is not completely obvious if you are not familiar with the upstream structure, so this takes the pain out of getting it right. It doesn't check out the branch locally, but does set everything up so that, if you have push enabled

Re: [v2] contrib: New remotes structure for vendor and personal refs

On 21/01/2020 10:26, Richard Earnshaw (lists) wrote: On 21/01/2020 01:47, Hans-Peter Nilsson wrote: From: "Richard Earnshaw (lists)" Date: Fri, 17 Jan 2020 12:21:07 +0100 As far as possible, I've made the script automatically restructure any existing fetch or push lines th

Re: [v2] contrib: New remotes structure for vendor and personal refs

On 21/01/2020 01:47, Hans-Peter Nilsson wrote: From: "Richard Earnshaw (lists)" Date: Fri, 17 Jan 2020 12:21:07 +0100 As far as possible, I've made the script automatically restructure any existing fetch or push lines that earlier versions of the scripts may have created - t

Re: [PATCH, GCC/ARM] Fix clear_operation_p uninitialised variable

On 20/01/2020 18:25, Mihail Ionescu wrote: > Hi, > > > This patch fixes the uninitialised 'last_regno' variable introduced in: > https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01299.html > and makes the clear_operation_p code more readable. > > *** gcc/ChangeLog *** > > 2020-01-20 Mihail-Calin

Re: [wwwdocs] Updates to contribute.html for git-friendly posting rules

On 19/01/2020 14:09, Gerald Pfeifer wrote: Hi Richard, On Thu, 9 Jan 2020, Richard Earnshaw (lists) wrote: The thread on gcc@ is now so long and complicated that this proposal back at the start has dropped off the radar. With the switch now imminent I'd like to re-propose this change

Re: [v2] contrib: New remotes structure for vendor and personal refs

On 17/01/2020 11:21, Richard Earnshaw (lists) wrote: The initial structure for vendor and personal branches makes use of the default remote (normally origin) for the upstream repository). Unfortunately, this causes some confusion, especially for personal branches because a push will not push

Re: [patch] contrib: Don't add push rules for personal and vendor spaces.

On 16/01/2020 15:00, Jakub Jelinek wrote: On Wed, Jan 15, 2020 at 10:48:23PM +, Joseph Myers wrote: A reasonable replacement for those push rules might be command aliases (e.g. "git upush " to push the user branch ). Would we have then separate aliases for pushing to one vendor branch and

Re: contrib: Check and if needed set user.name and user.email in gcc-git-customization.sh

On 16/01/2020 14:49, Andreas Schwab wrote: On Jan 16 2020, Richard Earnshaw (lists) wrote: diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh index dae2c35bb57..1cde6fd8224 100755 --- a/contrib/gcc-git-customization.sh +++ b/contrib/gcc-git-customization.sh

[v2] contrib: New remotes structure for vendor and personal refs

The initial structure for vendor and personal branches makes use of the default remote (normally origin) for the upstream repository). Unfortunately, this causes some confusion, especially for personal branches because a push will not push to the correct upstream location. This can be 'fixed'

contrib: New remotes structure for vendor and personal refs

The initial structure for vendor and personal branches makes use of the default remote (normally origin) for the upstream repository). Unfortunately, this causes some confusion, especially for personal branches because a push will not push to the correct upstream location. This can be 'fixed'

Re: gcc-cvs mails for personal/vendor branches for merge commits

On 16/01/2020 14:11, Jakub Jelinek wrote: On Thu, Jan 16, 2020 at 12:40:02PM +0100, Joel Brobecker wrote: I think there's a similar issue not just for merges but for non-fast-forward pushes as well. As a glibc example, consider and

Re: contrib: Check and if needed set user.name and user.email in gcc-git-customization.sh

On 15/01/2020 16:59, Richard Earnshaw (lists) wrote: As discussed on IRC, this adds a couple more checks in the customization setup for git.  If the variables user.name and user.email are not set anywhere in the git config hierarchy, we set some local values.  We always ask about the values we

Re: analyzer branch renamed to "devel/analyzer"

On 15/01/2020 15:19, David Malcolm wrote: Although most of the analyzer work is now on master I'm tracking additional work in a branch (for future features, work that isn't quite ready yet, etc). This used to be "dmalcolm/analyzer" on the git mirror. The new git server doesn't seem to like

contrib: Check and if needed set user.name and user.email in gcc-git-customization.sh

As discussed on IRC, this adds a couple more checks in the customization setup for git. If the variables user.name and user.email are not set anywhere in the git config hierarchy, we set some local values. We always ask about the values we detect and if the user gives an answer that is new,

Re: gcc-cvs mails for personal/vendor branches for merge commits

On 15/01/2020 16:30, Joseph Myers wrote: On Wed, 15 Jan 2020, Jason Merrill wrote: On 1/15/20 9:56 AM, Joseph Myers wrote: On Wed, 15 Jan 2020, Jakub Jelinek wrote: Or, if that is not possible, disable gcc-cvs mail for vendor and private branches altogether? I think this is desirable.

Re: [PATCH] .gitattributes: Add *.md diff=md

On 15/01/2020 13:19, Richard Earnshaw (lists) wrote: On 15/01/2020 11:45, Jakub Jelinek wrote: Hi! As discussed on IRC, this patch adds the .gitattributes part of the better diff for *.md files customization. Tested in a tree with contrib/gcc-git-customization.sh performed, config/i386/i386.md

Re: Add attribute to match *.md and *.pd to the git diff hook

On 15/01/2020 13:17, Richard Earnshaw (lists) wrote: The gcc-git-customization script sets up a diff hook to match (define as a function name hook so that diff -p style annotations will match a pattern name. This patch does the other half of this in the gcc configuration by matching *.pd

Re: [PATCH] .gitattributes: Add *.md diff=md

On 15/01/2020 11:45, Jakub Jelinek wrote: Hi! As discussed on IRC, this patch adds the .gitattributes part of the better diff for *.md files customization. Tested in a tree with contrib/gcc-git-customization.sh performed, config/i386/i386.md diffing then nicely shows the pattern, and in a tree

Add attribute to match *.md and *.pd to the git diff hook

The gcc-git-customization script sets up a diff hook to match (define as a function name hook so that diff -p style annotations will match a pattern name. This patch does the other half of this in the gcc configuration by matching *.pd and *.md to this new rule * .gitattributes: Use

Re: [patch] contrib: Don't add push rules for personal and vendor spaces.

On 14/01/2020 14:55, Richard Earnshaw (lists) wrote: Originally, it seemed like a good idea to add automatic 'push' rules to the git configuration, so that personal- and vendor-space commits would automatically push to the right place. Unfortunately, this changes git's behaviour

Re: [PATCH] contrib: git descr/undescr aliases fix for older git

On 14/01/2020 23:44, Jakub Jelinek wrote: On Tue, Jan 14, 2020 at 10:12:09AM +0100, Jakub Jelinek wrote: Note, for the scripts running on sourceware I also had to remove those tags/ part, but thought it is because of running against the bare repo. We could change those into

Backport: Add support for gcc as git submodule of another repository.

This is a straight backport of https://gcc.gnu.org/ml/gcc-patches/2018-04/msg01352.html. Without this contrib/gcc_update fails if run from a worktree, while git pull works just fine. Pushed to the gcc-8 branch. diff --git a/contrib/ChangeLog b/contrib/ChangeLog index

[patch] contrib: Don't add push rules for personal and vendor spaces.

Originally, it seemed like a good idea to add automatic 'push' rules to the git configuration, so that personal- and vendor-space commits would automatically push to the right place. Unfortunately, this changes git's behaviour and with these settings "git push" will try to push all branches in a

Re: contrib: script to setup git to pull a vendors branches

On 10/01/2020 15:04, Richard Earnshaw (lists) wrote: > This simple script is intended to setup a new git configuration to pull > the branches and tags for a specific vendor.  This should simplify some > of the steps needed for working with a vendor's branches. > > * git-fetch-vend

Re: Some local customization enhancements when using git

On 13/01/2020 13:44, Richard Earnshaw (lists) wrote: > On 10/01/2020 14:26, Richard Earnshaw (lists) wrote: >> On 10/01/2020 13:23, Richard Earnshaw (lists) wrote: >>> This patch is intended to help with folks setting up a git work >>> environment for use with GCC foll

Re: Some local customization enhancements when using git

On 10/01/2020 14:26, Richard Earnshaw (lists) wrote: > On 10/01/2020 13:23, Richard Earnshaw (lists) wrote: >> This patch is intended to help with folks setting up a git work >> environment for use with GCC following the transition to git.  It >> currently does a couple of

Re: [wwwdocs] Git transition - how to access private user and vendor branches

On 11/01/2020 15:41, Segher Boessenkool wrote: > Hi Richard, > > On Thu, Jan 09, 2020 at 04:50:03PM +, Richard Earnshaw (lists) wrote: >> Given the proposed intention to use non-standard refspecs for private >> and vendor branches I've written some notes on how to use t

Re: [PATCH][arm][backport] arm: fix v[78]-r multilibs when configured with --with-multlib-list=aprofile

On 10/01/2020 14:30, Przemyslaw Wirkus wrote: Hi, When gcc for Arm is configured with --with-multilib-list=aprofile a misplaced endif directive in the makefile was causing the arm->thumb mapping for multilibs to be omitted from the reuse rules. This resulted in the default multilib being picked

Re: [PATCH][arm] [backport] arm: Fix rmprofile multilibs when architecture includes +mp or +sec (PR target/93188)

On 10/01/2020 14:31, Przemyslaw Wirkus wrote: Hi, When only the rmprofile multilibs are built, compiling for armv7-a should select the generic v7 multilibs. This used to work before +sec and +mp were added to the architecture options but it was broken by that update. This patch fixes those

contrib: script to setup git to pull a vendors branches

This simple script is intended to setup a new git configuration to pull the branches and tags for a specific vendor. This should simplify some of the steps needed for working with a vendor's branches. * git-fetch-vendor.sh: New file. R. diff --git a/contrib/git-fetch-vendor.sh

Re: Some local customization enhancements when using git

On 10/01/2020 13:23, Richard Earnshaw (lists) wrote: This patch is intended to help with folks setting up a git work environment for use with GCC following the transition to git.  It currently does a couple of things. 1) Add an alias 'svn-rev' to git so that you can look up a legacy commit

Re: Some local customization enhancements when using git

On 10/01/2020 14:01, Richard Earnshaw (lists) wrote: On 10/01/2020 13:29, Richard Biener wrote: On Fri, Jan 10, 2020 at 2:23 PM Richard Earnshaw (lists) wrote: This patch is intended to help with folks setting up a git work environment for use with GCC following the transition to git

Re: Some local customization enhancements when using git

On 10/01/2020 13:29, Richard Biener wrote: On Fri, Jan 10, 2020 at 2:23 PM Richard Earnshaw (lists) wrote: This patch is intended to help with folks setting up a git work environment for use with GCC following the transition to git. It currently does a couple of things. 1) Add an alias 'svn

Some local customization enhancements when using git

This patch is intended to help with folks setting up a git work environment for use with GCC following the transition to git. It currently does a couple of things. 1) Add an alias 'svn-rev' to git so that you can look up a legacy commit by its svn revision number. This enables you to type

Re: [wwwdocs] Git transition - how to access private user and vendor branches

On 09/01/2020 16:50, Richard Earnshaw (lists) wrote: Given the proposed intention to use non-standard refspecs for private and vendor branches I've written some notes on how to use these. It would be helpful if someone could do some experiments to ensure that what I've written works properly

Re: Proposal for the transition timetable for the move to GIT

cking, and that is not worth it anyway:" Jeff Law "When Richard and I spoke we generally agreed that we felt a reposurgeon conversion, if it could be made to work was the preferred solution, followed by Maxim's approach and lastly the existing git-svn mirror." Richard Earnshaw (lists)

[wwwdocs] Git transition - how to access private user and vendor branches

Given the proposed intention to use non-standard refspecs for private and vendor branches I've written some notes on how to use these. It would be helpful if someone could do some experiments to ensure that what I've written works properly for all versions of git, not just the one I have

Re: Proposal for the transition timetable for the move to GIT

On 09/01/2020 02:38, Segher Boessenkool wrote: On Wed, Jan 08, 2020 at 11:34:32PM +, Joseph Myers wrote: As noted on overseers, once Saturday's DATESTAMP update has run at 00:16 UTC on Saturday, I intend to add a README.MOVED_TO_GIT file on SVN trunk and change the SVN hooks to make SVN

Re: GIT conversion: question about tags & release branches

On 09/01/2020 11:57, Richard Earnshaw (lists) wrote: On 09/01/2020 11:45, Martin Jambor wrote: Hi, On Thu, Jan 09 2020, Martin Liška wrote: Hi. I have question about release branches and release tags. For the current git mirror, we do have release tags living on release branches. Example

Re: GIT conversion: question about tags & release branches

On 09/01/2020 11:45, Martin Jambor wrote: Hi, On Thu, Jan 09 2020, Martin Liška wrote: Hi. I have question about release branches and release tags. For the current git mirror, we do have release tags living on release branches. Example: commit 64e1a4df1bc9dbf4cedb3a842c4eaff6b3425a66 Author:

Re: GIT conversion: question about tags & release branches

On 09/01/2020 09:44, Martin Liška wrote: Hi. I have question about release branches and release tags. For the current git mirror, we do have release tags living on release branches. Example: commit 64e1a4df1bc9dbf4cedb3a842c4eaff6b3425a66 Author: jakub Date:   Mon Aug 12 08:40:24 2019 +

[wwwdocs] Updates to contribute.html for git-friendly posting rules

The thread on gcc@ is now so long and complicated that this proposal back at the start has dropped off the radar. With the switch now imminent I'd like to re-propose this change, this time more formally. The text below draws heavily on the glibc equivalent rules in an attempt to bring some

arm: Fix rmprofile multilibs when architecture includes +mp or +sec (PR target/93188)

When only the rmprofile multilibs are built, compiling for armv7-a should select the generic v7 multilibs. This used to work before +sec and +mp were added to the architecture options but it was broken by that update. This patch fixes those variants and adds some tests to ensure that they

Re: [ARM] LLVM's -arm-assume-misaligned-load-store equivalent in GCC?

On 07/01/2020 15:57, Christophe Lyon wrote: Hi, I've received a support request where GCC generates strd/ldrd which require aligned memory addresses, while the user code actually provides sub-aligned pointers. The sample code is derived from CMSIS: #define __SIMD32_TYPE int #define

Re: Test GCC conversion with reposurgeon available

On 06/01/2020 22:09, Loren James Rittle wrote: On Fri, 3 Jan 2020, Joseph Myers wrote: git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-7a.git git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-7b.git I have not had a substantial commit to gcc [or, likely, post to this list] in a decade

Re: Proposal for the transition timetable for the move to GIT

On 02/01/2020 02:58, Alexandre Oliva wrote: > On Dec 30, 2019, "Richard Earnshaw (lists)" wrote: > >> Right, (and wrong). You have to understand how the release branches and >> tags are represented in CVS to understand why the SVN conversion is done >> this

Re: Proposal for the transition timetable for the move to GIT

On 31/12/2019 13:42, Joseph Myers wrote: > On Mon, 16 Dec 2019, Jeff Law wrote: > >>> Joseph Myers has made his choice. He has said repeatedly that he >>> wants to follow through with the reposurgeon conversion, and he's >>> putting his effort behind that by writing tests and even contributing

Re: Proposal for the transition timetable for the move to GIT

On 30/12/2019 15:49, Maxim Kuvyrkov wrote: >> On Dec 30, 2019, at 6:31 PM, Richard Earnshaw (lists) >> wrote: >> >> On 30/12/2019 13:00, Maxim Kuvyrkov wrote: >>>> On Dec 30, 2019, at 1:24 AM, Richard Earnshaw (lists) >>>> wrote: >>>>

Re: Git conversion: fixing email addresses from ChangeLog files

On 29/12/2019 22:56, Eric S. Raymond wrote: > Richard Earnshaw (lists) : >> Weak in the sense that it isn't proof given that the user name is >> partially redacted. There's nothing in the gcc archives that gives a >> full name either, unfortunately. >> >>

Re: Proposal for the transition timetable for the move to GIT

On 29/12/2019 23:13, Segher Boessenkool wrote: > On Sun, Dec 29, 2019 at 11:00:08PM +, Joseph Myers wrote: >> fixups in bugdb.py - and that way benefit both from reposurgeon making >> choices that are as conservatively safe as possible, which seems a >> desirable property for problem cases

Re: Proposal for the transition timetable for the move to GIT

On 30/12/2019 13:00, Maxim Kuvyrkov wrote: >> On Dec 30, 2019, at 1:24 AM, Richard Earnshaw (lists) >> wrote: >> >> On 29/12/2019 18:30, Maxim Kuvyrkov wrote: >>> Below are several more issues I found in reposurgeon-6a conversion >>> comparing it aga

Re: Git conversion: fixing email addresses from ChangeLog files

On 29/12/2019 22:24, Eric S. Raymond wrote: > Richard Earnshaw (lists) : >> Also, for this one: >> >> # "47044": "", >> >> There's some (relatively weak) evidence that this is Bjørn Wennberg (eg >> https://groups.google.com

Re: Proposal for the transition timetable for the move to GIT

On 29/12/2019 18:30, Maxim Kuvyrkov wrote: > Below are several more issues I found in reposurgeon-6a conversion comparing > it against gcc-reparent conversion. > > I am sure, these and whatever other problems I may find in the reposurgeon > conversion can be fixed in time. However, I don't see

Re: Git conversion: fixing email addresses from ChangeLog files

On 29/12/2019 12:32, Eric S. Raymond wrote: > Richard Earnshaw (lists) : >> I've just commented that one out for now; if anybody knows the correct >> addresses, please let me know.  Also, there's one joint list that I've >> not attempted to fix at this time. > >>

Re: Git conversion: fixing email addresses from ChangeLog files

On 27/12/2019 19:47, Richard Earnshaw (lists) wrote: > Email addresses from the ChangeLog files are not validated during > commits, so a number of typos exist in the extracted data. I've > extracted the 'Author:' entry from a prototype conversion and then piped > that through sort

Re: Git conversion: fixing email addresses from ChangeLog files

On 28/12/2019 20:11, Segher Boessenkool wrote: > On Sat, Dec 28, 2019 at 04:34:20PM +0000, Richard Earnshaw (lists) wrote: >> On 28/12/2019 14:54, Segher Boessenkool wrote: >>> On Sat, Dec 28, 2019 at 01:05:13PM +, Joseph Myers wrote: >>>> On Sat, 28 Dec

Re: Git conversion: fixing email addresses from ChangeLog files

On 28/12/2019 17:14, Joseph Myers wrote: > On Sat, 28 Dec 2019, Richard Earnshaw (lists) wrote: > >> My suggestion would be that we try to canonicalize all the author >> entries to UTF-8 as that avoids the limitations of ISO-8859-1, but that >> would probably need

Re: Proposal for the transition timetable for the move to GIT

On 28/12/2019 12:19, Segher Boessenkool wrote: > Branch merges do not mesh well with our commit policies, fwiw: > everything should normally be posted for public review on the mailing > lists. This does not really work for commits that have been set in > stone months before. > I disagree. The

Re: Git conversion: fixing email addresses from ChangeLog files

On 28/12/2019 12:04, Jakub Jelinek wrote: > On Fri, Dec 27, 2019 at 07:47:02PM +0000, Richard Earnshaw (lists) wrote: >> Email addresses from the ChangeLog files are not validated during >> commits, so a number of typos exist in the extracted data. I've >> extracted the

Re: Git conversion: fixing email addresses from ChangeLog files

On 28/12/2019 14:54, Segher Boessenkool wrote: > On Sat, Dec 28, 2019 at 01:05:13PM +, Joseph Myers wrote: >> On Sat, 28 Dec 2019, Segher Boessenkool wrote: >> >>> On Fri, Dec 27, 2019 at 07:47:02PM +, Richard Earnshaw (lists) wrote: >>>> 1 Autho

Git conversion: fixing email addresses from ChangeLog files

Email addresses from the ChangeLog files are not validated during commits, so a number of typos exist in the extracted data. I've extracted the 'Author:' entry from a prototype conversion and then piped that through sort and uniq -c. Subsequent analysis shows the following addresses/names that

Re: Proposal for the transition timetable for the move to GIT

On 27/12/2019 11:35, Joseph Myers wrote: > On Fri, 27 Dec 2019, Richard Earnshaw (lists) wrote: > >> I'm not really sure I understand why we don't want merge commits into >> trunk, especially for large changes. Performing archaeology on a change >> is just so much e

Re: Proposal for the transition timetable for the move to GIT

On 26/12/2019 18:59, Joseph Myers wrote: > On Thu, 26 Dec 2019, Jakub Jelinek wrote: > >> On Thu, Dec 26, 2019 at 04:58:22PM +, Joseph Myers wrote: >>> If we don't want merge commits on git master for the cases where people >>> put merge properties on trunk in the past, we can use a

Re: Commit messages and the move to git

On 19/12/2019 16:00, Joseph Myers wrote: On Thu, 19 Dec 2019, Jonathan Wakely wrote: It might be reasonable to assume rtl-optimization and tree-optimization are aliases, and not treat it as suspicious if those two appear mixed up. And anything where bugzilla has component debug or lto and the

Re: Test GCC conversions (publicly) available

On 19/12/2019 16:00, Eric S. Raymond wrote: Joseph Myers : On Thu, 19 Dec 2019, Eric S. Raymond wrote: There are other problems that might cause a delay beyond the 31st, however. Best if I let Joseph nd Richard explain those. I presume that's referring to the checkme: bug annotations where

Re: Commit messages and the move to git

On 19/12/2019 15:44, Jonathan Wakely wrote: These scraped "INVALID" as the component from the changelog, because it said "libgfortran/24685": revert: re PR libfortran/24685 (real(16) formatted input is broken for huge values (gfortran.dg/default_format_2.f90) [checkme: INVALID SVN r142840])

Re: Commit messages and the move to git

On 19/12/2019 15:17, Jonathan Wakely wrote: On Thu, 19 Dec 2019 at 14:29, Joseph Myers wrote: On Thu, 19 Dec 2019, Richard Earnshaw (lists) wrote: Best of all would be a pull request on https://gitlab.com/esr/gcc-conversion/tree/master to update bugdb.py directly. Note if doing

Re: Commit messages and the move to git

On 19/12/2019 11:16, Jakub Jelinek wrote: On Thu, Dec 19, 2019 at 12:01:28AM +, Joseph Myers wrote: re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme: tree-optimization SVN r277822]) re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme:

Re: Commit messages and the move to git

On 19/12/2019 12:35, Jonathan Wakely wrote: On Thu, 19 Dec 2019 at 12:33, Richard Earnshaw (lists) wrote: On 19/12/2019 12:23, Jonathan Wakely wrote: On Thu, 19 Dec 2019 at 11:50, Richard Earnshaw (lists) wrote: On 19/12/2019 09:27, Jonathan Wakely wrote: On Thu, 19 Dec 2019 at 00:02

Re: Commit messages and the move to git

On 19/12/2019 12:23, Jonathan Wakely wrote: On Thu, 19 Dec 2019 at 11:50, Richard Earnshaw (lists) wrote: On 19/12/2019 09:27, Jonathan Wakely wrote: On Thu, 19 Dec 2019 at 00:02, Joseph Myers wrote: On Wed, 18 Dec 2019, Joseph Myers wrote: On Mon, 18 Nov 2019, Richard Earnshaw (lists

Re: Commit messages and the move to git

On 19/12/2019 11:50, Richard Earnshaw (lists) wrote: On 19/12/2019 09:27, Jonathan Wakely wrote: On Thu, 19 Dec 2019 at 00:02, Joseph Myers wrote: On Wed, 18 Dec 2019, Joseph Myers wrote: On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote: I've attached a sample from the start

Re: Commit messages and the move to git

On 19/12/2019 09:27, Jonathan Wakely wrote: On Thu, 19 Dec 2019 at 00:02, Joseph Myers wrote: On Wed, 18 Dec 2019, Joseph Myers wrote: On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote: I've attached a sample from the start of the fixed list - the full list is far too big to post

Re: [PATCH][AArch64] Fixup core tunings

On 13/12/2019 12:23, Wilco Dijkstra wrote: Several tuning settings in cores.def are not consistent. Set the tuning for Cortex-A76AE and Cortex-A77 to neoversen1 so it is the same as for Cortex-A76 and Neoverse N1. Set the tuning for Neoverse E1 to cortexa73 so it's the same as for Cortex-A65.

Re: Proposal for the transition timetable for the move to GIT

On 11/12/2019 15:19, Jonathan Wakely wrote: > On Wed, 11 Dec 2019 at 15:03, Richard Earnshaw (lists) wrote: >> I wouldn't bother with that. There are known defects in the version of >> reposurgeon that I used to produce that which have since been fixed. It >> was *never* the

Re: Proposal for the transition timetable for the move to GIT

On 11/12/2019 14:40, Maxim Kuvyrkov wrote: >> On Dec 9, 2019, at 9:19 PM, Joseph Myers wrote: >> >> On Fri, 6 Dec 2019, Eric S. Raymond wrote: >> >>> Reposurgeon has been used for several major conversions, including groff >>> and Emacs. I don't mean to be nasty to Maxim, but I have not yet

arm: Fix an incorrect warning when -mcpu=cortex-a55 is used with -mfloat-abi=soft

When a CPU such as cortex-a55 is used with the soft-float ABI variant, the compiler is incorrectly issuing a warning about a mismatch between the architecture (generated internally) and the CPU. This is not expected or intended. The problem stems from the fact that we generate (correctly) an

<    1   2   3   4   5   6   7   8   9   10   >