Re: progress update

[Martin Jambor]

Hi,

On Tue, Jun 15 2021, David Malcolm via Gcc wrote:
>

[...]

>
> Are you perhaps building the first stage using clang, or a very old
> gcc?  That would likely generate very different debuginfo, which might
> explain the differences in behavior that you're seeing in gdb.
>
> If I run into problems using gdb to debug the code, and all else fails,
> I sometimes hack up the build flags in the generated Makefile to turn
> off optimizations and add debug flags.
>

If you run make in the gcc subdirectory of the build directory, changed
files are recompiled without optimization.  Often when I am about to use
gdb to debug the compiler, I touch tree.h and/or cgraph.h and then
rebuild the compiler in this way to end up with an executable where
things are not optimized away.

Martin

Re: [ranger-tech] How to use ranges within any pass with get_range_query()

[Martin Jambor]

Hi,

On Thu, Jun 10 2021, Aldy Hernandez via Gcc wrote:
> As part of the ranger development we have found that there are various 
> pieces of the infrastructure that can be used independently, and we’d 
> like to document them in the hopes that they are useful to others.  We 
> will be contributing short posts documenting parts of the ranger, which 
> we hope can become part of a more persistent documentation (wiki? 
> Internal docs?).

Thank you very much for writing this up.  And yes, please add something
like this to gcc/doc/gccint.texi - perhaps after it is converted to
Sphinx, assuming that writing in that format is easier.

Thanks again,

Martin

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Jonathan Wakely via Gcc]

On Wed, 16 Jun 2021 at 03:03, Martin Sebor  wrote:
>
> On 6/15/21 6:56 PM, Hans-Peter Nilsson wrote:
> > On Fri, 11 Jun 2021, Martin Sebor via Gcc wrote:
> >
> >> On 6/11/21 11:32 AM, Jonathan Wakely wrote:
> >>> On Fri, 11 Jun 2021 at 18:02, Martin Sebor wrote:
>  My objection is to making our policies and tools more restrictive
>  than they need to be.  We shouldn't expect everyone to study whole
>  manuals just to figure out how to successfully commit a change (or
>  learn how to format it just the right way).  It should be easy.
> >>>
> >>> I agree, to some extent. But consistency is also good. The conventions
> >>> for GNU ChangeLog formatting exist for a reason, and so do the
> >>> conventions for good Git commit messages.
> >>>
>  Setting this discussion aside for a moment and using a different
>  example, the commit hook rejects commit messages that don't start
>  ChangeLog entries with tabs.  It also rejects commit messages that
>  don't list all the same test files as those changed by the commit
>  (and probably some others as well).  That's in my view unnecessary
>  when the hook could just replace the leading spaces with tabs and
>  automatically mention all the tests.
> 
>  I see this proposal as heading in the same direction.  Rather than
>  making the script fix things up if we get them wrong it would reject
>  the commit, requiring the user to massage the ChangeLog by hand into
>  an unnecessarily rigid format.
> >>>
> >>> You cannot "fix things up" in a server-side receive hook, because
> >>> changing the commit message would alter the commit hash, which would
> >>> require the committer to do a rebase to proceed. That breaks the
> >>> expected behaviour and workflow of a git repo.
> >>>
> >>> You can use the scripts on the client side to verify your commit
> >>> message before pushing, so you don't have to be surprised when the
> >>> server rejects it.
> >>
> >> That sounds like a killer argument.  Do we have shared client-side
> >> scripts that could fix things up for us, or are we each on our own
> >> to write them?
> >
> > I hope I got your view wrong.  If not: the "scripts fixing
> > things up for us" direction is flawed (compared to the "scripts
> > rejecting bad formats"), unless offered as a non-default option;
> > please don't proceed.
> >
> > Why?  For one, there'll always be bugs in the scripting.
> > Mitigate those situations: while wrongly rejecting a commit is
> > bad, wrongly "fixing things up" is worse, as a general rule.
> > Better avoid that.  (There's probably a popular "pattern name"
> > for what I try to describe.)
>
> The word that comes to mind is Technophobia.  Is it wise to trust
> compilers to transform programs from their source form into
> executables?  What if there are bugs in either?  What about the OS?
> The whole computer, or the Internet?  Our cars?  Fortunately, there's
> more to gain than to lose by trusting automation.  If there weren't
> human progress would be stuck sometime in the 1700's.
>
> But we're not talking about anything anywhere that sophisticated
> here: a sed script to copy and paste a piece of text in
> the description of a change from one place to another.  It's been
> done a few times before with more important data than ChangeLogs.

But git commits are immutable (in practice, because we don't allow
rewriting history by force pushing) so having automated rewrites on
the server side where mistakes can't be corrected is a bad idea. Just
get your commit message right before you push (using automated tools
if you prefer) and give it a once over before pushing.

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Martin Sebor via Gcc]

On 6/15/21 9:42 PM, Jason Merrill wrote:
On Tue, Jun 15, 2021 at 10:04 PM Martin Sebor via Gcc > wrote:


On 6/15/21 6:56 PM, Hans-Peter Nilsson wrote:
 > On Fri, 11 Jun 2021, Martin Sebor via Gcc wrote:
 >
 >> On 6/11/21 11:32 AM, Jonathan Wakely wrote:
 >>> On Fri, 11 Jun 2021 at 18:02, Martin Sebor wrote:
  My objection is to making our policies and tools more restrictive
  than they need to be.  We shouldn't expect everyone to study whole
  manuals just to figure out how to successfully commit a change (or
  learn how to format it just the right way).  It should be easy.
 >>>
 >>> I agree, to some extent. But consistency is also good. The
conventions
 >>> for GNU ChangeLog formatting exist for a reason, and so do the
 >>> conventions for good Git commit messages.
 >>>
  Setting this discussion aside for a moment and using a different
  example, the commit hook rejects commit messages that don't start
  ChangeLog entries with tabs.  It also rejects commit messages that
  don't list all the same test files as those changed by the commit
  (and probably some others as well).  That's in my view unnecessary
  when the hook could just replace the leading spaces with tabs and
  automatically mention all the tests.
 
  I see this proposal as heading in the same direction.  Rather than
  making the script fix things up if we get them wrong it would
reject
  the commit, requiring the user to massage the ChangeLog by
hand into
  an unnecessarily rigid format.
 >>>
 >>> You cannot "fix things up" in a server-side receive hook, because
 >>> changing the commit message would alter the commit hash, which
would
 >>> require the committer to do a rebase to proceed. That breaks the
 >>> expected behaviour and workflow of a git repo.
 >>>
 >>> You can use the scripts on the client side to verify your commit
 >>> message before pushing, so you don't have to be surprised when the
 >>> server rejects it.
 >>
 >> That sounds like a killer argument.  Do we have shared client-side
 >> scripts that could fix things up for us, or are we each on our own
 >> to write them?
 >
 > I hope I got your view wrong.  If not: the "scripts fixing
 > things up for us" direction is flawed (compared to the "scripts
 > rejecting bad formats"), unless offered as a non-default option;
 > please don't proceed.
 >
 > Why?  For one, there'll always be bugs in the scripting.
 > Mitigate those situations: while wrongly rejecting a commit is
 > bad, wrongly "fixing things up" is worse, as a general rule.
 > Better avoid that.  (There's probably a popular "pattern name"
 > for what I try to describe.)

The word that comes to mind is Technophobia.  Is it wise to trust
compilers to transform programs from their source form into
executables?  What if there are bugs in either?  What about the OS?
The whole computer, or the Internet?  Our cars?  Fortunately, there's
more to gain than to lose by trusting automation.  If there weren't
human progress would be stuck sometime in the 1700's.

