[PATCH5,PR,gdb/16959] gdb hangs in infinite recursion

  The original problem was fixed (see related PR 22242). But using a typedef
as the declared type for a static member variable, as commented in this PR,
is still causing gdb to get into infinite loop when printing the static
member's value. This problem can be reproduced as follows:

% cat t.cc
class A {
    typedef A type;
public:
    bool operator==(const type& other) { return true; }

    static const type INSTANCE;
};

const A A::INSTANCE;

int main() {
    A a;
    if (a == A::INSTANCE) {
        return -1;
    }
    return 0;
}
% g++ -g t.cc
% gdb -ex "start" -ex "p a" a.out

The fix is rather trivial - in cp_print_static_field(), should call
check_typedef() to get the static member's real type and use it to
check whether it's a struct or an array.

As Simon suggested, I've added a new test case to the testsuite
and am passing the original type, not the real type, as argument
to both cp_print_value_fields() and val_print().

Re-tested on both aarch64-linux-gnu and amd64-linux-gnu. No regressions.
---
 gdb/ChangeLog                                 |    6 ++++
 gdb/cp-valprint.c                             |    6 ++--
 gdb/testsuite/ChangeLog                       |    5 +++
 gdb/testsuite/gdb.cp/static-typedef-print.cc  |   34 +++++++++++++++++++++++
 gdb/testsuite/gdb.cp/static-typedef-print.exp |   37 +++++++++++++++++++++++++
 5 files changed, 85 insertions(+), 3 deletions(-)
 create mode 100644 gdb/testsuite/gdb.cp/static-typedef-print.cc
 create mode 100644 gdb/testsuite/gdb.cp/static-typedef-print.exp
  

On 2018-03-28 16:44, Weimin Pan wrote:
> The original problem was fixed (see related PR 22242). But using a 
> typedef
> as the declared type for a static member variable, as commented in this 
> PR,
> is still causing gdb to get into infinite loop when printing the static
> member's value. This problem can be reproduced as follows:
> 
> % cat t.cc
> class A {
>     typedef A type;
> public:
>     bool operator==(const type& other) { return true; }
> 
>     static const type INSTANCE;
> };
> 
> const A A::INSTANCE;
> 
> int main() {
>     A a;
>     if (a == A::INSTANCE) {
>         return -1;
>     }
>     return 0;
> }
> % g++ -g t.cc
> % gdb -ex "start" -ex "p a" a.out
> 
> The fix is rather trivial - in cp_print_static_field(), should call
> check_typedef() to get the static member's real type and use it to
> check whether it's a struct or an array.
> 
> As Simon suggested, I've added a new test case to the testsuite
> and am passing the original type, not the real type, as argument
> to both cp_print_value_fields() and val_print().
> 
> Re-tested on both aarch64-linux-gnu and amd64-linux-gnu. No 
> regressions.

Hi Weimin,

Could you change the title to something more descriptive about what the 
change/fix is, rather than the problem being fixed?  For example, "Fix 
infinite recursion when printing static member with typedef".

It is ok to push with that fixed (feel free to ask if you still need 
some guidance).

Thanks!

Simon
  

On 3/29/2018 10:08 PM, Simon Marchi wrote:
> On 2018-03-28 16:44, Weimin Pan wrote:
>> The original problem was fixed (see related PR 22242). But using a 
>> typedef
>> as the declared type for a static member variable, as commented in 
>> this PR,
>> is still causing gdb to get into infinite loop when printing the static
>> member's value. This problem can be reproduced as follows:
>>
>> % cat t.cc
>> class A {
>>     typedef A type;
>> public:
>>     bool operator==(const type& other) { return true; }
>>
>>     static const type INSTANCE;
>> };
>>
>> const A A::INSTANCE;
>>
>> int main() {
>>     A a;
>>     if (a == A::INSTANCE) {
>>         return -1;
>>     }
>>     return 0;
>> }
>> % g++ -g t.cc
>> % gdb -ex "start" -ex "p a" a.out
>>
>> The fix is rather trivial - in cp_print_static_field(), should call
>> check_typedef() to get the static member's real type and use it to
>> check whether it's a struct or an array.
>>
>> As Simon suggested, I've added a new test case to the testsuite
>> and am passing the original type, not the real type, as argument
>> to both cp_print_value_fields() and val_print().
>>
>> Re-tested on both aarch64-linux-gnu and amd64-linux-gnu. No regressions.
>
> Hi Weimin,
>
> Could you change the title to something more descriptive about what 
> the change/fix is, rather than the problem being fixed?  For example, 
> "Fix infinite recursion when printing static member with typedef".
>
> It is ok to push with that fixed (feel free to ask if you still need 
> some guidance).
>
> Thanks!
>
> Simon
Hi Simon,

