Re: fast_math_flags_set_p vs. set_fast_math_flags inconsistency?
Joseph Myers wrote: > On Mon, 20 Jan 2020, Ulrich Weigand wrote: > > > This has the effect that e.g. after > > > > -ffast-math -fno-finite-math-only > > > > the __FAST_MATH__ macro is no longer predefined, but after > > > > -ffast-math -fno-associative-math > > > > the __FAST_MATH__ macro still *is* predefined, even though both > > -ffinite-math-only and -fassociative-math are implied by -ffast-math. > > > > Is this deliberate? (If so, is it documented somewhere?) > > I'd expect both to cause it to be undefined. My guess would be that some > past patch, after fast_math_flags_set_p was added, added more flags to > -ffast-math but accidentally failed to update fast_math_flags_set_p; you'd > need to look at past patches adding flags to -ffast-math to confirm if > it's accidental. It looks like there's multiple cases here. For the two flags -fassociative-math and -freciprocal-math, it seems to have happened just as you describe: they were created (split out of -funsafe-math-optimizations) in commit a1a826110720eda37c73f829daa4ee243ee953f5, which however did not update fast_math_flags_set_p. For the other three flags, -fsignaling-nans, -frounding-math, and -fcx-limited-range, the story appears to be a bit different: from the very beginning, those were treated somewhat differently: these are only modified as a result of -ffast-math, not -fno-fast-math (like the other flags derived from -ffast-math), and they are not considered by fast_math_flags_set_p. (I'm not sure if there is any particular reason why these should be treated differently here, though.) Finally, there is one "mixed" flag, -fexcess-precision, which is handled like the above three in that its default is only modified as a result of -ffast-math, not -fno-fast-math; but nevertheless this flag *is* checked in fast_math_flags_set_p. Do you think there is something that ought to be fixed here? Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
[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 subject for a patch will form a good summary when the message is committed to the repository if applied with 'git am'. Where possible, I've tried to align these rules with those already in use for glibc, so that the differences are minimal and only where necessary. Some things that differ from existing practice (at least by some people) are: - Use ':' rather than '[]' - This is more git friendly and works with 'git am'. - Put bug numbers at the end of the line rather than the beginning. - The bug number is useful, but not as useful as the brief summary. Also, use the shortened form, as the topic part is more usefully conveyed in the proper topic field (see above). diff --git a/htdocs/contribute.html b/htdocs/contribute.html index 042ff069..861f7e5e 100644 --- a/htdocs/contribute.html +++ b/htdocs/contribute.html @@ -249,13 +249,98 @@ that ChangeLog entries may be included as part of the patch and diffs representing new files may be omitted, especially if large, since they can be accessed directly from the repository.) +E-mail subject lines + +Your contribution e-mail subject line will become the first line of +the commit message for your patch. + +A high-quality e-mail subject line for a contribution contains the +following elements: + + + A classifier + Component tags + An optional series identifier + A brief summary + An optional bug number + + +Classifier + +The classifier identifies the type of contribution, for example a +patch, an RFC (request for comments) or a committed patch (where +approval is not necessary. The classifier should be written in upper +case and surrounded with square brackets. This is the only component +of the e-mail subject line that will not appear in the commit itself. +The classifier may optionally contain a version number (vN) and +a series marker (N/M). Examples are: + + + [PATCH] - a single patch + [PATCH v2] - the second version of a single patch + [PATCH 3/7] - the third patch in a series of seven +patches + [RFC] - a point of discussion, may contain a patch + [COMMITTED] - a patch that has already been committed. + + +Component tags + +A component tag is a short identifier that identifies the part of +the compiler being modified. This highlights to the relevant +maintainers that the patch may need their attention. Multiple +components may be listed if necessary. Each component tag should be +followed by a colon. For example, + + + libstdc++: + combine: + vax: testsuite: + + +Series identifier + +The series identifier is optional and is only relevant if a number of +patches are needed in order to effect an overall change. It should be +a short string that identifies the series (it is common to all +patches) and should be followed by a single dash surrounded by white +space. + +Brief summary + +The brief summary encapsulates in a few words the intent of the +change. For example: cleanup check_field_decls. + +Bug number + +If your patch fixes a bug in the compiler for which there is an +existing PR number the bug number should be stated. Use the +short-form variant (PRn) without the bugzilla component +identifier. + +Other messages + +Some large patch sets benefit from an introductory e-mail that +provides more context for the patch series and describes how the +patches have been broken up to provide for review. The convention is +that such messages should follow the same format as described above, +but the patch number should be set to zero, for example: [PATCH +0/7]. Remember that the introductory message will not be +committed with the patches themselves, so it should not contain any +important information that is not also covered in the individual +patches. If you send a summary e-mail with a series it is a good idea +to send the patches as follow-ups (essentially replies) to your +initial message so that mail software can group the messages +together. + Pinging patches, Getting patches applied If you do not receive a response to a patch that you have submitted within two weeks or so, it may be a good idea to chase it by sending a -follow-up email to the same list(s). Patches can occasionally fall through -the cracks. Please be sure to include a brief summary of the patch and the -URL of the entry in the mailing list archive of the original submission. +follow-up e-mail to the same list(s). Patches can occasionally fall +through the cracks. Please be sure to include a brief summary of the +patch and the URL of the entry in the mailing list archive of the +original submission. If you do not have write access and a patch of yours has been approved, but not committed, please advise the approver of that fact. You may w
Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions
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 some new (additional) rules for email subject lines > when contributing to GCC. The goal is to make sure that, as far as > possible, the subject for a patch will form a good summary when the > message is committed to the repository if applied with 'git am'. Where > possible, I've tried to align these rules with those already in > use for glibc, so that the differences are minimal and only where > necessary. > > Some things that differ from existing practice (at least by some people) > are: > > - Use ':' rather than '[]' > - This is more git friendly and works with 'git am'. > - Put bug numbers at the end of the line rather than the beginning. > - The bug number is useful, but not as useful as the brief summary. > Also, use the shortened form, as the topic part is more usefully > conveyed in the proper topic field (see above). 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: whatever words describe it (PR12345) or something: whatever words describe it: PR12345 or something: whatever words describe it [PR12345] or something else? Also, it would be nice to stress that the PR long form should be in the ChangeLog and somewhere on the later lines of the commit message, I don't think we pick up the shorter form from the first line when it short form (I could be wrong, but e.g. https://gcc.gnu.org/g:865257c447cc50f5819e9b53da83145f3c36c305 commit didn't make it into bugzilla). Jakub
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 some new (additional) rules for email subject lines when contributing to GCC. The goal is to make sure that, as far as possible, the subject for a patch will form a good summary when the message is committed to the repository if applied with 'git am'. Where possible, I've tried to align these rules with those already in use for glibc, so that the differences are minimal and only where necessary. Some things that differ from existing practice (at least by some people) are: - Use ':' rather than '[]' - This is more git friendly and works with 'git am'. - Put bug numbers at the end of the line rather than the beginning. - The bug number is useful, but not as useful as the brief summary. Also, use the shortened form, as the topic part is more usefully conveyed in the proper topic field (see above). 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: whatever words describe it (PR12345) or something: whatever words describe it: PR12345 or something: whatever words describe it [PR12345] or something else? Glibc use "[BZ #]" - obviously BZ becomes PR, but after that, I'm not too worried. I'd be happy with [PR #], but if folk want something else, please say so quickly... I'll prepare an edit for that... Also, it would be nice to stress that the PR long form should be in the ChangeLog and somewhere on the later lines of the commit message, I don't think we pick up the shorter form from the first line when it short form (I could be wrong, but e.g. https://gcc.gnu.org/g:865257c447cc50f5819e9b53da83145f3c36c305 commit didn't make it into bugzilla). Yes, good point. Thanks. R.
Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions
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: whatever words describe it (PR12345) > > or > > something: whatever words describe it: PR12345 > > or > > something: whatever words describe it [PR12345] > > or something else? > > Glibc use "[BZ #]" - obviously BZ becomes PR, but after that, I'm not > too worried. I'd be happy with [PR #], but if folk want something else, > please say so quickly... [PR 12345] or [PR #12345] is bad, because the bugzilla won't underline it, it needs to be either PR12345 word, or PR component/12345 . Jakub
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: whatever words describe it (PR12345) or something: whatever words describe it: PR12345 or something: whatever words describe it [PR12345] or something else? Glibc use "[BZ #]" - obviously BZ becomes PR, but after that, I'm not too worried. I'd be happy with [PR #], but if folk want something else, please say so quickly... [PR 12345] or [PR #12345] is bad, because the bugzilla won't underline it, it needs to be either PR12345 word, or PR component/12345 . Jakub ok, lets go with [PR] then. R.
git: remote: *** The first line of a commit message should be a short description of the change, not a single word.
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 threads Compressing objects: 100% (14/14), done. Writing objects: 100% (14/14), 1.77 KiB | 1.77 MiB/s, done. Total 14 (delta 13), reused 0 (delta 0) remote: *** The first line of a commit message should be a short description of the change, not a single word. remote: error: hook declined to update refs/users/marxin/heads/filter-non-common To git+ssh://gcc.gnu.org/git/gcc.git ! [remote rejected] me/filter-non-common -> refs/users/marxin/heads/filter-non-common (hook declined) error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc.git' Thanks, Martin
Re: git: remote: *** The first line of a commit message should be a short description of the change, not a single word.
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 threads > Compressing objects: 100% (14/14), done. > Writing objects: 100% (14/14), 1.77 KiB | 1.77 MiB/s, done. > Total 14 (delta 13), reused 0 (delta 0) > remote: *** The first line of a commit message should be a short description > of the change, not a single word. > remote: error: hook declined to update > refs/users/marxin/heads/filter-non-common > To git+ssh://gcc.gnu.org/git/gcc.git > ! [remote rejected] me/filter-non-common -> > refs/users/marxin/heads/filter-non-common (hook declined) > error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc.git' Requiring slightly better messages than just a single word doesn't seem to restrictive to me, even on user branches.
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 threads Compressing objects: 100% (14/14), done. Writing objects: 100% (14/14), 1.77 KiB | 1.77 MiB/s, done. Total 14 (delta 13), reused 0 (delta 0) remote: *** The first line of a commit message should be a short description of the change, not a single word. remote: error: hook declined to update refs/users/marxin/heads/filter-non-common To git+ssh://gcc.gnu.org/git/gcc.git ! [remote rejected] me/filter-non-common -> refs/users/marxin/heads/filter-non-common (hook declined) error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc.git' Requiring slightly better messages than just a single word doesn't seem to restrictive to me, even on user branches. I agree. What's more, if you ever want to merge the branch into trunk you'll need to fix such messages, so why not just get them right in the first place? R.
Re: git: remote: *** The first line of a commit message should be a short description of the change, not a single word.
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 Enumerating objects: 27, done. Counting objects: 100% (27/27), done. Delta compression using up to 16 threads Compressing objects: 100% (14/14), done. Writing objects: 100% (14/14), 1.77 KiB | 1.77 MiB/s, done. Total 14 (delta 13), reused 0 (delta 0) remote: *** The first line of a commit message should be a short description of the change, not a single word. remote: error: hook declined to update refs/users/marxin/heads/filter-non-common To git+ssh://gcc.gnu.org/git/gcc.git ! [remote rejected] me/filter-non-common -> refs/users/marxin/heads/filter-non-common (hook declined) error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc.git' Requiring slightly better messages than just a single word doesn't seem to restrictive to me, even on user branches. plus it teaches you good practice in a safe area. I agree. What's more, if you ever want to merge the branch into trunk you'll need to fix such messages, so why not just get them right in the first place? Are you using 'merge' with some meaning other than git merge? because merging to trunk is verboeten. nathan -- Nathan Sidwell
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 Enumerating objects: 27, done. Counting objects: 100% (27/27), done. Delta compression using up to 16 threads Compressing objects: 100% (14/14), done. Writing objects: 100% (14/14), 1.77 KiB | 1.77 MiB/s, done. Total 14 (delta 13), reused 0 (delta 0) remote: *** The first line of a commit message should be a short description of the change, not a single word. remote: error: hook declined to update refs/users/marxin/heads/filter-non-common To git+ssh://gcc.gnu.org/git/gcc.git ! [remote rejected] me/filter-non-common -> refs/users/marxin/heads/filter-non-common (hook declined) error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc.git' Requiring slightly better messages than just a single word doesn't seem to restrictive to me, even on user branches. plus it teaches you good practice in a safe area. I agree. What's more, if you ever want to merge the branch into trunk you'll need to fix such messages, so why not just get them right in the first place? Are you using 'merge' with some meaning other than git merge? because merging to trunk is verboeten. In the sense 'integrate' your change into trunk. In practice I mean by a fast-forward push, of course. R.
Re: fast_math_flags_set_p vs. set_fast_math_flags inconsistency?
On Tue, 21 Jan 2020, Ulrich Weigand wrote: > It looks like there's multiple cases here. For the two flags > -fassociative-math and -freciprocal-math, it seems to have happened just as > you describe: they were created (split out of -funsafe-math-optimizations) > in commit a1a826110720eda37c73f829daa4ee243ee953f5, which however did not > update fast_math_flags_set_p. So that's a bug. > For the other three flags, -fsignaling-nans, -frounding-math, and > -fcx-limited-range, the story appears to be a bit different: from the The first two of those are disabled by default as well as disabled by -ffast-math, so it seems right that -fno-fast-math does nothing with them and that they aren't checked by fast_math_flags_set_p. The last one is disabled by default but enabled by -ffast-math. So it would seem appropriate to handle it like other such options, disable it with -fno-fast-math, and check it in fast_math_flags_set_p. > Finally, there is one "mixed" flag, -fexcess-precision, which is handled > like the above three in that its default is only modified as a result of > -ffast-math, not -fno-fast-math; but nevertheless this flag *is* checked > in fast_math_flags_set_p. That one's trickier because the default depends on whether a C standards conformance mode is specified. -- Joseph S. Myers jos...@codesourcery.com
Re: git: remote: *** The first line of a commit message should be a short description of the change, not a single word.
On Tue, Jan 21, 2020 at 11:52 AM Richard Earnshaw (lists) < richard.earns...@arm.com> wrote: > 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 > Enumerating objects: 27, done. > Counting objects: 100% (27/27), done. > Delta compression using up to 16 threads > Compressing objects: 100% (14/14), done. > Writing objects: 100% (14/14), 1.77 KiB | 1.77 MiB/s, done. > Total 14 (delta 13), reused 0 (delta 0) > remote: *** The first line of a commit message should be a short > description of the change, not a single word. > remote: error: hook declined to update > refs/users/marxin/heads/filter-non-common > To git+ssh://gcc.gnu.org/git/gcc.git > ! [remote rejected] me/filter-non-common -> > refs/users/marxin/heads/filter-non-common (hook declined) > error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc.git > ' > >>> > >>> Requiring slightly better messages than just a single word doesn't > >>> seem to restrictive to me, even on user branches. > > > > plus it teaches you good practice in a safe area. > > > >> I agree. What's more, if you ever want to merge the branch into trunk > >> you'll need to fix such messages, so why not just get them right in > >> the first place? > > > > Are you using 'merge' with some meaning other than git merge? because > > merging to trunk is verboeten. > > In the sense 'integrate' your change into trunk. In practice I mean by > a fast-forward push, of course. > My commit messages while I'm working on something rarely have anything to do with the commit messages that I eventually push to trunk; there's no point in writing extensive description of stuff I might discard anyway. When I'm done developing a change I then squash and reorganize commits and write the commit message for public consumption. Jason
Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions
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 the PR number to be appended, shall it be something: whatever words describe it PR12345 or something: whatever words describe it (PR12345) or something: whatever words describe it: PR12345 or something: whatever words describe it [PR12345] or something else? Glibc use "[BZ #]" - obviously BZ becomes PR, but after that, I'm not too worried. I'd be happy with [PR #], but if folk want something else, please say so quickly... [PR 12345] or [PR #12345] is bad, because the bugzilla won't underline it, it needs to be either PR12345 word, or PR component/12345 . ok, lets go with [PR] then. Doesn't this use of [] have the same problem with git am? My summaries are often describing the bug I'm fixing, i.e. [PATCH] PR c++/91476 - anon-namespace reference temp clash between TUs. which is also the first line of my ChangeLog entry. I think you are proposing [COMMITTED] c++: Fix anon-namespace reference temp clash between TUs (PR91476) which can no longer be shared with the ChangeLog. Jason
Re: git: remote: *** The first line of a commit message should be a short description of the change, not a single word.
On Tue, 21 Jan 2020 at 17:06, Jason Merrill wrote: > > On Tue, Jan 21, 2020 at 11:52 AM Richard Earnshaw (lists) < > richard.earns...@arm.com> wrote: > > > 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 > > Enumerating objects: 27, done. > > Counting objects: 100% (27/27), done. > > Delta compression using up to 16 threads > > Compressing objects: 100% (14/14), done. > > Writing objects: 100% (14/14), 1.77 KiB | 1.77 MiB/s, done. > > Total 14 (delta 13), reused 0 (delta 0) > > remote: *** The first line of a commit message should be a short > > description of the change, not a single word. > > remote: error: hook declined to update > > refs/users/marxin/heads/filter-non-common > > To git+ssh://gcc.gnu.org/git/gcc.git > > ! [remote rejected] me/filter-non-common -> > > refs/users/marxin/heads/filter-non-common (hook declined) > > error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc.git > > ' > > >>> > > >>> Requiring slightly better messages than just a single word doesn't > > >>> seem to restrictive to me, even on user branches. > > > > > > plus it teaches you good practice in a safe area. > > > > > >> I agree. What's more, if you ever want to merge the branch into trunk > > >> you'll need to fix such messages, so why not just get them right in > > >> the first place? > > > > > > Are you using 'merge' with some meaning other than git merge? because > > > merging to trunk is verboeten. > > > > In the sense 'integrate' your change into trunk. In practice I mean by > > a fast-forward push, of course. > > > > My commit messages while I'm working on something rarely have anything to > do with the commit messages that I eventually push to trunk; there's no > point in writing extensive description of stuff I might discard anyway. > When I'm done developing a change I then squash and reorganize commits and > write the commit message for public consumption. Whether they make it to trunk or not doesn't really change the fact that a one-word message is poor. If it's only on your local machine, do what you like. The hook only complains when such a commit is published on gcc.gnu.org.
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 the PR number to be appended, shall it be something: whatever words describe it PR12345 or something: whatever words describe it (PR12345) or something: whatever words describe it: PR12345 or something: whatever words describe it [PR12345] or something else? Glibc use "[BZ #]" - obviously BZ becomes PR, but after that, I'm not too worried. I'd be happy with [PR #], but if folk want something else, please say so quickly... [PR 12345] or [PR #12345] is bad, because the bugzilla won't underline it, it needs to be either PR12345 word, or PR component/12345 . ok, lets go with [PR] then. Doesn't this use of [] have the same problem with git am? No, because only 'leading' [] blocks are removed - git mailinfo --help My summaries are often describing the bug I'm fixing, i.e. [PATCH] PR c++/91476 - anon-namespace reference temp clash between TUs. which is also the first line of my ChangeLog entry. I think you are proposing [COMMITTED] c++: Fix anon-namespace reference temp clash between TUs (PR91476) which can no longer be shared with the ChangeLog. I was trying to unify this with glibc. They specify the bug number at the end of the line. We can diverge if it's generally felt to be important, but details like this create needless friction for folk working in both communities. R.
[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 since before we did not have these scripts to make use of. I've not filled in the documentation for gcc-descr and gcc-undescr, Jakub has agreed to provide that at a later date. R. diff --git a/htdocs/gitwrite.html b/htdocs/gitwrite.html index 87a18fa7..047c139f 100644 --- a/htdocs/gitwrite.html +++ b/htdocs/gitwrite.html @@ -26,6 +26,7 @@ maintainers and significant developers. Example check-in session Creating and using branches git-merge-changelog + Personal and Vendor branches Tips&Tricks around your account @@ -370,6 +371,158 @@ git config --global merge.merge-changelog.driver "git-merge-changelog %O %A %B" echo "ChangeLog* merge=merge-changelog" >> $GCCSRCDIR/.git/info/attributes + +Personal and vendor branches + +The GCC git repository is used by many people and the branch and tag +namespace would become very polluted if all branches lived at the +top-level naming space. To help minimise the amount of data that +needs to be fetched the git repository on gcc.gnu.org supports +having personal and vendor branches that developers use to +share their work. These are not pulled by default, but simple +configuration steps can give access to them. + + + Personal branches live +in refs/users/username/heads with tags +in refs/users/username/tags. + Vendor branches live +in refs/vendors/vendor-name/heads with tags +in refs/vendors/vendor-name/tags. + + +Scripts exist the contrib directory to help manage these spaces. + +contrib/gcc-git-customization.sh + +This script will help set up your personal area. It will also define +some aliases that might be useful when developing GCC. The script will + first ask a number of questions: + + Your name - git uses this when you commit messages. You +can set this globally, but the script will confirm the setting is +appropriate for GCC as well. If you have not already set this +then git will try to find your name from your account. + Your email address - similar to above. If this is not +set globally, the script will not attempt to guess this field, so +you must provide a suitable answer. + The local name for the upstream repository - normally, the +default (origin) will be correct. This is the git remote that +connects directly to the gcc.gnu.org server. + Your account name on gcc.gnu.org - the script will try to +work this out based on the URL used to fetch from the git server, or +fall back to your local user name if that fails. Using this name +on the server for your personal space ensures that your branches will +not conflict with anybody elses. + The prefix to use for your personal branches - the default is +me, but you can change this if you prefer. The script +will add configuration information to allow local branches that +start me/to be pushed or pulled from +your personal space in the gcc git repository on the server. +Do not worry if you do not have an account on gcc.gnu.org. You will +not be able to create a personal space on the server, but other +settings configured by the script will still be useful. + + +If you have multiple clones of the gcc repository you can fetch +updates from your personal space by running + git fetch me +(or whatever personal prefix you've chosen). You can also push an +already existing branch using git push me me/branch. +Beware that if you have more than one personal branch set up locally, +simply typing git push me will potentially push all such +personal branches. Use --dry-run to check that what will be pushed is +what you intend. + +To create a new personal branch, the following sequence of steps can be +used: + + git push me :refs/users/ /heads/ + git fetch me + git checkout -b me/ remotes/me/ + +If you've used a different personal prefix to 'me' then use that + in the sequence described above. + +The script also defines a few useful aliases that can be used with the +repository: + + + svn-rev - Find the commit in the git repository that was +created from a particular revision number from the SVN era. The +first parameter must be the revision number you wish to look up, +an initial 'r' prefix is optional. You can then pass other +options that are accepted by git log to modify the format of the +output. Of particular use is the +--oneline option to summarize the commit on a single line. + + gcc-descr - Undocumented + gcc-undescr - Undocumented + + +The final customization that the script makes is to add a diff rule so +that running git diff on a machine description file (a file +with the suffix .md) will annotate +the dif
Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions
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 as > possible, the subject for a patch will form a good summary when the > message is committed to the repository if applied with 'git am'. > +A high-quality e-mail subject line for a contribution contains the > +following elements: > + A brief summary You could stress that this is the one thing that really matters. And it's not a summary, it's much too brief for that (at most ~50 chars), but yup it should be something that allows *a human* to identify what this is. Everything else is just convention. > +A component tag is a short identifier that identifies the part of > +the compiler being modified. This highlights to the relevant > +maintainers that the patch may need their attention. Multiple > +components may be listed if necessary. Each component tag should be > +followed by a colon. Often people use aaa/bbb: if drilling down a bit that way helps keep the subject short (which is the *point* of all this: keep things better consumable for humans). > +The brief summary encapsulates in a few words the intent of the > +change. For example: cleanup check_field_decls. It should start with a capital though. "Clean up blablal". (So no dot to end the sentence, this isn't a sentence). A capital helps the reader to quickly identify what is what, separate fluff from the core parts. > +Some large patch sets benefit from an introductory e-mail that > +provides more context for the patch series and describes how the > +patches have been broken up to provide for review. All non-trivial series, yeah. Maybe we should mention how v2 etc. of patch series should show what is changed? If there is a good standard practice for that at all :-) Segher
Re: git: remote: *** The first line of a commit message should be a short description of the change, not a single word.
On 1/21/20 6:30 PM, Jonathan Wakely wrote: Whether they make it to trunk or not doesn't really change the fact that a one-word message is poor. If it's only on your local machine, do what you like. The hook only complains when such a commit is published on gcc.gnu.org. I would disagree here. I used 'WIP' as my commit message for a branch that is an experimental and potentially fixes a PR. GCC git is a central point for my setup, I need to push the branch in order to pull it from a different machine and test it there. Moreover, as Jason said, one can have multiple commits that will be squashed anyway before a patch submission. Martin
What needs to be satisfied to become a type qualifier in standard?
Hello everyone, I am trying to see how a new type qualifier only for pointer variables is suitable to be in standard semantically. I have this thread ( https://gcc.gnu.org/ml/gcc-patches/2019-08/msg02015.html ) where Joseph discussed a bit about what a new type qualifier should satisfy. Can somebody help me to know the full list of existing logic that needs to be satisfied for a new type qualifier. Is going with this doc ( http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf ), in section 6.7.3, sufficient? Thanks, Akshat