But we're not talking about anything anywhere that sophisticated
here: a sed script to copy and paste a piece of text in
the description of a change from one place to another.  It's been
done a few times before with more important data than ChangeLogs.


git gcc-commit-mklog already automates most of the process.  It could 
also automate adding [PRx] to the first line.  Is that what you're 
asking for?


My suggestion was to have the script adjust the commit message when
it found something amiss (like a PR in the subject but not in
the ChangeLog entry that prompted this thread, or leading spaces
rather than tabs, missing test files, etc.), instead of rejecting
it and making the user fix it.  Jonathan explained that (IIUC)
changing the commit message by the commit hook on the server side
would result in a different commit hash and that the idea would
only work by running a pre-commit script on the client side.
Until we have such a script rejecting these simple mistakes appears
to be the best we can do.  (Barring more radical approaches like
completely automating the ChangeLog file maintenance or getting
rid of it).

Martin

[RISCV][CANCELLED] RISC-V GNU Toolchain Biweekly Sync-up call (June 17, 2021)

[吴伟]

Hi all,

We will skip tomorrow's RISC-V GNU Biweekly meeting. Not so many
topics were collected. No big progress on CI in the past two weeks, for
I was preparing for the upcoming RISC-V World Conference China 2021
(RVWC2021). Hopefully I will have more time on CI after June 27.


-- 
Best wishes,
Wei Wu (吴伟)

GCC trunk commit a325bdd195ee96f826b208c3afb9bed2ec077e12

[Peter Bergner via Gcc]

Hi all,

I recently did a search on a git log of gcc trunk looking for a particular
commit of mine, so was searching for my name, and I came across a commit
from Uroš that lists me as the Author.  I did not author that commit and
talking with Uroš offline, he assures me that he didn't use --author when
committing that, so we're wondering whether there might be a bug in one
of the commit hooks.  Is there someone who an dig into the commit below
and try to find out how the author field was incorrectly set?

Peter


commit a325bdd195ee96f826b208c3afb9bed2ec077e12
Author: Peter Bergner 
AuthorDate: Thu Jun 10 13:54:12 2021 -0500
Commit: Uros Bizjak 
CommitDate: Thu Jun 10 23:55:24 2021 +0200

i386: Add V8QI and other 64bit vector permutations [PR89021]

In addition to V8QI permutations, several other missing permutations are
added for 64bit vector modes for TARGET_SSSE3 and TARGET_SSE4_1 targets.

2021-06-10  Uroš Bizjak  

gcc/
PR target/89021
* config/i386/i386-expand.c (ix86_split_mmx_punpck):
Handle V2SF mode.  Emit SHUFPS to fixup unpack-high for V2SF mode.
(expand_vec_perm_blend): Handle 64bit modes for TARGET_SSE4_1.
(expand_vec_perm_pshufb): Handle 64bit modes for TARGET_SSSE3.
(expand_vec_perm_pblendv): Handle 64bit modes for TARGET_SSE4_1.
(expand_vec_perm_interleave2): Handle 64bit modes.
(expand_vec_perm_even_odd_pack): Handle V8QI mode.
(expand_vec_perm_even_odd_1): Ditto.
(ix86_vectorize_vec_perm_const): Ditto.
* config/i386/i386.md (UNSPEC_PSHUFB): Move from ...
* config/i386/sse.md: ... here.
* config/i386/mmx.md (*vec_interleave_lowv2sf):
New insn_and_split pattern.
(*vec_interleave_highv2sf): Ditto.
(mmx_pshufbv8qi3): New insn pattern.
(*mmx_pblendw): Ditto.

Re: GCC trunk commit a325bdd195ee96f826b208c3afb9bed2ec077e12

[Jonathan Wakely via Gcc]

>Is there someone who an dig into the commit below
>and try to find out how the author field was incorrectly set?

That gets set when the local commit is done, before pushing it to the
server. I don't think there's any way to find out how/why that
happened after the fact.

You did author the commit before the commit before that one, and they
have identical author dates:


$ git log --pretty=format:'commit %H%nAuthor: %an <%ae>%nAuthorDate: 
%ad%nCommitter:  %cn <%ce>%nCommitDate: %cd%n%n%s%n%n' -3  
a325bdd195ee96f826b208c3afb9bed2ec077e12
commit a325bdd195ee96f826b208c3afb9bed2ec077e12
Author: Peter Bergner 
AuthorDate: Thu Jun 10 19:54:12 2021
Committer:  Uros Bizjak 
CommitDate: Thu Jun 10 22:55:24 2021

i386: Add V8QI and other 64bit vector permutations [PR89021]


commit ee52bf609bac45b3c251858a69071262f46ee89c
Author: Ian Lance Taylor 
AuthorDate: Thu Jun 10 20:37:34 2021
Committer:  Ian Lance Taylor 
CommitDate: Thu Jun 10 22:41:23 2021

libgo: update to Go1.16.5 release


commit 00d07ec6e12451acc7a290cd93be03bed50cb666
Author: Peter Bergner 
AuthorDate: Thu Jun 10 19:54:12 2021
Committer:  Peter Bergner 
CommitDate: Thu Jun 10 19:56:27 2021

rs6000: Add new __builtin_vsx_build_pair and __builtin_mma_build_acc 
built-ins


So maybe Uroš did a git reset or rebase or something which somehow
modified the previous commit, retaining its author info, instead of
creating a brand new commit?

Uroš, does your 'git reflog' show anything around those commits?

git reflog | grep -C 3 -E '^(00d07ec6e124|a325bdd195ee9)'

Re: GCC trunk commit a325bdd195ee96f826b208c3afb9bed2ec077e12

[Liu Hao via Gcc]

在 2021-06-16 23:22, Jonathan Wakely via Gcc 写道:

Is there someone who an dig into the commit below
and try to find out how the author field was incorrectly set?


That gets set when the local commit is done, before pushing it to the
server. I don't think there's any way to find out how/why that
happened after the fact.

You did author the commit before the commit before that one, and they
have identical author dates:



It looks like Uroš was on 00d07ec6e12, committed his changes mistakenly with `git commit --amend` 
(which changed the commit message but did not reset the author), then rebased the modified commit 
onto ee52bf609bac. Git is smart enough to drop duplicate changes, but the leftovers formed a new 
commit, which was exactly a325bdd195e.




--
Best regards,
Liu Hao





OpenPGP_signature
Description: OpenPGP digital signature

Re: Build failure due to format-truncation

[Martin Sebor via Gcc]

On 6/13/21 11:48 AM, José Rui Faustino de Sousa via Gcc wrote:


Hi All!

While building I started to get this error:

../../gcc-master/gcc/opts.c: In function ‘void 
print_filtered_help(unsigned int, unsigned int, unsigned int, unsigned 
int, gcc_options*, unsigned int)’:
../../gcc-master/gcc/opts.c:1497:26: error: ‘  ’ directive output may be 
truncated writing 2 bytes into a region of size between 1 and 256 
[-Werror=format-truncation=]

  1497 |   "%s  %s", help, _(use_diagnosed_msg));
   |  ^~
../../gcc-master/gcc/opts.c:1496:22: note: ‘snprintf’ output 3 or more 
bytes (assuming 258) into a destination of size 256

  1496 | snprintf (new_help, sizeof new_help,
   | ~^~~
  1497 |   "%s  %s", help, _(use_diagnosed_msg));
   |   ~
cc1plus: all warnings being treated as errors