I just got started to work on this. Here is what I've done (I followed
your lead to creat a different remote name):

% git add <newfile>
% git commit -a
% git remote add upstream ssh://sourceware.org/git/binutils-gdb.git
% git fetch upstream

I have a few questions:

  * Do I need to do a "git merge" after "git fetch"? Or can I just
    do "git pull" which is equivalent to "git fetch;git merge"?
    (I was a Mercurial(hg) user, its typical workflow is like:
     hg in; do work; hg commit; hg pull; hg rebase(if needed); hg push)

  * In your previous email, you said:

    Make sure you inserted the ChangeLog entries in the actual ChangeLog 
files
    and amended your commit

    It seems the "git commit -a" command will contain all the changes, 
including
    those in ChangeLog files. Why do I have to insert the entries?

  * Changing the commit title to be be more descriptive:

    So I need to use "git commit --amend" to change the title?

Thanks very much for your help.

Weimin
  

On 2018-03-30 05:43 PM, Weimin Pan wrote:
> Hi Simon,
> 
> I just got started to work on this. Here is what I've done (I followed
> your lead to creat a different remote name):
> 
> % git add <newfile>
> % git commit -a
> % git remote add upstream ssh://sourceware.org/git/binutils-gdb.git
> % git fetch upstream
> 
> I have a few questions:
> 
>   * Do I need to do a "git merge" after "git fetch"? Or can I just
>     do "git pull" which is equivalent to "git fetch;git merge"?
>     (I was a Mercurial(hg) user, its typical workflow is like:
>      hg in; do work; hg commit; hg pull; hg rebase(if needed); hg push)

There are two different approaches to bringing the commits from upstream into the
branch where you did some work, rebase and merge (they probably exist in mercurial
too, maybe some other name).  Many projects (including us) never use merging,
because it leads to a non-linear history, which is more difficult to follow and
bisect.

To keep it simple, if you have some commits of yours on master and want to "update"
to get the new stuff from the official repo, I suggest doing "git pull --rebase",
which is the same as "git fetch; git rebase".  It will basically try to apply your
commits on top of the "official" master branch.  You may need to handle any conflicts,
I suggest looking on the web, there are plenty of tutorials for that.

>   * In your previous email, you said:
> 
>     Make sure you inserted the ChangeLog entries in the actual ChangeLog 
> files
>     and amended your commit
> 
>     It seems the "git commit -a" command will contain all the changes, 
> including
>     those in ChangeLog files. Why do I have to insert the entries?

As you can see on the mailing list (though there are some variations), we usually
put the ChangeLog entry as part of the commit message when posting the patch to
the list.  I think the historical reason for that is that otherwise, rebasing your
patches always gives some conflicts in the ChangeLog files*.  Therefore, when comes
the time to push the patch to the upstream repo, we must not forget to actually
insert the ChangeLog entry at the top of the right ChangeLog file, and modify the
commit to contain that change.  This can be done with

$ ... copy ChangeLog entry to ChangeLog file ...
$ git add ChangeLog
$ git commit --amend

The last command will modify the currently checked out commit with the stage changes.

* You can use this to mitigate the conflicts in ChangeLogs though:
  http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c

