Fix ptype bug actually exercised in userdef.exp
authorPedro Alves <palves@redhat.com>
Thu, 14 Feb 2013 12:43:46 +0000 (12:43 +0000)
committerPedro Alves <palves@redhat.com>
Thu, 14 Feb 2013 12:43:46 +0000 (12:43 +0000)
commit4819b3f897686ee8a2d51f6ba1c9c4e7c3a22597
treea22f2b46ad84bf216d9f556011991e983b6cfb82
parentd99b05a32ecaecbaaac6c07f9cbcd8ba46746951
Fix ptype bug actually exercised in userdef.exp

I happened to notice a bug with ptype &Ref, and found out userdef.exp
actually exercises the bug.  With:

class Container
{
public:
  Member m;

  Member& operator* ();
};

Member& Container::operator* ()
{
  return this->m;
}

And 'c' is of type Container:

(gdb) p c
$1 = {m = {z = -9192}}
(gdb) p *c
$2 = (Member &) @0x7fffffffda20: {z = -9192}
(gdb) ptype *c
type = class Member {
  public:
    int z;
} &

(gdb) p &*c
$3 = (Member *) 0x7fffffffda20

(gdb) ptype &*c
type = class Member {
  public:
    int z;
} &*
(gdb)

Notice that last print (&*c) on says the type is a pointer - that's
how you get the address behind a reference.  But notice the last ptype
instead says the type of the same expression is a pointer _reference_.
This looks like a bug to me.

This patch fixes it.  The issue is that we're entering the VALUE_LVAL
(x) == lval_memory branch by mistake for references.  The fix is just
to swap the tests so references are checked first, like value_addr
also handles references first.

Tested on x86_64 Fedora 17.

2013-02-14  Pedro Alves  <palves@redhat.com>

* eval.c (evaluate_subexp_for_address) <default_case_after_eval,
EVAL_AVOID_SIDE_EFFECTS>: Swap and handle TYPE_CODE_REF before
lval_memory.

2013-02-14  Pedro Alves  <palves@redhat.com>

* gdb.cp/userdef.exp (ptype &*c): Don't expect an &.
gdb/ChangeLog
gdb/eval.c
gdb/testsuite/ChangeLog
gdb/testsuite/gdb.cp/userdef.exp