My guess is that it is due to the use of the flag "-fstrict-overflow"

I am not complaining or saying that this is a bug, but the whole code 
compiles fine with this flag except for this single instance...


-fstrict-overflow isn't related to the warning or to sprintf (it
controls whether signed integer overflow is considered undefined).

The warning above tells you that if help points to a string that's
255 characters long the snprintf output will be truncated.  This
warning is only issued at level 2 (-Wformat-truncation=2) which
points out more instances of possible truncation than the more
conservative level 1.

Martin



Thank you very much.

Best regards,
José Rui

Re: docs: Unification of "enabled by default at -O{,1}

[Martin Sebor via Gcc]

On 6/11/21 6:53 AM, Martin Liška wrote:

Hello.

First, note that -O is equal to -O1 :) I noticed we don't use it 
consistently

in documentation:

$ git grep 'at.*-O1}' | cat

gcc/ada/gnat_ugn.texi:pick it based on the optimization level: 1 for 
@code{-O1}, @code{-O2} or



...

Is the later (and more common variant) preferred?


I think -O1 should be preferred wherever the manual means to refer
to -O1.  It's clearer that way mainly because other compilers have
different meanings for -O than GCC (e.g., in IBM XLC it corresponds
to -O2 and in Oracle C it's equivalent to level 3).

This is in line with the POSIX description of the c99 command which
leaves the -O level unspecified if none is provided.

Martin

Re: Build failure due to format-truncation

[José Rui Faustino de Sousa via Gcc]

On 16/06/21 16:53, Martin Sebor wrote:

-fstrict-overflow isn't related to the warning or to sprintf (it
controls whether signed integer overflow is considered undefined).

The warning above tells you that if help points to a string that's
255 characters long the snprintf output will be truncated.  This
warning is only issued at level 2 (-Wformat-truncation=2) which
points out more instances of possible truncation than the more
conservative level 1.



These are the flags I use to build gcc:

-O0 -g3 -ggdb3 -gdwarf-4 -fvar-tracking-assignments 
-fno-omit-frame-pointer -fstrict-overflow -fstack-check


I have been using these flags for more than a year now, it just started 
failing recently.


Maybe this is due to some other, deeper, issue?

Thank you very much.

Best regards,
José Rui

P.S.- from config.log:

  $ ../gcc-local/configure --prefix=/opt/gcc/gcc-local --enable-debug 
--enable-checking --enable-valgrind-annotations --disable-multilib 
CFLAGS= -O0 -g3 -ggdb3 -gdwarf-4 -fvar-tracking-assignments 
-fno-omit-frame-pointer -fstrict-overflow -fstack-check   CXXFLAGS= -O0 
-g3 -ggdb3 -gdwarf-4 -fvar-tracking-assignments -fno-omit-frame-pointer 
-fstrict-overflow -fstack-check   --enable-languages=c,c++,fortran,lto 
--no-create --no-recursion

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Hans-Peter Nilsson]

On Tue, 15 Jun 2021, Martin Sebor wrote:
> On 6/15/21 6:56 PM, Hans-Peter Nilsson wrote:
> > On Fri, 11 Jun 2021, Martin Sebor via Gcc wrote:
> >
> > > On 6/11/21 11:32 AM, Jonathan Wakely wrote:
> > > > On Fri, 11 Jun 2021 at 18:02, Martin Sebor wrote:
> > > > > My objection is to making our policies and tools more restrictive
> > > > > than they need to be.  We shouldn't expect everyone to study whole
> > > > > manuals just to figure out how to successfully commit a change (or
> > > > > learn how to format it just the right way).  It should be easy.
> > > >
> > > > I agree, to some extent. But consistency is also good. The conventions
> > > > for GNU ChangeLog formatting exist for a reason, and so do the
> > > > conventions for good Git commit messages.
> > > >
> > > > > Setting this discussion aside for a moment and using a different
> > > > > example, the commit hook rejects commit messages that don't start
> > > > > ChangeLog entries with tabs.  It also rejects commit messages that
> > > > > don't list all the same test files as those changed by the commit
> > > > > (and probably some others as well).  That's in my view unnecessary
> > > > > when the hook could just replace the leading spaces with tabs and
> > > >
> > > > You cannot "fix things up" in a server-side receive hook, because
> > > > changing the commit message would alter the commit hash, which would
> > > > require the committer to do a rebase to proceed. That breaks the
> > > > expected behaviour and workflow of a git repo.
> > > >
> > > > You can use the scripts on the client side to verify your commit
> > > > message before pushing, so you don't have to be surprised when the
> > > > server rejects it.
> > >
> > > That sounds like a killer argument.  Do we have shared client-side
> > > scripts that could fix things up for us, or are we each on our own
> > > to write them?
> >
> > > > > automatically mention all the tests.
> > > > >
> > > > > I see this proposal as heading in the same direction.  Rather than
> > > > > making the script fix things up if we get them wrong it would reject
> > > > > the commit, requiring the user to massage the ChangeLog by hand into
> > > > > an unnecessarily rigid format.

> > I hope I got your view wrong.  If not: the "scripts fixing
> > things up for us" direction is flawed (compared to the "scripts
> > rejecting bad formats"), unless offered as a non-default option;
> > please don't proceed.
> >
> > Why?  For one, there'll always be bugs in the scripting.
> > Mitigate those situations: while wrongly rejecting a commit is
> > bad, wrongly "fixing things up" is worse, as a general rule.
> > Better avoid that.  (There's probably a popular "pattern name"
> > for what I try to describe.)
>
> The word that comes to mind is Technophobia.  Is it wise to trust
> compilers to transform programs from their source form into
> executables?  What if there are bugs in either?  What about the OS?
> The whole computer, or the Internet?  Our cars?  Fortunately, there's
> more to gain than to lose by trusting automation.  If there weren't
> human progress would be stuck sometime in the 1700's.
>
> But we're not talking about anything anywhere that sophisticated
> here: a sed script to copy and paste a piece of text in
> the description of a change from one place to another.  It's been
> done a few times before with more important data than ChangeLogs.

Your hyperbole would be funnier if it wasn't too much over the
top.  Criticizing the suggested approach for suffering from a
technical fallacy ("outsmarting the user") isn't technophobia.
Keep it in the helper scripts, don't put it in a commit hook.

brgds, H-P

Re: GCC trunk commit a325bdd195ee96f826b208c3afb9bed2ec077e12

[Uros Bizjak via Gcc]

On Wed, Jun 16, 2021 at 6:08 PM Liu Hao  wrote:
>
> 在 2021-06-16 23:22, Jonathan Wakely via Gcc 写道:
> >> Is there someone who an dig into the commit below
> >> and try to find out how the author field was incorrectly set?
> >
> > That gets set when the local commit is done, before pushing it to the
> > server. I don't think there's any way to find out how/why that
> > happened after the fact.
> >
> > You did author the commit before the commit before that one, and they
> > have identical author dates:
> >
>
> It looks like Uroš was on 00d07ec6e12, committed his changes mistakenly with 
> `git commit --amend`
> (which changed the commit message but did not reset the author), then rebased 
> the modified commit
> onto ee52bf609bac. Git is smart enough to drop duplicate changes, but the 
> leftovers formed a new
> commit, which was exactly a325bdd195e.

Indeed, IIRC - contrib/gcc_update failed due to the unresolved merge,
and I changed my commit with --amend. There were some issues, but I
was under the impression that I fixed them. It looks like I forgot
something, so the result is the commit with wrong author attribution.

Perhaps a notice in the documentation should be added what to do if
contrib/gcc_update fails, or perhaps this script should be made more
robust.