I personally avoid using "git commit -a", as it's easy to add unwanted changes.  You
can try "git add -p" (with or without specifying a filename afteR).  For each modified
hunk, it will ask you if you want to add it to the staged changes (what's about to be
committed).  It's then easier to spot unintended changes.

> 
>   * Changing the commit title to be be more descriptive:
> 
>     So I need to use "git commit --amend" to change the title?

Exactly, "git commit --amend" will allow you to change the commit message, including
the title (the first line).

> 
> Thanks very much for your help.
> 
> Weimin 

You are welcome, thanks for your perseverance!

Simon
  

On 3/30/2018 3:04 PM, Simon Marchi wrote:
> On 2018-03-30 05:43 PM, Weimin Pan wrote:
>> Hi Simon,
>>
>> I just got started to work on this. Here is what I've done (I followed
>> your lead to creat a different remote name):
>>
>> % git add <newfile>
>> % git commit -a
>> % git remote add upstream ssh://sourceware.org/git/binutils-gdb.git
>> % git fetch upstream
>>
>> I have a few questions:
>>
>>    * Do I need to do a "git merge" after "git fetch"? Or can I just
>>      do "git pull" which is equivalent to "git fetch;git merge"?
>>      (I was a Mercurial(hg) user, its typical workflow is like:
>>       hg in; do work; hg commit; hg pull; hg rebase(if needed); hg push)
> There are two different approaches to bringing the commits from upstream into the
> branch where you did some work, rebase and merge (they probably exist in mercurial
> too, maybe some other name).  Many projects (including us) never use merging,
> because it leads to a non-linear history, which is more difficult to follow and
> bisect.
>
> To keep it simple, if you have some commits of yours on master and want to "update"
> to get the new stuff from the official repo, I suggest doing "git pull --rebase",
> which is the same as "git fetch; git rebase".  It will basically try to apply your
> commits on top of the "official" master branch.  You may need to handle any conflicts,
> I suggest looking on the web, there are plenty of tutorials for that.

Yes, there are indeed many tutorials out there and I've been reading 
some of them to learn more
about git :)

>>    * In your previous email, you said:
>>
>>      Make sure you inserted the ChangeLog entries in the actual ChangeLog
>> files
>>      and amended your commit
>>
>>      It seems the "git commit -a" command will contain all the changes,
>> including
>>      those in ChangeLog files. Why do I have to insert the entries?
> As you can see on the mailing list (though there are some variations), we usually
> put the ChangeLog entry as part of the commit message when posting the patch to
> the list.  I think the historical reason for that is that otherwise, rebasing your
> patches always gives some conflicts in the ChangeLog files*.  Therefore, when comes
> the time to push the patch to the upstream repo, we must not forget to actually
> insert the ChangeLog entry at the top of the right ChangeLog file, and modify the
> commit to contain that change.  This can be done with
>
> $ ... copy ChangeLog entry to ChangeLog file ...
> $ git add ChangeLog
> $ git commit --amend
>
> The last command will modify the currently checked out commit with the stage changes.

Thanks for the tips.  But I checked the ChangeLog files which seem to 
contains the entries.

> * You can use this to mitigate the conflicts in ChangeLogs though:
>    http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c
>
> I personally avoid using "git commit -a", as it's easy to add unwanted changes.  You
> can try "git add -p" (with or without specifying a filename afteR).  For each modified
> hunk, it will ask you if you want to add it to the staged changes (what's about to be
> committed).  It's then easier to spot unintended changes.

Yes, it looks like "git add -p" is better than "commit -a" which our 
group was told to use.

>>    * Changing the commit title to be be more descriptive:
>>
>>      So I need to use "git commit --amend" to change the title?
> Exactly, "git commit --amend" will allow you to change the commit message, including
> the title (the first line).

I just did my first patch:

$ git push upstream fixes
Enter passphrase for key '/home/wepan/.ssh/id_rsa':
Counting objects: 17, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (10/10), done.
Writing objects: 100% (10/10), 2.43 KiB, done.
Total 10 (delta 8), reused 0 (delta 0)
To ssh://sourceware.org/git/binutils-gdb.git
    0f59d5f..c9cf730  fixes -> fixes

and hope I did it correctly.

Thanks again for your help. I really appreciate it.

Weimin

> You are welcome, thanks for your perseverance!
>
> Simon
  

I just emailed Weimin personally when I saw the branch creation,
but now I understand a little better:

> I just did my first patch:
> 
> $ git push upstream fixes
> Enter passphrase for key '/home/wepan/.ssh/id_rsa':
> Counting objects: 17, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (10/10), done.
> Writing objects: 100% (10/10), 2.43 KiB, done.
> Total 10 (delta 8), reused 0 (delta 0)
> To ssh://sourceware.org/git/binutils-gdb.git
>    0f59d5f..c9cf730  fixes -> fixes
> 
> and hope I did it correctly.

Actually, no :).

What you did is you pushed your branch called locally "fixes"
to the repository corresponding to "upstream".  So, when you did
the "push" command above, what happened is that it created
the "fixes" branch on the upstream repository. This is not
what you want, because (1) it creates a branch on the remote
where you fix is (and pollutes the already existing branches),
and (2) does not change the "master" branch, and so your fix
is not really applied to the current development branch either.

With your permission, I will start by fixing the mistake, which
was to create the "fixes" branch on the upstream repository.

On your end, I think the simplest solution is for you to
push your current "fixes" branch to upstream's master:

    $ git push upstream fixes:master

**HOWEVER**, BEFORE YOU DO SO, please do the following:

    $ git log upstream/master..fixes

and verify that the list only shows the one path you are trying
to push. From your push of the "fixes" branch, I think that's correct,
but it's not a bad thing to be doing systematically, to make sure
you are pushing exactly what you think you are pushing.

I would like to recomment a book called "Pro Git" if you'd like
to learn about git. This is the book that allowed me to finally
break through git, and understand it.
  

Hi Joel,

On 3/30/2018 3:52 PM, Joel Brobecker wrote:
> I just emailed Weimin personally when I saw the branch creation,
> but now I understand a little better:
>
>> I just did my first patch:
>>
>> $ git push upstream fixes
>> Enter passphrase for key '/home/wepan/.ssh/id_rsa':
>> Counting objects: 17, done.
>> Delta compression using up to 8 threads.
>> Compressing objects: 100% (10/10), done.
>> Writing objects: 100% (10/10), 2.43 KiB, done.
>> Total 10 (delta 8), reused 0 (delta 0)
>> To ssh://sourceware.org/git/binutils-gdb.git
>>     0f59d5f..c9cf730  fixes -> fixes
>>
>> and hope I did it correctly.
> Actually, no :).
>
> What you did is you pushed your branch called locally "fixes"
> to the repository corresponding to "upstream".  So, when you did
> the "push" command above, what happened is that it created
> the "fixes" branch on the upstream repository. This is not
> what you want, because (1) it creates a branch on the remote
> where you fix is (and pollutes the already existing branches),
> and (2) does not change the "master" branch, and so your fix
> is not really applied to the current development branch either.
>
> With your permission, I will start by fixing the mistake, which
> was to create the "fixes" branch on the upstream repository.

Yes, please go ahead. Thanks.

>
> On your end, I think the simplest solution is for you to
> push your current "fixes" branch to upstream's master:
>
>      $ git push upstream fixes:master
>
> **HOWEVER**, BEFORE YOU DO SO, please do the following:
>
>      $ git log upstream/master..fixes

Yes, the log command does show the correct patch. It was actually my fault
by following:

   git push  <REMOTENAME> <BRANCHNAME>

with "fixes" as the branch name, as opposed to Simon's suggestion of 
"master:master".

