GCC trunk commit a325bdd195ee96f826b208c3afb9bed2ec077e12

GCC trunk commit a325bdd195ee96f826b208c3afb9bed2ec077e12

[Peter Bergner]

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 <bergner@linux.ibm.com>
AuthorDate: Thu Jun 10 13:54:12 2021 -0500
Commit:     Uros Bizjak <ubizjak@gmail.com>
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  <ubizjak@gmail.com>
    
    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]

>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 <bergner@linux.ibm.com>
AuthorDate: Thu Jun 10 19:54:12 2021
Committer:  Uros Bizjak <ubizjak@gmail.com>
CommitDate: Thu Jun 10 22:55:24 2021

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


commit ee52bf609bac45b3c251858a69071262f46ee89c
Author:     Ian Lance Taylor <iant@golang.org>
AuthorDate: Thu Jun 10 20:37:34 2021
Committer:  Ian Lance Taylor <iant@golang.org>
CommitDate: Thu Jun 10 22:41:23 2021

    libgo: update to Go1.16.5 release


commit 00d07ec6e12451acc7a290cd93be03bed50cb666
Author:     Peter Bergner <bergner@linux.ibm.com>
AuthorDate: Thu Jun 10 19:54:12 2021
Committer:  Peter Bergner <bergner@linux.ibm.com>
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]

[-- Attachment #1.1: Type: text/plain, Size: 842 bytes --]

在 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




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: GCC trunk commit a325bdd195ee96f826b208c3afb9bed2ec077e12

[Uros Bizjak]

On Wed, Jun 16, 2021 at 6:08 PM Liu Hao <lh_mouse@126.com> 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]

On 6/16/21 1:32 PM, Uros Bizjak wrote:
> On Wed, Jun 16, 2021 at 6:08 PM Liu Hao <lh_mouse@126.com> 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