Sorry for the unintended inconvenience,
Uros.

Re: GCC trunk commit a325bdd195ee96f826b208c3afb9bed2ec077e12

[Peter Bergner via Gcc]

On 6/16/21 1:32 PM, Uros Bizjak wrote:
> On Wed, Jun 16, 2021 at 6:08 PM Liu Hao  wrote:
>> It looks like Uroš was on 00d07ec6e12, committed his changes mistakenly with 
>> `git commit --amend`
>> (which changed the commit message but did not reset the author), then 
>> rebased the modified commit
>> onto ee52bf609bac. Git is smart enough to drop duplicate changes, but the 
>> leftovers formed a new
>> commit, which was exactly a325bdd195e.
> 
> Indeed, IIRC - contrib/gcc_update failed due to the unresolved merge,
> and I changed my commit with --amend. There were some issues, but I
> was under the impression that I fixed them. It looks like I forgot
> something, so the result is the commit with wrong author attribution.
> 
> Perhaps a notice in the documentation should be added what to do if
> contrib/gcc_update fails, or perhaps this script should be made more
> robust.

I admit, that if the same thing happened to me, I would have made the
same mistake...or worse :-), so yeah, a comment about what to do to "fix"
things when gcc_update fails would be greatly appreciated by me too!

Peter

Re: Build failure due to format-truncation

[Martin Sebor via Gcc]

On 6/16/21 11:21 AM, José Rui Faustino de Sousa wrote:

On 16/06/21 16:53, Martin Sebor wrote:

-fstrict-overflow isn't related to the warning or to sprintf (it
controls whether signed integer overflow is considered undefined).

The warning above tells you that if help points to a string that's
255 characters long the snprintf output will be truncated.  This
warning is only issued at level 2 (-Wformat-truncation=2) which
points out more instances of possible truncation than the more
conservative level 1.



These are the flags I use to build gcc:

-O0 -g3 -ggdb3 -gdwarf-4 -fvar-tracking-assignments 
-fno-omit-frame-pointer -fstrict-overflow -fstack-check


I have been using these flags for more than a year now, it just started 
failing recently.


Maybe this is due to some other, deeper, issue?


The early sprintf warning pass has been moved recently to run after
the IL has been converted to the SSA form which lets it follow more
logic.  But because few optimizations have been done on the IL at
that point it also results in different warnings than when it runs
later.  In this case, the difference is that the pass now sees a PHI
where before it saw a VAR_DECL and the logic between the two is just
different enough that it makes a difference to the heuristics used
to enable vs disable it.  I don't really think the warning is doing
anything wrong, it just works with limited view of the code at -O0.
Perhaps it might be worth turning off the "maybe" kind of warnings
when optimization is disabled to reduce noise.  Here's a test case
that shows another difference between GCC 11 and trunk (although
this one warns consistently with -O0 and -O2 as well so that's
an improvement):

  char a[7], d[8], *p;

  void f (int i)
  {
const char *s = i ? a : p;
__builtin_snprintf (d, sizeof d, "%s x", s);   // trunk warns
  }

Martin



Thank you very much.

Best regards,
José Rui

P.S.- from config.log:

   $ ../gcc-local/configure --prefix=/opt/gcc/gcc-local --enable-debug 
--enable-checking --enable-valgrind-annotations --disable-multilib 
CFLAGS= -O0 -g3 -ggdb3 -gdwarf-4 -fvar-tracking-assignments 
-fno-omit-frame-pointer -fstrict-overflow -fstack-check   CXXFLAGS= -O0 
-g3 -ggdb3 -gdwarf-4 -fvar-tracking-assignments -fno-omit-frame-pointer 
-fstrict-overflow -fstack-check   --enable-languages=c,c++,fortran,lto 
--no-create --no-recursion

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Jason Merrill via Gcc]

On 6/15/21 11:42 PM, Jason Merrill wrote:
On Tue, Jun 15, 2021 at 10:04 PM Martin Sebor via Gcc > wrote:


On 6/15/21 6:56 PM, Hans-Peter Nilsson wrote:
 > On Fri, 11 Jun 2021, Martin Sebor via Gcc wrote:
 >
 >> On 6/11/21 11:32 AM, Jonathan Wakely wrote:
 >>> On Fri, 11 Jun 2021 at 18:02, Martin Sebor wrote:
  My objection is to making our policies and tools more restrictive
  than they need to be.  We shouldn't expect everyone to study whole
  manuals just to figure out how to successfully commit a change (or
  learn how to format it just the right way).  It should be easy.
 >>>
 >>> I agree, to some extent. But consistency is also good. The
conventions
 >>> for GNU ChangeLog formatting exist for a reason, and so do the
 >>> conventions for good Git commit messages.
 >>>
  Setting this discussion aside for a moment and using a different
  example, the commit hook rejects commit messages that don't start
  ChangeLog entries with tabs.  It also rejects commit messages that
  don't list all the same test files as those changed by the commit
  (and probably some others as well).  That's in my view unnecessary
  when the hook could just replace the leading spaces with tabs and
  automatically mention all the tests.
 
  I see this proposal as heading in the same direction.  Rather than
  making the script fix things up if we get them wrong it would
reject
  the commit, requiring the user to massage the ChangeLog by
hand into
  an unnecessarily rigid format.
 >>>
 >>> You cannot "fix things up" in a server-side receive hook, because
 >>> changing the commit message would alter the commit hash, which
would
 >>> require the committer to do a rebase to proceed. That breaks the
 >>> expected behaviour and workflow of a git repo.
 >>>
 >>> You can use the scripts on the client side to verify your commit
 >>> message before pushing, so you don't have to be surprised when the
 >>> server rejects it.
 >>
 >> That sounds like a killer argument.  Do we have shared client-side
 >> scripts that could fix things up for us, or are we each on our own
 >> to write them?
 >
 > I hope I got your view wrong.  If not: the "scripts fixing
 > things up for us" direction is flawed (compared to the "scripts
 > rejecting bad formats"), unless offered as a non-default option;
 > please don't proceed.
 >
 > Why?  For one, there'll always be bugs in the scripting.
 > Mitigate those situations: while wrongly rejecting a commit is
 > bad, wrongly "fixing things up" is worse, as a general rule.
 > Better avoid that.  (There's probably a popular "pattern name"
 > for what I try to describe.)

The word that comes to mind is Technophobia.  Is it wise to trust
compilers to transform programs from their source form into
executables?  What if there are bugs in either?  What about the OS?
The whole computer, or the Internet?  Our cars?  Fortunately, there's
more to gain than to lose by trusting automation.  If there weren't
human progress would be stuck sometime in the 1700's.

But we're not talking about anything anywhere that sophisticated
here: a sed script to copy and paste a piece of text in
the description of a change from one place to another.  It's been
done a few times before with more important data than ChangeLogs.


git gcc-commit-mklog already automates most of the process.  It could 
also automate adding [PRx] to the first line.  Is that what you're 
asking for?


Like, say:
>From a4e1c5eef3491e3d2e72a01e864af204f124a994 Mon Sep 17 00:00:00 2001
From: Jason Merrill 
Date: Wed, 16 Jun 2021 16:46:38 -0400
Subject: [PATCH] mklog: add subject line skeleton
To: gcc-patc...@gcc.gnu.org

contrib/ChangeLog:

	* mklog.py: Add an initial component: [PRn] line when
	we have a PR.
---
 contrib/mklog.py | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/contrib/mklog.py b/contrib/mklog.py