>
> and verify that the list only shows the one path you are trying
> to push. From your push of the "fixes" branch, I think that's correct,
> but it's not a bad thing to be doing systematically, to make sure
> you are pushing exactly what you think you are pushing.
>
> I would like to recomment a book called "Pro Git" if you'd like
> to learn about git. This is the book that allowed me to finally
> break through git, and understand it.
>

OK, will see if Amazon carries it. Thanks.

Weimin
  

On 3/30/2018 3:52 PM, Joel Brobecker wrote:
> I just emailed Weimin personally when I saw the branch creation,
> but now I understand a little better:
>
>> I just did my first patch:
>>
>> $ git push upstream fixes
>> Enter passphrase for key '/home/wepan/.ssh/id_rsa':
>> Counting objects: 17, done.
>> Delta compression using up to 8 threads.
>> Compressing objects: 100% (10/10), done.
>> Writing objects: 100% (10/10), 2.43 KiB, done.
>> Total 10 (delta 8), reused 0 (delta 0)
>> To ssh://sourceware.org/git/binutils-gdb.git
>>     0f59d5f..c9cf730  fixes -> fixes
>>
>> and hope I did it correctly.
> Actually, no :).
>
> What you did is you pushed your branch called locally "fixes"
> to the repository corresponding to "upstream".  So, when you did
> the "push" command above, what happened is that it created
> the "fixes" branch on the upstream repository. This is not
> what you want, because (1) it creates a branch on the remote
> where you fix is (and pollutes the already existing branches),
> and (2) does not change the "master" branch, and so your fix
> is not really applied to the current development branch either.
>
> With your permission, I will start by fixing the mistake, which
> was to create the "fixes" branch on the upstream repository.
>
> On your end, I think the simplest solution is for you to
> push your current "fixes" branch to upstream's master:
>
>      $ git push upstream fixes:master


$ git push upstream fixes:master
Enter passphrase for key '/home/wepan/.ssh/id_rsa':
To ssh://sourceware.org/git/binutils-gdb.git
  ! [rejected]        fixes -> master (non-fast-forward)
error: failed to push some refs to 
'ssh://sourceware.org/git/binutils-gdb.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again.  See the 'Note about
fast-forwards' section of 'git push --help' for details.

Does it mean that I  need to do a "git merge"?

Thanks,
Weimin
  

> $ git push upstream fixes:master
> Enter passphrase for key '/home/wepan/.ssh/id_rsa':
> To ssh://sourceware.org/git/binutils-gdb.git
>  ! [rejected]        fixes -> master (non-fast-forward)
> error: failed to push some refs to
> 'ssh://sourceware.org/git/binutils-gdb.git'
> To prevent you from losing history, non-fast-forward updates were rejected
> Merge the remote changes before pushing again.  See the 'Note about
> fast-forwards' section of 'git push --help' for details.
> 
> Does it mean that I  need to do a "git merge"?

Not quite. It is telling you that your "fixes" branch is behind
upstream's "master".  You need to do a "rebase" your "fixes" branch
instead (while having the "fixes" being the current branch):

    $ git rebase upstream/master

You may have some conflicts to resolve, particularly around
ChangeLog files.

Once that's done, do a "git show" to make sure your commit looks
exactly the way you think it should look (in particular, that
the "diff" contains exactly the changes you mean to push).
And then, once done, try the push command again.
  

> > With your permission, I will start by fixing the mistake, which
> > was to create the "fixes" branch on the upstream repository.
> 
> Yes, please go ahead. Thanks.

FTR, done. This is how I did it:

    $ git push origin :fixes
    remote: fatal: Invalid revision range c9cf7302418ad14b7f72949ba0421b9df3cd1127..0000000000000000000000000000000000000000
    To ssh://sourceware.org/git/binutils-gdb.git
     - [deleted]               fixes

The error is a limitation of one the the scripts that get run
when we create or delete a new branch or a new tag, but is not
fatal. The output confirms the branch we deleted.
  

