Re: C++ testsuite changes

Re: C++ testsuite changes

[Michael Elizabeth Chastain]

On reflection, actually, I should keep the output identical for a
rewrite.  And I still have a bunch of nice "before" files.
So I'll change classes.exp, derivation.exp, overload.exp, and
virtfunc.exp so that they print the same results in the same order.

Then I can fix the problems in the test script one problem at a time.

I can reproduce Mark's problem with virtfunc.exp by using the
sourceware version of TCL+Expect+Dejagnu rather than the released
versions.  In particular, the sourceware version of Expect was last
updated in 1998.  Argh!  So I'll find some way to write virtfunc.exp
that works with these versions of TCL+Expect+Dejagnu.

As far the virtual base pointer goes, if you consider it a bug in gdb,
then I'll write a KFAIL arm for it and KFAIL it.

Michael C

Re: C++ testsuite changes

[Daniel Jacobowitz]

On Thu, Jan 01, 2004 at 04:40:33PM -0500, Michael Chastain wrote:
> On reflection, actually, I should keep the output identical for a
> rewrite.  And I still have a bunch of nice "before" files.
> So I'll change classes.exp, derivation.exp, overload.exp, and
> virtfunc.exp so that they print the same results in the same order.
> 
> Then I can fix the problems in the test script one problem at a time.
> 
> I can reproduce Mark's problem with virtfunc.exp by using the
> sourceware version of TCL+Expect+Dejagnu rather than the released
> versions.  In particular, the sourceware version of Expect was last
> updated in 1998.  Argh!  So I'll find some way to write virtfunc.exp
> that works with these versions of TCL+Expect+Dejagnu.

Can you identify what expect feature was causing the problem?  I'm
quite curious.

I suspect we need to do an expect update...

> As far the virtual base pointer goes, if you consider it a bug in gdb,
> then I'll write a KFAIL arm for it and KFAIL it.

Thank you.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: C++ testsuite changes

[Michael Elizabeth Chastain]

Committed.

Also, I tested this on native i686-pc-linux-gnu with v2/v3,
dwarf-2 and stabs+.

In the future, I will test changes this big with both tcl+expect+dejagnu
stacks (the stock released versions, which I usually use, and the
sourceware versions).

Michael C

===

   2004-01-01  Michael Chastain  <mec.gnu@mindspring.com>

	   * gdb.cp/virtfunc.exp: Modify some patterns to avoid a
	   mysterious bug with sourceware version of expect.

Re: C++ testsuite changes

[Mark Kettenis]

   Date: Thu,  1 Jan 2004 17:40:49 -0500 (EST)
   From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)

   Okay, this fixes the ERROR/UNRESOLVED problem on my system
   when I use the sourceware version of 'expect'.  It replaces one level of
   "(void|)" alternative with more alternatives at a higher level.

   Mark, can you try this?

That defenitely helps.  Please check this in.  Thanks!

Mark

   2004-01-01  Michael Chastain  <mec.gnu@mindspring.com>

	   * gdb.cp/virtfunc.exp: Modify some patterns to avoid a
	   mysterious bug with sourceware version of expect.

Re: C++ testsuite changes

[Michael Elizabeth Chastain]

Okay, this fixes the ERROR/UNRESOLVED problem on my system
when I use the sourceware version of 'expect'.  It replaces one level of
"(void|)" alternative with more alternatives at a higher level.

Mark, can you try this?

2004-01-01  Michael Chastain  <mec.gnu@mindspring.com>

	* gdb.cp/virtfunc.exp: Modify some patterns to avoid a
	mysterious bug with sourceware version of expect.

Index: virtfunc.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.cp/virtfunc.exp,v
retrieving revision 1.3
diff -c -3 -p -r1.3 virtfunc.exp
*** virtfunc.exp	1 Jan 2004 02:30:59 -0000	1.3
--- virtfunc.exp	1 Jan 2004 22:34:18 -0000
***************
*** 1,4 ****
! # Copyright 1992, 1994, 1995, 1996, 1997, 1998, 1999, 2001, 2002, 2003
  # Free Software Foundation, Inc.
  
  # This program is free software; you can redistribute it and/or modify