index 5c93c707128..6113ae30a8e 100755
--- a/contrib/mklog.py
+++ b/contrib/mklog.py
@@ -39,6 +39,7 @@ import requests
 from unidiff import PatchSet
 
 pr_regex = re.compile(r'(\/(\/|\*)|[Cc*!])\s+(?PPR [a-z+-]+\/[0-9]+)')
+prnum_regex = re.compile(r'PR (?P[a-z+-]+)/(?P[0-9]+)')
 dr_regex = re.compile(r'(\/(\/|\*)|[Cc*!])\s+(?PDR [0-9]+)')
 dg_regex = re.compile(r'{\s+dg-(error|warning)')
 identifier_regex = re.compile(r'^([a-zA-Z0-9_#].*)')
@@ -67,6 +68,7 @@ PATCH must be generated using diff(1)'s -up or -cp options
 script_folder = os.path.realpath(__file__)
 root = os.path.dirname(os.path.dirname(script_folder))
 
+firstpr = ''
 
 def find_changelog(path):
 folder = os.path.split(path)[0]
@@ -134,6 +136,7 @@ def generate_changelog(data, no_functions=False, fill_pr_titles=False):

The official glibc IRC channel is now on OFTC as #glibc.

[Carlos O'Donell via Gcc]

Community,

The official glibc IRC channel is now on OFTC as #glibc.

gcc developers, please feel free to visit #glibc :-)

We also have an unofficial IRC channel #glibc on Libera.Chat

-- 
Cheers,
Carlos.

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Martin Sebor via Gcc]

On 6/16/21 2:49 PM, Jason Merrill wrote:

On 6/15/21 11:42 PM, Jason Merrill wrote:
On Tue, Jun 15, 2021 at 10:04 PM Martin Sebor via Gcc > wrote:


    On 6/15/21 6:56 PM, Hans-Peter Nilsson wrote:
 > On Fri, 11 Jun 2021, Martin Sebor via Gcc wrote:
 >
 >> On 6/11/21 11:32 AM, Jonathan Wakely wrote:
 >>> On Fri, 11 Jun 2021 at 18:02, Martin Sebor wrote:
  My objection is to making our policies and tools more 
restrictive
  than they need to be.  We shouldn't expect everyone to study 
whole
  manuals just to figure out how to successfully commit a 
change (or

  learn how to format it just the right way).  It should be easy.
 >>>
 >>> I agree, to some extent. But consistency is also good. The
    conventions
 >>> for GNU ChangeLog formatting exist for a reason, and so do the
 >>> conventions for good Git commit messages.
 >>>
  Setting this discussion aside for a moment and using a 
different
  example, the commit hook rejects commit messages that don't 
start
  ChangeLog entries with tabs.  It also rejects commit 
messages that
  don't list all the same test files as those changed by the 
commit
  (and probably some others as well).  That's in my view 
unnecessary
  when the hook could just replace the leading spaces with 
tabs and

  automatically mention all the tests.
 
  I see this proposal as heading in the same direction.  
Rather than

  making the script fix things up if we get them wrong it would
    reject
  the commit, requiring the user to massage the ChangeLog by
    hand into
  an unnecessarily rigid format.
 >>>
 >>> You cannot "fix things up" in a server-side receive hook, 
because

 >>> changing the commit message would alter the commit hash, which
    would
 >>> require the committer to do a rebase to proceed. That breaks the
 >>> expected behaviour and workflow of a git repo.
 >>>
 >>> You can use the scripts on the client side to verify your commit
 >>> message before pushing, so you don't have to be surprised 
when the

 >>> server rejects it.
 >>
 >> That sounds like a killer argument.  Do we have shared 
client-side
 >> scripts that could fix things up for us, or are we each on our 
own

 >> to write them?
 >
 > I hope I got your view wrong.  If not: the "scripts fixing
 > things up for us" direction is flawed (compared to the "scripts
 > rejecting bad formats"), unless offered as a non-default option;
 > please don't proceed.
 >
 > Why?  For one, there'll always be bugs in the scripting.
 > Mitigate those situations: while wrongly rejecting a commit is
 > bad, wrongly "fixing things up" is worse, as a general rule.
 > Better avoid that.  (There's probably a popular "pattern name"
 > for what I try to describe.)

    The word that comes to mind is Technophobia.  Is it wise to trust
    compilers to transform programs from their source form into
    executables?  What if there are bugs in either?  What about the OS?
    The whole computer, or the Internet?  Our cars?  Fortunately, there's
    more to gain than to lose by trusting automation.  If there weren't
    human progress would be stuck sometime in the 1700's.

    But we're not talking about anything anywhere that sophisticated
    here: a sed script to copy and paste a piece of text in
    the description of a change from one place to another.  It's been
    done a few times before with more important data than ChangeLogs.


git gcc-commit-mklog already automates most of the process.  It could 
also automate adding [PRx] to the first line.  Is that what you're 
asking for?


Like, say:


I don't think this solves the problem Xionghu Luo was asking about:
  https://gcc.gnu.org/pipermail/gcc/2021-June/236346.html
i.e., they did have a [PR] in the one line subject but not in
their ChangeLog entries.  It also not clear if they used mklog.py
at all.  IME, mklog.py already puts in a [PR] near the top of
a patch if it finds in one of the tests.  Though it doesn't seem
to put in the ChangeLog entries.  Odd.

I was suggesting to make this (and the other things the commit
hook rejects commit for) happen automatically by running a script
at the same time as git commit.

But to be clear, I'm not asking for anything for myself.  Although
I use mklog.py I have my own script that does what I suggest that
I could go back to.  I responded to this thread because I think
these minute details could be automated for everyone's benefit.
Before moving to Git we talked about doing much more, including
automatically running a format/style checker on the patch and
(IIRC) Jeff even wanted it to do some basic tweaks on its own
(like replace spaces with tabs).

Martin

Aldy Hernandez and Andrew MacLeod as VRP maintainers

[Jeff Law via Gcc]

I am pleased to announce that the GCC Steering Committee has appointed 
Aldy Hernandez and Ian MacLeod as maintainers for the VRP subsystem 
(EVRP, VRP, Ranger).


Aldy/Andrew, please update the MAINTAINERS file appropriately.

Thanks,
jeff

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Jason Merrill via Gcc]

On Wed, Jun 16, 2021 at 5:46 PM Martin Sebor  wrote:

> On 6/16/21 2:49 PM, Jason Merrill wrote:
> > On 6/15/21 11:42 PM, Jason Merrill wrote:
> >> On Tue, Jun 15, 2021 at 10:04 PM Martin Sebor via Gcc  >> > wrote:
> >>
> >> On 6/15/21 6:56 PM, Hans-Peter Nilsson wrote:
> >>  > On Fri, 11 Jun 2021, Martin Sebor via Gcc wrote:
> >>  >
> >>  >> On 6/11/21 11:32 AM, Jonathan Wakely wrote:
> >>  >>> On Fri, 11 Jun 2021 at 18:02, Martin Sebor wrote:
> >>   My objection is to making our policies and tools more
> >> restrictive
> >>   than they need to be.  We shouldn't expect everyone to study
> >> whole
> >>   manuals just to figure out how to successfully commit a
> >> change (or
> >>   learn how to format it just the right way).  It should be
> easy.
> >>  >>>
> >>  >>> I agree, to some extent. But consistency is also good. The
> >> conventions
> >>  >>> for GNU ChangeLog formatting exist for a reason, and so do the
> >>  >>> conventions for good Git commit messages.
> >>  >>>
> >>   Setting this discussion aside for a moment and using a
> >> different
> >>   example, the commit hook rejects commit messages that don't
> >> start
> >>   ChangeLog entries with tabs.  It also rejects commit
> >> messages that
> >>   don't list all the same test files as those changed by the
> >> commit
> >>   (and probably some others as well).  That's in my view
> >> unnecessary
> >>   when the hook could just replace the leading spaces with
> >> tabs and
> >>   automatically mention all the tests.
> >>  
> >>   I see this proposal as heading in the same direction.
> >> Rather than
> >>   making the script fix things up if we get them wrong it would
> >> reject
> >>   the commit, requiring the user to massage the ChangeLog by
> >> hand into
> >>   an unnecessarily rigid format.
> >>  >>>
> >>  >>> You cannot "fix things up" in a server-side receive hook,
> >> because
> >>  >>> changing the commit message would alter the commit hash, which
> >> would
> >>  >>> require the committer to do a rebase to proceed. That breaks
> the
> >>  >>> expected behaviour and workflow of a git repo.
> >>  >>>
> >>  >>> You can use the scripts on the client side to verify your
> commit
> >>  >>> message before pushing, so you don't have to be surprised
> >> when the
> >>  >>> server rejects it.
> >>  >>
> >>  >> That sounds like a killer argument.  Do we have shared
> >> client-side
> >>  >> scripts that could fix things up for us, or are we each on our
> >> own
> >>  >> to write them?
> >>  >
> >>  > I hope I got your view wrong.  If not: the "scripts fixing
> >>  > things up for us" direction is flawed (compared to the "scripts
> >>  > rejecting bad formats"), unless offered as a non-default option;
> >>  > please don't proceed.
> >>  >
> >>  > Why?  For one, there'll always be bugs in the scripting.
> >>  > Mitigate those situations: while wrongly rejecting a commit is
> >>  > bad, wrongly "fixing things up" is worse, as a general rule.
> >>  > Better avoid that.  (There's probably a popular "pattern name"
> >>  > for what I try to describe.)
> >>
> >> The word that comes to mind is Technophobia.  Is it wise to trust
> >> compilers to transform programs from their source form into
> >> executables?  What if there are bugs in either?  What about the OS?
> >> The whole computer, or the Internet?  Our cars?  Fortunately,
> there's
> >> more to gain than to lose by trusting automation.  If there weren't
> >> human progress would be stuck sometime in the 1700's.
> >>
> >> But we're not talking about anything anywhere that sophisticated
> >> here: a sed script to copy and paste a piece of text in
> >> the description of a change from one place to another.  It's been
> >> done a few times before with more important data than ChangeLogs.
> >>
> >>
> >> git gcc-commit-mklog already automates most of the process.  It could
> >> also automate adding [PRx] to the first line.  Is that what you're
> >> asking for?
> >
> > Like, say:
>
> I don't think this solves the problem Xionghu Luo was asking about:
>https://gcc.gnu.org/pipermail/gcc/2021-June/236346.html


Indeed, their problem was not mentioning the PR in the testcase, which a
script isn't going to fix.

i.e., they did have a [PR] in the one line subject but not in
> their ChangeLog entries.  It also not clear if they used mklog.py
> at all.  IME, mklog.py already puts in a [PR] near the top of
> a patch if it finds in one of the tests.  Though it doesn't seem
> to put in the ChangeLog entries.  Odd.
>

It currently puts in

 PR comp/n

at the beginning of the ChangeLog entries; it used to put them in the
entries for each ChangeLog file, but tha

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Martin Sebor via Gcc]

On 6/16/21 5:45 PM, Jason Merrill wrote:
On Wed, Jun 16, 2021 at 5:46 PM Martin Sebor > wrote:


On 6/16/21 2:49 PM, Jason Merrill wrote:
 > On 6/15/21 11:42 PM, Jason Merrill wrote:
 >> On Tue, Jun 15, 2021 at 10:04 PM Martin Sebor via Gcc
mailto:gcc@gcc.gnu.org>
 >> >> wrote:
 >>
 >>     On 6/15/21 6:56 PM, Hans-Peter Nilsson wrote:
 >>  > On Fri, 11 Jun 2021, Martin Sebor via Gcc wrote:
 >>  >
 >>  >> On 6/11/21 11:32 AM, Jonathan Wakely wrote:
 >>  >>> On Fri, 11 Jun 2021 at 18:02, Martin Sebor wrote:
 >>   My objection is to making our policies and tools more
 >> restrictive
 >>   than they need to be.  We shouldn't expect everyone to
study
 >> whole
 >>   manuals just to figure out how to successfully commit a
 >> change (or
 >>   learn how to format it just the right way).  It should
be easy.
 >>  >>>
 >>  >>> I agree, to some extent. But consistency is also good. The
 >>     conventions
 >>  >>> for GNU ChangeLog formatting exist for a reason, and so
do the
 >>  >>> conventions for good Git commit messages.
 >>  >>>
 >>   Setting this discussion aside for a moment and using a
 >> different
 >>   example, the commit hook rejects commit messages that
don't
 >> start
 >>   ChangeLog entries with tabs.  It also rejects commit
 >> messages that
 >>   don't list all the same test files as those changed by
the
 >> commit
 >>   (and probably some others as well).  That's in my view
 >> unnecessary
 >>   when the hook could just replace the leading spaces with
 >> tabs and
 >>   automatically mention all the tests.
 >>  
 >>   I see this proposal as heading in the same direction.
 >> Rather than
 >>   making the script fix things up if we get them wrong
it would
 >>     reject
 >>   the commit, requiring the user to massage the ChangeLog by
 >>     hand into
 >>   an unnecessarily rigid format.
 >>  >>>
 >>  >>> You cannot "fix things up" in a server-side receive hook,
 >> because
 >>  >>> changing the commit message would alter the commit
hash, which
 >>     would
 >>  >>> require the committer to do a rebase to proceed. That
breaks the
 >>  >>> expected behaviour and workflow of a git repo.
 >>  >>>
 >>  >>> You can use the scripts on the client side to verify
your commit
 >>  >>> message before pushing, so you don't have to be surprised
 >> when the
 >>  >>> server rejects it.
 >>  >>
 >>  >> That sounds like a killer argument.  Do we have shared
 >> client-side
 >>  >> scripts that could fix things up for us, or are we each
on our
 >> own
 >>  >> to write them?
 >>  >
 >>  > I hope I got your view wrong.  If not: the "scripts fixing
 >>  > things up for us" direction is flawed (compared to the
"scripts
 >>  > rejecting bad formats"), unless offered as a non-default
option;
 >>  > please don't proceed.
 >>  >
 >>  > Why?  For one, there'll always be bugs in the scripting.
 >>  > Mitigate those situations: while wrongly rejecting a
commit is
 >>  > bad, wrongly "fixing things up" is worse, as a general rule.
 >>  > Better avoid that.  (There's probably a popular "pattern
name"
 >>  > for what I try to describe.)
 >>
 >>     The word that comes to mind is Technophobia.  Is it wise to
trust
 >>     compilers to transform programs from their source form into
 >>     executables?  What if there are bugs in either?  What about
the OS?
 >>     The whole computer, or the Internet?  Our cars? 
Fortunately, there's

 >>     more to gain than to lose by trusting automation.  If there
weren't
 >>     human progress would be stuck sometime in the 1700's.
 >>
 >>     But we're not talking about anything anywhere that sophisticated
 >>     here: a sed script to copy and paste a piece of text in
 >>     the description of a change from one place to another.  It's
been
 >>     done a few times before with more important data than