On 3/30/2018 4:41 PM, Joel Brobecker wrote:
>> $ git push upstream fixes:master
>> Enter passphrase for key '/home/wepan/.ssh/id_rsa':
>> To ssh://sourceware.org/git/binutils-gdb.git
>>   ! [rejected]        fixes -> master (non-fast-forward)
>> error: failed to push some refs to
>> 'ssh://sourceware.org/git/binutils-gdb.git'
>> To prevent you from losing history, non-fast-forward updates were rejected
>> Merge the remote changes before pushing again.  See the 'Note about
>> fast-forwards' section of 'git push --help' for details.
>>
>> Does it mean that I  need to do a "git merge"?
> Not quite. It is telling you that your "fixes" branch is behind
> upstream's "master".  You need to do a "rebase" your "fixes" branch
> instead (while having the "fixes" being the current branch):
>
>      $ git rebase upstream/master
>
> You may have some conflicts to resolve, particularly around
> ChangeLog files.

After the "git rebase" command, it no longer points to my branch:

$ git show
commit d8611974cf819e5f8cb9eb36907251f3e2d721c6
Author: Simon Marchi <simon.marchi@polymtl.ca>
Date:   Fri Mar 30 17:18:56 2018 -0400
....

$ git branch
* (no branch)
   fixes
   master

> Once that's done, do a "git show" to make sure your commit looks
> exactly the way you think it should look (in particular, that
> the "diff" contains exactly the changes you mean to push).
> And then, once done, try the push command again.
>
  

> > Not quite. It is telling you that your "fixes" branch is behind
> > upstream's "master".  You need to do a "rebase" your "fixes" branch
> > instead (while having the "fixes" being the current branch):
> > 
> >      $ git rebase upstream/master
> > 
> > You may have some conflicts to resolve, particularly around
> > ChangeLog files.
> 
> After the "git rebase" command, it no longer points to my branch:

That tells me the rebase did not complete successfully (the merge
conflict I was talking about). What output did you get when you
rebased? Did you resolve the merge conflict? And after you did so,
did you do a "git rebase --continue"?

Looking around, I found the following documentation which seems to
provide some information on how to handle merge conflicts after
a git rebase.

https://help.github.com/articles/resolving-merge-conflicts-after-a-git-rebase/
https://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/
https://help.github.com/articles/about-merge-conflicts/

If you're not sure where you are, right now, try the following:

    $ git rebase --abort

That should abort the rebase operation, and get you back where you
started; and in particular, the current branch should be back to
the "fixes" branch.
  

On 3/30/2018 6:52 PM, Joel Brobecker wrote:
>>> Not quite. It is telling you that your "fixes" branch is behind
>>> upstream's "master".  You need to do a "rebase" your "fixes" branch
>>> instead (while having the "fixes" being the current branch):
>>>
>>>       $ git rebase upstream/master
>>>
>>> You may have some conflicts to resolve, particularly around
>>> ChangeLog files.
>> After the "git rebase" command, it no longer points to my branch:
> That tells me the rebase did not complete successfully (the merge
> conflict I was talking about). What output did you get when you
> rebased? Did you resolve the merge conflict? And after you did so,
> did you do a "git rebase --continue"?

Sorry, I lost the output. But I did resolve the merge conflicts by 
modifying the
ChangeLog files.  I just did a "git rebase  --continue" which I didn't 
do before
and it points to my branch and shows my patch:

%  git add ChangeLog
%  git add testsuite/ChangeLog
%  git rebase --continue
%  git commit --amend
%  git show

But when I tried to push again, I got the same "non-fast-forward" error 
as if no merges were ever done.

> Looking around, I found the following documentation which seems to
> provide some information on how to handle merge conflicts after
> a git rebase.
>
> https://help.github.com/articles/resolving-merge-conflicts-after-a-git-rebase/
> https://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/
> https://help.github.com/articles/about-merge-conflicts/

Will read the above documentation for clue. Thanks.

> If you're not sure where you are, right now, try the following:
>
>      $ git rebase --abort
>
> That should abort the rebase operation, and get you back where you
> started; and in particular, the current branch should be back to
> the "fixes" branch.
>
  