--- 1,4 ----
! # Copyright 1992, 1994, 1995, 1996, 1997, 1998, 1999, 2001, 2002, 2003, 2004
  # Free Software Foundation, Inc.
  
  # This program is free software; you can redistribute it and/or modify
*************** proc test_ptype_of_classes {} {
*** 330,343 ****
      }
  
      # class D
  
      set re_class	"class D : public AD, public virtual V \{(${ws}private:|)"
      set re_vbptr	"V \\*(_vb.1V|_vb.V);"
      set re_fields	"int d;"
!     set re_methods	"static void s\\((void|)\\);${ws}virtual int vg\\((void|)\\);${ws}virtual int vd\\((void|)\\);${ws}int fd\\((void|)\\);"
      set re_synth_gcc_2	"D & operator=\\(D const ?&\\);${ws}D\\(int, D const ?&\\);${ws}D\\(int\\);"
      set re_synth_gcc_3	"D & operator=\\(D const ?&\\);${ws}D\\(D const ?&\\);${ws}D\\(\\);"
!     set re_all_methods	"($re_methods|$re_synth_gcc_2${ws}$re_methods|$re_synth_gcc_3${ws}$re_methods|$re_methods${ws}$re_synth_gcc_3)"
  
      gdb_test_multiple "ptype D" "ptype D" {
  	-re "type = ${re_class}${ws}(${re_vbptr}${ws}|)public:${ws}${re_fields}${ws}${re_all_methods}$nl\}$nl$gdb_prompt $" {
--- 330,351 ----
      }
  
      # class D
+     #
+     # I wrote this differently from the others to avoid a problem with
+     # the sourceware version of expect, which dates from 1998.
+     # The bug manifests as ERROR/UNRESOLVED results after an "eof"
+     # in gdb_test_multiple.
+     #
+     # -- chastain 2004-01-01
  
      set re_class	"class D : public AD, public virtual V \{(${ws}private:|)"
      set re_vbptr	"V \\*(_vb.1V|_vb.V);"
      set re_fields	"int d;"
!     set re_methods_2	"static void s\\(void\\);${ws}virtual int vg\\(void\\);${ws}virtual int vd\\(void\\);${ws}int fd\\(void\\);"
!     set re_methods_3	"static void s\\(\\);${ws}virtual int vg\\(\\);${ws}virtual int vd\\(\\);${ws}int fd\\(\\);"
      set re_synth_gcc_2	"D & operator=\\(D const ?&\\);${ws}D\\(int, D const ?&\\);${ws}D\\(int\\);"
      set re_synth_gcc_3	"D & operator=\\(D const ?&\\);${ws}D\\(D const ?&\\);${ws}D\\(\\);"
!     set re_all_methods	"($re_methods_2|$re_methods_3|$re_synth_gcc_2${ws}$re_methods_2|$re_synth_gcc_3${ws}$re_methods_3|$re_methods${ws}$re_synth_gcc_3)"
  
      gdb_test_multiple "ptype D" "ptype D" {
  	-re "type = ${re_class}${ws}(${re_vbptr}${ws}|)public:${ws}${re_fields}${ws}${re_all_methods}$nl\}$nl$gdb_prompt $" {

Re: C++ testsuite changes

[Daniel Jacobowitz]

On Thu, Jan 01, 2004 at 05:15:45PM -0500, Michael Chastain wrote:
> drow> Can you identify what expect feature was causing the problem?  I'm
> drow> quite curious.
> 
> I'm working on it.  Something like this is happening:
> 
>   virtfunc.exp calls gdb_test_multiple
>   gdb_test_multiple gets the "eof" case
>   virtfunc.exp calls gdb_test_multiple with nearly the same pattern
>   gdb_test_multiple gets the "eof" case
>   virtfunc.exp calls gdb_test_multiple with nearly the same pattern
>   gdb_test_multiple gets the "eof" case
>   virtfunc.exp calls gdb_test_multiple with nearly the same pattern
>   gdb_test_multiple gets the "eof" case
>   virtfunc.exp calls gdb_test_multiple with a different pattern
>   gdb_test_multiple recovers and gets normal output!
> 
> I'll try futzing with the problem pattern and see if that makes the
> problem go away.
> 
> drow> I suspect we need to do an expect update...
> 
> Well, tcl 8.4.5 + expect 5.3.9 + dejagnu 1.4.3 works fine on
> hppa2.0w-hp-hpux11.11 (as well as i686-pc-linux-gnu of course).
> 
> What would it take to do an expect update?  In particular, what is the
> list of hosts that have to be tested with a new version of 'expect'
> in order to do an expect update?

I haven't the faintest idea.  But I think it may be better to simply do
the update and deal with the consequences.  The real question is, does
anything other than dejagnu use the in-tree expect?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: C++ testsuite changes

[Michael Elizabeth Chastain]

drow> Can you identify what expect feature was causing the problem?  I'm
drow> quite curious.

I'm working on it.  Something like this is happening:

  virtfunc.exp calls gdb_test_multiple
  gdb_test_multiple gets the "eof" case
  virtfunc.exp calls gdb_test_multiple with nearly the same pattern
  gdb_test_multiple gets the "eof" case
  virtfunc.exp calls gdb_test_multiple with nearly the same pattern
  gdb_test_multiple gets the "eof" case
  virtfunc.exp calls gdb_test_multiple with nearly the same pattern
  gdb_test_multiple gets the "eof" case
  virtfunc.exp calls gdb_test_multiple with a different pattern
  gdb_test_multiple recovers and gets normal output!

I'll try futzing with the problem pattern and see if that makes the
problem go away.

drow> I suspect we need to do an expect update...

Well, tcl 8.4.5 + expect 5.3.9 + dejagnu 1.4.3 works fine on
hppa2.0w-hp-hpux11.11 (as well as i686-pc-linux-gnu of course).

What would it take to do an expect update?  In particular, what is the
list of hosts that have to be tested with a new version of 'expect'
in order to do an expect update?

Michael C

Re: C++ testsuite changes

[Daniel Jacobowitz]

On Thu, Jan 01, 2004 at 04:22:47PM -0500, Michael Chastain wrote:
> > I would really prefer it if you didn't rewrite the tests to accomodate
> > the ABI change (a very specific change) and change all sorts of other
> > tests at the same time.  It makes it impossible to tell from your
> > patches when you make a change like this one.
> 
> Sigh, you're right.  I should have done this in several stages,
> where the first stage is lot of gdb_test_multiple with no change
> in output.
> 
> I can go back and make it that way if you want.  Shall I do that?

At this point I don't think it's worth it.  For the remaining testcases
perhaps?

> > Eh... why don't you?  It's a feature that we don't print the virtual
> > base pointer in recent gcc/dwarf combinations.
> 
> Of course it's acceptable if gdb does *not* print the virtual base
> pointer.
> 
> If gdb *does* print a virtual base pointer, do we consider that a
> bug in gcc?  Because that's what "XFAIL" means.  Or is it a bug in gdb?
> Then I should file a PR for it.
> 
> My opinion is that we should just accept it.  There's far worse bugs
> in C++ support that aren't getting any attention.

It's a bug in GDB.

I'm currently working on the C++ PRs.  Unfortunately the one at the top
of my list also triggers a GCC bug.  So it is taking time.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: C++ testsuite changes

[Michael Elizabeth Chastain]

> I would really prefer it if you didn't rewrite the tests to accomodate
> the ABI change (a very specific change) and change all sorts of other
> tests at the same time.  It makes it impossible to tell from your
> patches when you make a change like this one.

Sigh, you're right.  I should have done this in several stages,
where the first stage is lot of gdb_test_multiple with no change
in output.

I can go back and make it that way if you want.  Shall I do that?

> Eh... why don't you?  It's a feature that we don't print the virtual
> base pointer in recent gcc/dwarf combinations.

Of course it's acceptable if gdb does *not* print the virtual base
pointer.

If gdb *does* print a virtual base pointer, do we consider that a
bug in gcc?  Because that's what "XFAIL" means.  Or is it a bug in gdb?
Then I should file a PR for it.

My opinion is that we should just accept it.  There's far worse bugs
in C++ support that aren't getting any attention.

Michael C

Re: C++ testsuite changes

[Daniel Jacobowitz]

On Thu, Jan 01, 2004 at 03:05:26PM -0500, Michael Chastain wrote:
> Hi Mark,
> 
> > I noticed some PASSes that previously were XFAILs.  Is that correct?
> 
> Let me have a look .... yes, these are the ptype's that I fixed.
> 
> In particular, I changed the results for tests like this:
> 
>   ptype class vC
>   type = class vC : public virtual vA {
>     private:
>       vA *_vb.2vA;
>     public:
>       int vc;
>       int vx;
>   }
> 
> The old test would XFAIL this because gdb prints the virtual base
> pointer, _vb.2vA.  I don't consider that a bug so I don't XFAIL it
> any more.

Eh... why don't you?  It's a feature that we don't print the virtual
base pointer in recent gcc/dwarf combinations.  It could be implemented
for stabs or older gccs or whichever it is that used to xfail, but no
one has taken the time yet.

I would really prefer it if you didn't rewrite the tests to accomodate
the ABI change (a very specific change) and change all sorts of other
tests at the same time.  It makes it impossible to tell from your
patches when you make a change like this one.

> > I get some wierd ERRORs in virtfunc.exp.
> > As far as I can tell, GDB doesn't crash.
> 
> This is stumping me.
> 
> I proofread "ptype D" forwards and backwards and compared it to
> the code before and the code after, and I don't see any mistakes.
> 
> What is your host triple?
> Which versions of TCL, Expect, and Dejagnu are you using?
> Can you mail me the whole gdb.log section for virtfunc.exp?
> 
> Michael C
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: C++ testsuite changes

[Michael Elizabeth Chastain]

Hi Mark,

> I noticed some PASSes that previously were XFAILs.  Is that correct?

Let me have a look .... yes, these are the ptype's that I fixed.

In particular, I changed the results for tests like this:

  ptype class vC
  type = class vC : public virtual vA {
    private:
      vA *_vb.2vA;
    public:
      int vc;
      int vx;
  }

The old test would XFAIL this because gdb prints the virtual base
pointer, _vb.2vA.  I don't consider that a bug so I don't XFAIL it
any more.

> I get some wierd ERRORs in virtfunc.exp.
> As far as I can tell, GDB doesn't crash.

This is stumping me.

I proofread "ptype D" forwards and backwards and compared it to
the code before and the code after, and I don't see any mistakes.

What is your host triple?
Which versions of TCL, Expect, and Dejagnu are you using?
Can you mail me the whole gdb.log section for virtfunc.exp?

Michael C

C++ testsuite changes

[Mark Kettenis]

Attached is the diff between a gdb.sum from before C++ testsuite
changes and one after.  This is on the native FreeBSD 4.7 gcc, which
bears the version number 2.95.4.  I noticed some PASSes that
previously were XFAILs.  Is that correct?  I get some wierd ERRORs in
virtfunc.exp.  As far as I can tell, GDB doesn't crash.

Mark

--- ../testresults/20031212/gdb.sum	Fri Dec 12 19:15:38 2003
+++ gdb/testsuite/gdb.sum	Thu Jan  1 15:12:05 2004
@@ -1,4 +1,4 @@
-Test Run By kettenis on Fri Dec 12 19:10:23 2003
+Test Run By kettenis on Thu Jan  1 15:03:50 2004
 Native configuration is i386-unknown-freebsd4.7
 
 		=== gdb tests ===
@@ -2173,6 +2173,10 @@
 Running ../../../src/gdb/testsuite/gdb.base/foll-exec.exp ...
 Running ../../../src/gdb/testsuite/gdb.base/foll-fork.exp ...
 Running ../../../src/gdb/testsuite/gdb.base/foll-vfork.exp ...
+Running ../../../src/gdb/testsuite/gdb.base/freebpcmd.exp ...
+PASS: gdb.base/freebpcmd.exp: set breakpoint
+PASS: gdb.base/freebpcmd.exp: send breakpoint commands
+PASS: gdb.base/freebpcmd.exp: run program with breakpoint commands
 Running ../../../src/gdb/testsuite/gdb.base/funcargs.exp ...
 PASS: gdb.base/funcargs.exp: run to call0a
 PASS: gdb.base/funcargs.exp: print c after run to call0a
@@ -2971,7 +2975,7 @@
 PASS: gdb.base/page.exp: q
 Running ../../../src/gdb/testsuite/gdb.base/pc-fp.exp ...
 PASS: gdb.base/pc-fp.exp: get value of $pc (0x80484ba)
-PASS: gdb.base/pc-fp.exp: get value of $fp (0xbfbfe85c)
+PASS: gdb.base/pc-fp.exp: get value of $fp (0xbfbfe844)
 PASS: gdb.base/pc-fp.exp: display/i $pc
 PASS: gdb.base/pc-fp.exp: display/w $fp
 Running ../../../src/gdb/testsuite/gdb.base/pointers.exp ...
@@ -6183,6 +6187,22 @@
 PASS: gdb.cp/class2.exp: print * abp at marker return 0, s-p-o off
 PASS: gdb.cp/class2.exp: print * (B *) abp at marker return 0
 Running ../../../src/gdb/testsuite/gdb.cp/classes.exp ...
+PASS: gdb.cp/classes.exp: print Bar::z
+PASS: gdb.cp/classes.exp: print &Foo::x
+PASS: gdb.cp/classes.exp: print (int)&Foo::x
+PASS: gdb.cp/classes.exp: print (int)&Bar::y == 2*sizeof(int)
+PASS: gdb.cp/classes.exp: print Foo::st
+PASS: gdb.cp/classes.exp: set foo.st = 200
+PASS: gdb.cp/classes.exp: print bar.st
+PASS: gdb.cp/classes.exp: print &foo.st
+PASS: gdb.cp/classes.exp: print &Bar::st
+PASS: gdb.cp/classes.exp: print *$
+PASS: gdb.cp/classes.exp: set print static-members off
+PASS: gdb.cp/classes.exp: print csi without static members
+PASS: gdb.cp/classes.exp: print cnsi without static members
+PASS: gdb.cp/classes.exp: set print static-members on
+PASS: gdb.cp/classes.exp: print csi with static members
+PASS: gdb.cp/classes.exp: print cnsi with static members
 PASS: gdb.cp/classes.exp: ptype struct default_public_struct
 PASS: gdb.cp/classes.exp: ptype struct explicit_public_struct
 PASS: gdb.cp/classes.exp: ptype struct protected_struct
@@ -6200,12 +6220,12 @@
 PASS: gdb.cp/classes.exp: ptype class E
 PASS: gdb.cp/classes.exp: ptype class Static
 PASS: gdb.cp/classes.exp: ptype class vA
-XFAIL: gdb.cp/classes.exp: ptype class vB (FIXME: non-portable virtual table constructs)
-XFAIL: gdb.cp/classes.exp: ptype class vC (FIXME: non-portable virtual table constructs)
-XFAIL: gdb.cp/classes.exp: ptype class vD (FIXME: non-portable virtual table constructs)
-XFAIL: gdb.cp/classes.exp: ptype class vE (FIXME: non-portable virtual table constructs)
+PASS: gdb.cp/classes.exp: ptype class vB
+PASS: gdb.cp/classes.exp: ptype class vC
+PASS: gdb.cp/classes.exp: ptype class vD
+PASS: gdb.cp/classes.exp: ptype class vE
 PASS: gdb.cp/classes.exp: ptype class Base1
-PASS: gdb.cp/classes.exp: ptype class Foo (obsolescent gcc or gdb)
+KFAIL: gdb.cp/classes.exp: ptype class Foo (PRMS: gdb/1497)
 PASS: gdb.cp/classes.exp: ptype class Bar
 PASS: gdb.cp/classes.exp: g_A.a incorrect
 PASS: gdb.cp/classes.exp: g_A.x incorrect
@@ -6242,7 +6262,6 @@
 PASS: gdb.cp/classes.exp: unrelated class *param
 PASS: gdb.cp/classes.exp: unrelated class &param
 PASS: gdb.cp/classes.exp: unrelated class param
-PASS: gdb.cp/classes.exp: continue to enums2(\(\)|)
 PASS: gdb.cp/classes.exp: print obj_with_enum (1)
 PASS: gdb.cp/classes.exp: next
 PASS: gdb.cp/classes.exp: print obj_with_enum (2)
@@ -6251,25 +6270,8 @@
 KFAIL: gdb.cp/classes.exp: ptype obj_with_enum (PRMS: gdb/57)
 KFAIL: gdb.cp/classes.exp: print (ClassWithEnum::PrivEnum) 42 (PRMS: gdb/826)
 KFAIL: gdb.cp/classes.exp: print ('ClassWithEnum::PrivEnum') 42 (PRMS: gdb/57)
-PASS: gdb.cp/classes.exp: print Bar::z
-PASS: gdb.cp/classes.exp: print &Foo::x
-PASS: gdb.cp/classes.exp: print (int)&Foo::x
-PASS: gdb.cp/classes.exp: print (int)&Bar::y == 2*sizeof(int)
-PASS: gdb.cp/classes.exp: print (int)pmi == sizeof(int)
-PASS: gdb.cp/classes.exp: print Foo::st
-PASS: gdb.cp/classes.exp: print bar.st
-PASS: gdb.cp/classes.exp: print &foo.st
-PASS: gdb.cp/classes.exp: print &Bar::st
-PASS: gdb.cp/classes.exp: print *$
-PASS: gdb.cp/classes.exp: set print static-members off
-PASS: gdb.cp/classes.exp: print csi without static members
-PASS: gdb.cp/classes.exp: print cnsi without static members
-PASS: gdb.cp/classes.exp: set print static-members on
-PASS: gdb.cp/classes.exp: print csi with static members
-PASS: gdb.cp/classes.exp: print cnsi with static members
 PASS: gdb.cp/classes.exp: finish from marker_reg1
 XFAIL: gdb.cp/classes.exp: calling method for small class (PRMS 2972)
-PASS: gdb.cp/classes.exp: demangle
 Running ../../../src/gdb/testsuite/gdb.cp/cplusfuncs.exp ...
 PASS: gdb.cp/cplusfuncs.exp: detect dm_operator_comma
 PASS: gdb.cp/cplusfuncs.exp: detect dm_type_char_star
@@ -7276,14 +7278,14 @@
 PASS: gdb.cp/demangle.exp: hp: _Utf390_1__1_9223372036854775807__9223372036854775
 Running ../../../src/gdb/testsuite/gdb.cp/derivation.exp ...
 PASS: gdb.cp/derivation.exp: up from marker1
+PASS: gdb.cp/derivation.exp: ptype a_instance
 PASS: gdb.cp/derivation.exp: print value of a_instance
-PASS: gdb.cp/derivation.exp: ptype a_instance (with synth ops)
+KFAIL: gdb.cp/derivation.exp: ptype d_instance (PRMS: gdb/1498)
 PASS: gdb.cp/derivation.exp: print value of d_instance
-PASS: gdb.cp/derivation.exp: ptype d_instance
+KFAIL: gdb.cp/derivation.exp: ptype e_instance (PRMS: gdb/1498)
 PASS: gdb.cp/derivation.exp: print value of e_instance
-PASS: gdb.cp/derivation.exp: ptype e_instance
-PASS: gdb.cp/derivation.exp: print value of f_instance
 PASS: gdb.cp/derivation.exp: ptype f_instance
+PASS: gdb.cp/derivation.exp: print value of f_instance
 PASS: gdb.cp/derivation.exp: print value of d_instance.a
 PASS: gdb.cp/derivation.exp: print value of d_instance.aa
 PASS: gdb.cp/derivation.exp: print value of d_instance.b
@@ -7599,8 +7601,8 @@
 PASS: gdb.cp/namespace.exp: print XOtherFile
 Running ../../../src/gdb/testsuite/gdb.cp/overload.exp ...
 PASS: gdb.cp/overload.exp: up from marker1
+XFAIL: gdb.cp/overload.exp: ptype foo_instance1
 PASS: gdb.cp/overload.exp: print foo_instance1
-PASS: gdb.cp/overload.exp: ptype foo_instance1 (shorter match)
 PASS: gdb.cp/overload.exp: print foo_instance2
 PASS: gdb.cp/overload.exp: print foo_instance3
 PASS: gdb.cp/overload.exp: print call overloaded func 1 arg
@@ -7834,35 +7836,41 @@
 Running ../../../src/gdb/testsuite/gdb.cp/virtfunc.exp ...
 PASS: gdb.cp/virtfunc.exp: ptype VA
 PASS: gdb.cp/virtfunc.exp: ptype VB
+PASS: gdb.cp/virtfunc.exp: ptype vb
+PASS: gdb.cp/virtfunc.exp: ptype pVB
 PASS: gdb.cp/virtfunc.exp: ptype V
-PASS: gdb.cp/virtfunc.exp: ptype A
-PASS: gdb.cp/virtfunc.exp: ptype B
-PASS: gdb.cp/virtfunc.exp: ptype C
-PASS: gdb.cp/virtfunc.exp: ptype AD
-PASS: gdb.cp/virtfunc.exp: ptype D
-PASS: gdb.cp/virtfunc.exp: ptype E
-PASS: gdb.cp/virtfunc.exp: ptype dd
-PASS: gdb.cp/virtfunc.exp: ptype ppd
-PASS: gdb.cp/virtfunc.exp: ptype pAd
-PASS: gdb.cp/virtfunc.exp: ptype a
-PASS: gdb.cp/virtfunc.exp: ptype b
-PASS: gdb.cp/virtfunc.exp: ptype c
-PASS: gdb.cp/virtfunc.exp: ptype d
-PASS: gdb.cp/virtfunc.exp: ptype e
 PASS: gdb.cp/virtfunc.exp: ptype v
-PASS: gdb.cp/virtfunc.exp: ptype vb
-PASS: gdb.cp/virtfunc.exp: ptype pAa
-PASS: gdb.cp/virtfunc.exp: ptype pAe
-PASS: gdb.cp/virtfunc.exp: ptype pBe
-PASS: gdb.cp/virtfunc.exp: ptype pDd
-PASS: gdb.cp/virtfunc.exp: ptype pDe
 PASS: gdb.cp/virtfunc.exp: ptype pVa
 PASS: gdb.cp/virtfunc.exp: ptype pVv
 PASS: gdb.cp/virtfunc.exp: ptype pVe
 PASS: gdb.cp/virtfunc.exp: ptype pVd
+PASS: gdb.cp/virtfunc.exp: ptype A
+PASS: gdb.cp/virtfunc.exp: ptype a
+PASS: gdb.cp/virtfunc.exp: ptype pAa
+PASS: gdb.cp/virtfunc.exp: ptype pAe
+PASS: gdb.cp/virtfunc.exp: ptype B
+PASS: gdb.cp/virtfunc.exp: ptype b
+PASS: gdb.cp/virtfunc.exp: ptype pBe
+PASS: gdb.cp/virtfunc.exp: ptype C
+PASS: gdb.cp/virtfunc.exp: ptype c
+PASS: gdb.cp/virtfunc.exp: ptype AD
+PASS: gdb.cp/virtfunc.exp: ptype pAd
 PASS: gdb.cp/virtfunc.exp: ptype pADe
+ERROR: Process no longer exists
+UNRESOLVED: gdb.cp/virtfunc.exp: ptype D
+ERROR: Process no longer exists
+UNRESOLVED: gdb.cp/virtfunc.exp: ptype d
+ERROR: Process no longer exists
+UNRESOLVED: gdb.cp/virtfunc.exp: ptype dd
+ERROR: Process no longer exists
+UNRESOLVED: gdb.cp/virtfunc.exp: ptype ppd
+ERROR: Process no longer exists
+UNRESOLVED: gdb.cp/virtfunc.exp: ptype pDd
+ERROR: Process no longer exists
+UNRESOLVED: gdb.cp/virtfunc.exp: ptype pDe
+PASS: gdb.cp/virtfunc.exp: ptype E
+PASS: gdb.cp/virtfunc.exp: ptype e
 PASS: gdb.cp/virtfunc.exp: ptype pEe
-PASS: gdb.cp/virtfunc.exp: ptype pVB
 PASS: gdb.cp/virtfunc.exp: print pAe->f()
 PASS: gdb.cp/virtfunc.exp: print pAa->f()
 PASS: gdb.cp/virtfunc.exp: print pDe->vg()
@@ -10166,11 +10174,12 @@
 
 		=== gdb Summary ===
 
-# of expected passes		9619
+# of expected passes		9614
 # of unexpected failures	26
-# of expected failures		155
-# of known failures		35
+# of expected failures		152
+# of known failures		38
+# of unresolved testcases	6
 # of untested testcases		3
 # of unsupported tests		14
-/home/kettenis/sandbox/virgin-gdb/obj/gdb/testsuite/../../gdb/gdb version  2003-12-12-cvs -nx
+/home/kettenis/sandbox/virgin-gdb/obj/gdb/testsuite/../../gdb/gdb version  2004-01-01-cvs -nx