ChangeLogs.
 >>
 >>
 >> git gcc-commit-mklog already automates most of the process.  It
could
 >> also automate adding [PRx] to the first line.  Is that what
you're
 >> asking for?
 >
 > Like, say:

I don't think this solves the problem Xionghu Luo was asking about:
https://gcc.gnu.org/pipermail/gcc/2021-June/236346.html


Indeed, their problem was not mentioning the PR in the testcase, which a 
script is

Re: Build failure due to format-truncation

[José Rui Faustino de Sousa via Gcc]

On 16/06/21 20:37, Martin Sebor wrote:

I don't really think the warning is doing
anything wrong



I completely agree. I am not complaining about the warning, I am 
complaining that there is code in gcc which raises this warning and 
breaks the build.


I was assuming that this was being triggered by some option that I was 
using but, on further investigation, the -Wformat-truncation flag is 
being set by -Wall which AFAICT is set by the build process itself...


So this is starting to look like something that really should be 
fixed... What bugs me is why it seems that I was the only one who noticed...


Thank you very much.

Best regards,
José Rui

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Jason Merrill via Gcc]

On 6/16/21 8:17 PM, Martin Sebor wrote:

On 6/16/21 5:45 PM, Jason Merrill wrote:
On Wed, Jun 16, 2021 at 5:46 PM Martin Sebor > wrote:


    On 6/16/21 2:49 PM, Jason Merrill wrote:
 > On 6/15/21 11:42 PM, Jason Merrill wrote:
 >> On Tue, Jun 15, 2021 at 10:04 PM Martin Sebor via Gcc
    mailto:gcc@gcc.gnu.org>
 >> >> wrote:
 >>
 >>     On 6/15/21 6:56 PM, Hans-Peter Nilsson wrote:
 >>  > On Fri, 11 Jun 2021, Martin Sebor via Gcc wrote:
 >>  >
 >>  >> On 6/11/21 11:32 AM, Jonathan Wakely wrote:
 >>  >>> On Fri, 11 Jun 2021 at 18:02, Martin Sebor wrote:
 >>   My objection is to making our policies and tools more
 >> restrictive
 >>   than they need to be.  We shouldn't expect everyone to
    study
 >> whole
 >>   manuals just to figure out how to successfully commit a
 >> change (or
 >>   learn how to format it just the right way).  It should
    be easy.
 >>  >>>
 >>  >>> I agree, to some extent. But consistency is also 
good. The

 >>     conventions
 >>  >>> for GNU ChangeLog formatting exist for a reason, and so
    do the
 >>  >>> conventions for good Git commit messages.
 >>  >>>
 >>   Setting this discussion aside for a moment and using a
 >> different
 >>   example, the commit hook rejects commit messages that
    don't
 >> start
 >>   ChangeLog entries with tabs.  It also rejects commit
 >> messages that
 >>   don't list all the same test files as those changed by
    the
 >> commit
 >>   (and probably some others as well).  That's in my view
 >> unnecessary
 >>   when the hook could just replace the leading spaces 
with

 >> tabs and
 >>   automatically mention all the tests.
 >>  
 >>   I see this proposal as heading in the same direction.
 >> Rather than
 >>   making the script fix things up if we get them wrong
    it would
 >>     reject
 >>   the commit, requiring the user to massage the 
ChangeLog by

 >>     hand into
 >>   an unnecessarily rigid format.
 >>  >>>
 >>  >>> You cannot "fix things up" in a server-side receive 
hook,

 >> because
 >>  >>> changing the commit message would alter the commit
    hash, which
 >>     would
 >>  >>> require the committer to do a rebase to proceed. That
    breaks the
 >>  >>> expected behaviour and workflow of a git repo.
 >>  >>>
 >>  >>> You can use the scripts on the client side to verify
    your commit
 >>  >>> message before pushing, so you don't have to be 
surprised

 >> when the
 >>  >>> server rejects it.
 >>  >>
 >>  >> That sounds like a killer argument.  Do we have shared
 >> client-side
 >>  >> scripts that could fix things up for us, or are we each
    on our
 >> own
 >>  >> to write them?
 >>  >
 >>  > I hope I got your view wrong.  If not: the "scripts fixing
 >>  > things up for us" direction is flawed (compared to the
    "scripts
 >>  > rejecting bad formats"), unless offered as a non-default
    option;
 >>  > please don't proceed.
 >>  >
 >>  > Why?  For one, there'll always be bugs in the scripting.
 >>  > Mitigate those situations: while wrongly rejecting a
    commit is
 >>  > bad, wrongly "fixing things up" is worse, as a general 
rule.

 >>  > Better avoid that.  (There's probably a popular "pattern
    name"
 >>  > for what I try to describe.)
 >>
 >>     The word that comes to mind is Technophobia.  Is it wise to
    trust
 >>     compilers to transform programs from their source form into
 >>     executables?  What if there are bugs in either?  What about
    the OS?
 >>     The whole computer, or the Internet?  Our cars? 
Fortunately, there's

 >>     more to gain than to lose by trusting automation.  If there
    weren't
 >>     human progress would be stuck sometime in the 1700's.
 >>
 >>     But we're not talking about anything anywhere that 
sophisticated

 >>     here: a sed script to copy and paste a piece of text in
 >>     the description of a change from one place to another.  It's
    been
 >>     done a few times before with more important data than
    ChangeLogs.
 >>
 >>
 >> git gcc-commit-mklog already automates most of the process.  It
    could
 >> also automate adding [PRx] to the first line.  Is that what
    you're
 >> asking for?
 >
 > Like, say:

    I don't think this solves the problem Xionghu Luo was asking about:
    https://gcc.gnu.org/pipermail/gcc/2021-June/236346.html


Indeed, their problem was no

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Martin Sebor via Gcc]

On 6/16/21 6:40 PM, Jason Merrill wrote:

On 6/16/21 8:17 PM, Martin Sebor wrote:

On 6/16/21 5:45 PM, Jason Merrill wrote:
On Wed, Jun 16, 2021 at 5:46 PM Martin Sebor > wrote:


    On 6/16/21 2:49 PM, Jason Merrill wrote:
 > On 6/15/21 11:42 PM, Jason Merrill wrote:
 >> On Tue, Jun 15, 2021 at 10:04 PM Martin Sebor via Gcc
    mailto:gcc@gcc.gnu.org>
 >> >> wrote:
 >>
 >>     On 6/15/21 6:56 PM, Hans-Peter Nilsson wrote:
 >>  > On Fri, 11 Jun 2021, Martin Sebor via Gcc wrote:
 >>  >
 >>  >> On 6/11/21 11:32 AM, Jonathan Wakely wrote:
 >>  >>> On Fri, 11 Jun 2021 at 18:02, Martin Sebor wrote:
 >>   My objection is to making our policies and tools more
 >> restrictive
 >>   than they need to be.  We shouldn't expect everyone to
    study
 >> whole
 >>   manuals just to figure out how to successfully 
commit a

 >> change (or
 >>   learn how to format it just the right way).  It should
    be easy.
 >>  >>>
 >>  >>> I agree, to some extent. But consistency is also 
good. The

 >>     conventions
 >>  >>> for GNU ChangeLog formatting exist for a reason, and so
    do the
 >>  >>> conventions for good Git commit messages.
 >>  >>>
 >>   Setting this discussion aside for a moment and using a
 >> different
 >>   example, the commit hook rejects commit messages that
    don't
 >> start
 >>   ChangeLog entries with tabs.  It also rejects commit
 >> messages that
 >>   don't list all the same test files as those changed by
    the
 >> commit
 >>   (and probably some others as well).  That's in my view
 >> unnecessary
 >>   when the hook could just replace the leading spaces 