> Sorry, I lost the output. But I did resolve the merge conflicts by modifying
> the
> ChangeLog files.  I just did a "git rebase  --continue" which I didn't do
> before
> and it points to my branch and shows my patch:
> 
> %  git add ChangeLog
> %  git add testsuite/ChangeLog
> %  git rebase --continue
> %  git commit --amend
> %  git show
> 
> But when I tried to push again, I got the same "non-fast-forward" error as
> if no merges were ever done.

This is most likely because someone pushed a change between the moment
you fetched + rebased, and the moment you tried to push the rebased
result. You're going to have to redo it again, I'm afraid. Once you
learn to handle those merge failures quickly, this will almost never
happen.
  

On 4/2/2018 6:44 AM, Joel Brobecker wrote:
>> Sorry, I lost the output. But I did resolve the merge conflicts by modifying
>> the
>> ChangeLog files.  I just did a "git rebase  --continue" which I didn't do
>> before
>> and it points to my branch and shows my patch:
>>
>> %  git add ChangeLog
>> %  git add testsuite/ChangeLog
>> %  git rebase --continue
>> %  git commit --amend
>> %  git show
>>
>> But when I tried to push again, I got the same "non-fast-forward" error as
>> if no merges were ever done.
> This is most likely because someone pushed a change between the moment
> you fetched + rebased, and the moment you tried to push the rebased
> result. You're going to have to redo it again, I'm afraid. Once you
> learn to handle those merge failures quickly, this will almost never
> happen.
>

Hi Joel,

I tried it differently by merging the "fixes" branch to my "master" 
branch but got
the same "non-fast-forward"  error when pushing:

$ git checkout master
$ git merge fixes
$ git fetch upstream
$ git push upstream master:master
To ssh://sourceware.org/git/binutils-gdb.git
  ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 
'ssh://sourceware.org/git/binutils-gdb.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again.  See the 'Note about
fast-forwards' section of 'git push --help' for details.

Maybe output from the "status" command sheds some light?

$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 19 commits.
#
nothing to commit (working directory clean)

Thanks.
  

> I tried it differently by merging the "fixes" branch to my "master" branch
> but got
> the same "non-fast-forward"  error when pushing:

We're going to take it off-list, because I doubt everything is
really all that interested in following that thread.
  

This patch has been pushed.

Thanks.

On 3/29/2018 10:08 PM, Simon Marchi wrote:
> On 2018-03-28 16:44, Weimin Pan wrote:
>> The original problem was fixed (see related PR 22242). But using a 
>> typedef
>> as the declared type for a static member variable, as commented in 
>> this PR,
>> is still causing gdb to get into infinite loop when printing the static
>> member's value. This problem can be reproduced as follows:
>>
>> % cat t.cc
>> class A {
>>     typedef A type;
>> public:
>>     bool operator==(const type& other) { return true; }
>>
>>     static const type INSTANCE;
>> };
>>
>> const A A::INSTANCE;
>>
>> int main() {
>>     A a;
>>     if (a == A::INSTANCE) {
>>         return -1;
>>     }
>>     return 0;
>> }
>> % g++ -g t.cc
>> % gdb -ex "start" -ex "p a" a.out
>>
>> The fix is rather trivial - in cp_print_static_field(), should call
>> check_typedef() to get the static member's real type and use it to
>> check whether it's a struct or an array.
>>
>> As Simon suggested, I've added a new test case to the testsuite
>> and am passing the original type, not the real type, as argument
>> to both cp_print_value_fields() and val_print().
>>
>> Re-tested on both aarch64-linux-gnu and amd64-linux-gnu. No regressions.
>
> Hi Weimin,
>
> Could you change the title to something more descriptive about what 
> the change/fix is, rather than the problem being fixed?  For example, 
> "Fix infinite recursion when printing static member with typedef".
>
> It is ok to push with that fixed (feel free to ask if you still need 
> some guidance).
>
> Thanks!
>
> Simon