with

 >> tabs and
 >>   automatically mention all the tests.
 >>  
 >>   I see this proposal as heading in the same direction.
 >> Rather than
 >>   making the script fix things up if we get them wrong
    it would
 >>     reject
 >>   the commit, requiring the user to massage the 
ChangeLog by

 >>     hand into
 >>   an unnecessarily rigid format.
 >>  >>>
 >>  >>> You cannot "fix things up" in a server-side receive 
hook,

 >> because
 >>  >>> changing the commit message would alter the commit
    hash, which
 >>     would
 >>  >>> require the committer to do a rebase to proceed. That
    breaks the
 >>  >>> expected behaviour and workflow of a git repo.
 >>  >>>
 >>  >>> You can use the scripts on the client side to verify
    your commit
 >>  >>> message before pushing, so you don't have to be 
surprised

 >> when the
 >>  >>> server rejects it.
 >>  >>
 >>  >> That sounds like a killer argument.  Do we have shared
 >> client-side
 >>  >> scripts that could fix things up for us, or are we each
    on our
 >> own
 >>  >> to write them?
 >>  >
 >>  > I hope I got your view wrong.  If not: the "scripts 
fixing

 >>  > things up for us" direction is flawed (compared to the
    "scripts
 >>  > rejecting bad formats"), unless offered as a non-default
    option;
 >>  > please don't proceed.
 >>  >
 >>  > Why?  For one, there'll always be bugs in the scripting.
 >>  > Mitigate those situations: while wrongly rejecting a
    commit is
 >>  > bad, wrongly "fixing things up" is worse, as a general 
rule.

 >>  > Better avoid that.  (There's probably a popular "pattern
    name"
 >>  > for what I try to describe.)
 >>
 >>     The word that comes to mind is Technophobia.  Is it wise to
    trust
 >>     compilers to transform programs from their source form into
 >>     executables?  What if there are bugs in either?  What about
    the OS?
 >>     The whole computer, or the Internet?  Our cars? 
Fortunately, there's

 >>     more to gain than to lose by trusting automation.  If there
    weren't
 >>     human progress would be stuck sometime in the 1700's.
 >>
 >>     But we're not talking about anything anywhere that 
sophisticated

 >>     here: a sed script to copy and paste a piece of text in
 >>     the description of a change from one place to another.  It's
    been
 >>     done a few times before with more important data than
    ChangeLogs.
 >>
 >>
 >> git gcc-commit-mklog already automates most of the process.  It
    could
 >> also automate adding [PRx] to the first line.  Is that what
    you're
 >> asking for?
 >
 > Like, say:

    I don't think this solves the problem Xionghu Luo was asking about:
    https://gcc.gnu.org/pipermail/gcc/2021-June/

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Jason Merrill via Gcc]

On 6/16/21 9:01 PM, Martin Sebor wrote:

On 6/16/21 6:40 PM, Jason Merrill wrote:

On 6/16/21 8:17 PM, Martin Sebor wrote:

On 6/16/21 5:45 PM, Jason Merrill wrote:
On Wed, Jun 16, 2021 at 5:46 PM Martin Sebor > wrote:


    On 6/16/21 2:49 PM, Jason Merrill wrote:
 > On 6/15/21 11:42 PM, Jason Merrill wrote:
 >> On Tue, Jun 15, 2021 at 10:04 PM Martin Sebor via Gcc
    mailto:gcc@gcc.gnu.org>
 >> >> wrote:
 >>
 >>     On 6/15/21 6:56 PM, Hans-Peter Nilsson wrote:
 >>  > On Fri, 11 Jun 2021, Martin Sebor via Gcc wrote:
 >>  >
 >>  >> On 6/11/21 11:32 AM, Jonathan Wakely wrote:
 >>  >>> On Fri, 11 Jun 2021 at 18:02, Martin Sebor wrote:
 >>   My objection is to making our policies and tools more
 >> restrictive
 >>   than they need to be.  We shouldn't expect 
everyone to

    study
 >> whole
 >>   manuals just to figure out how to successfully 
commit a

 >> change (or
 >>   learn how to format it just the right way).  It 
should

    be easy.
 >>  >>>
 >>  >>> I agree, to some extent. But consistency is also 
good. The

 >>     conventions
 >>  >>> for GNU ChangeLog formatting exist for a reason, 
and so

    do the
 >>  >>> conventions for good Git commit messages.
 >>  >>>
 >>   Setting this discussion aside for a moment and 
using a

 >> different
 >>   example, the commit hook rejects commit messages that
    don't
 >> start
 >>   ChangeLog entries with tabs.  It also rejects commit
 >> messages that
 >>   don't list all the same test files as those 
changed by

    the
 >> commit
 >>   (and probably some others as well).  That's in my 
view

 >> unnecessary
 >>   when the hook could just replace the leading 
spaces with

 >> tabs and
 >>   automatically mention all the tests.
 >>  
 >>   I see this proposal as heading in the same direction.
 >> Rather than
 >>   making the script fix things up if we get them wrong
    it would
 >>     reject
 >>   the commit, requiring the user to massage the 
ChangeLog by

 >>     hand into
 >>   an unnecessarily rigid format.
 >>  >>>
 >>  >>> You cannot "fix things up" in a server-side receive 
hook,

 >> because
 >>  >>> changing the commit message would alter the commit
    hash, which
 >>     would
 >>  >>> require the committer to do a rebase to proceed. That
    breaks the
 >>  >>> expected behaviour and workflow of a git repo.
 >>  >>>
 >>  >>> You can use the scripts on the client side to verify
    your commit
 >>  >>> message before pushing, so you don't have to be 
surprised

 >> when the
 >>  >>> server rejects it.
 >>  >>
 >>  >> That sounds like a killer argument.  Do we have shared
 >> client-side
 >>  >> scripts that could fix things up for us, or are we each
    on our
 >> own
 >>  >> to write them?
 >>  >
 >>  > I hope I got your view wrong.  If not: the "scripts 
fixing

 >>  > things up for us" direction is flawed (compared to the
    "scripts
 >>  > rejecting bad formats"), unless offered as a non-default
    option;
 >>  > please don't proceed.
 >>  >
 >>  > Why?  For one, there'll always be bugs in the scripting.
 >>  > Mitigate those situations: while wrongly rejecting a
    commit is
 >>  > bad, wrongly "fixing things up" is worse, as a 
general rule.

 >>  > Better avoid that.  (There's probably a popular "pattern
    name"
 >>  > for what I try to describe.)
 >>
 >>     The word that comes to mind is Technophobia.  Is it wise to
    trust
 >>     compilers to transform programs from their source form into
 >>     executables?  What if there are bugs in either?  What about
    the OS?
 >>     The whole computer, or the Internet?  Our cars? 
Fortunately, there's

 >>     more to gain than to lose by trusting automation.  If there
    weren't
 >>     human progress would be stuck sometime in the 1700's.
 >>
 >>     But we're not talking about anything anywhere that 
sophisticated

 >>     here: a sed script to copy and paste a piece of text in
 >>     the description of a change from one place to another.  
It's

    been
 >>     done a few times before with more important data than
    ChangeLogs.
 >>
 >>
 >> git gcc-commit-mklog already automates most of the process.  It
    could
 >> also automate adding [PRx] to the first line.  Is that what
    you're
 >> asking for?
 >
 > Like, say:

    I don't think this solves the problem Xionghu Luo was asking