Re: egcs release

Re: egcs release

[Jim Wilson]

	Wed Jul 30 14:43:34 1997  H.J. Lu  (hjl@gnu.ai.mit.edu)

		* sched.c (sched_analyze_2): Handle access stack memory
		beyond the stack pointer via the frame pointer.
		(STACK_POINTER_REG_NREGS): New. Default as 1.

We already have a patch installed that fixes this, and which works for
both the old (sched.c) and new (haifa-sched.c) schedulers.  Patches that
only fix sched.c aren't very userful anymore.

	Sun Jul 13 13:39:15 1997  H.J. Lu  (hjl@gnu.ai.mit.edu)

		* sched.c (sched_analyze_2): Handle USE_PIC_OFFSET_TABLE_REG if
		defined.
		(PIC_OFFSET_TABLE_REG_NREGS): New. Default as 1.

		* config/i386/i386.h (USE_PIC_OFFSET_TABLE_REG): New. True if
		the PIC base register is used.

I suggest we use this patch.  This fixes the testcase that you wrote your
patch for, and works for both schedulers.

Wed Aug 27 14:52:54 1997  Jim Wilson  <wilson@cygnus.com>

	* i386.c (ix86_expand_epilogue): Emit blockage instruction when pic.

Index: i386.c
===================================================================
RCS file: /cvs/cvsfiles/egcs/gcc/config/i386/i386.c,v
retrieving revision 1.1.1.1
diff -p -r1.1.1.1 i386.c
*** i386.c	1997/08/11 15:57:16	1.1.1.1
--- i386.c	1997/08/27 21:52:31
*************** ix86_expand_epilogue ()
*** 2128,2133 ****
--- 2128,2143 ----
  
    xops[2] = stack_pointer_rtx;
  
+   /* When -fpic, we must emit a scheduling barrier, so that the instruction
+      that restores %ebx (which is PIC_OFFSET_TABLE_REGNUM), does not get
+      moved before any instruction which implicitly uses the got.  This
+      includes any instruction which uses a SYMBOL_REF or a LABEL_REF.
+ 
+      Alternatively, this could be fixed by making the dependence on the
+      PIC_OFFSET_TABLE_REGNUM explicit in the RTL.  */
+   if (flag_pic)
+     emit_insn (gen_blockage ());
+ 
    if (nregs > 1 || ! frame_pointer_needed)
      {
        if (frame_pointer_needed)

Re: egcs-2.90.02 970825, hppa1.1-hp-hpux9.01 bootstraps okay

[Jeffrey A Law]

  In message <199708272133.RAA18344@caip.rutgers.edu>you write:
  > 	I bootstrapped egcs-2.90.02 970825 on hppa1.1-hp-hpux9.01 using
  > BOOTCFLAGS='-O3 -funroll-all-loops' and cc for stage1 with native as/ld. 
  > I got a clean "make compare" and identical c-torture results with those
  > of gcc2-970721.  (Later gcc2 snapshots don't bootstrap for me.)
Good/bad.

Good that we generate idential c-torture results, bad because
later gcc2 snapshots don't bootstrap.

Odds are this is a reload issue that I tried to explain to
Kenner without much success.  I'm going to have to take another
stab at it within the next couple days.

[ egcs has code to avoid the reload problem... ]

jeff

Re: Here are the g++ test results

[Jeffrey A Law]

  In message <Pine.PMDF.3.91.970827170134.538982528A-100000@MPS.OHIO-STATE.EDU>
you write:
  > > I believe it is a bug in the testsuite, but I need to see the contents
  > > of the $objdir/libio to make sure.
  > > 
  > Here are the contents of $objdir/libio, sorry about the delay.
THanks.  Looks like the message got garbled somewhere.

Regardless, I think I know what the problem is.  Try this patch
to dejagnu:

Index: lib/libgloss.exp
===================================================================
RCS file: /cvs/cvsfiles/devo/dejagnu/lib/libgloss.exp,v
retrieving revision 1.48
retrieving revision 1.49
diff -c -r1.48 -r1.49
*** libgloss.exp	1997/08/06 04:42:09	1.48
--- libgloss.exp	1997/08/07 01:42:15	1.49
***************
*** 166,172 ****
  	set gccpath [file dirname [file dirname ${base_dir}]]
      }
  
!     set libio_bin_dir [lookfor_file ${gccpath} libio/libio.a];
      set libio_src_dir [lookfor_file ${srcdir} libio/Makefile.in]
      if { $libio_bin_dir != "" && $libio_src_dir != "" } {
  	set libio_src_dir [file dirname ${libio_src_dir}]
--- 166,172 ----
  	set gccpath [file dirname [file dirname ${base_dir}]]
      }
  
!     set libio_bin_dir [lookfor_file ${gccpath} libio/_G_config.h];
      set libio_src_dir [lookfor_file ${srcdir} libio/Makefile.in]
      if { $libio_bin_dir != "" && $libio_src_dir != "" } {
  	set libio_src_dir [file dirname ${libio_src_dir}]

Re: Performance; was: 68k problem.

[Jeffrey A Law]

  In message <9708272100.AA01051@moene.indiv.nluug.nl>you write:
  > i.e. not as bad as I thought [38000+ seconds], but certainly worse  
  > than the g77-0.5.21-970811 + gcc-2.7.2.2 result (~ 10 %).
Just a note; I've got -freduce-all-givs and -fmove-all-movables
in my source tree, and barring any natual disasters they should
get checked in and appear in the next snapshot (tonight/tomorrow).

I'm not including -frerun-loop yet; I want to think about it a
little -- my experiences with trying to rerun passes hasn't been
good.  At various times over the years I've done this with cse
and flow, and in both cases doing so has destabilized things
pretty badly.

Jeff

Re: Here are the g++ test results

[Alexandre Oliva]

Joe Buck writes:

>> I did apply HJ Lu's patch and ran make ckeck-g++ and got the same 
>> results as you and HJ. Is it not possible to run the make checks without 
>> installing the untested compilers and header files?

> It's possible and not hard.  The tests just need to get the -nostdinc++
> flag (to avoid using /usr/include/g++) as well as an -I flag to give them
> the egcs libstdc++ headers.

Not only that, some tests also need to be linked against libstdc++, so
you may need to add some -L flag for gcc to find the non-installed
libstdc++, and maybe a -R flag for the run-time path, if you have
built a shared library.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
Universidade Estadual de Campinas, SP, Brasil

Re: Here are the g++ test results

[djohnson]

On Wed, 27 Aug 1997, Jeffrey A Law wrote:

>   In message <Pine.PMDF.3.91.970827073910.538980029A-100000@MPS.OHIO-STATE.EDU>
> you write:
>   > Hi,
>   > 	I did apply HJ Lu's patch and ran make ckeck-g++ and got the same 
>   > results as you and HJ. Is it not possible to run the make checks without 
>   > installing the untested compilers and header files?
> I believe it is a bug in the testsuite, but I need to see the contents
> of the $objdir/libio to make sure.
> 
> jeff
> 
Here are the contents of $objdir/libio, sorry about the delay.

Doug

  /local/src/egcs-970825/libio:
  total 2637
  drwxrwx---   7 djohnson users        4096 Aug 26 21:36 .
  drwxrwx---  11 djohnson users        2048 Aug 27 14:49 ..
  -rw-rw----   1 djohnson users       73273 Aug 25 11:38 ChangeLog
  -rw-r--r--   1 djohnson users        5244 Aug 26 21:34 Make.pack
  -rw-r--r--   1 djohnson users       24859 Aug 26 21:34 Makefile
  -rw-rw----   1 djohnson users        4638 Aug 25 11:38 Makefile.in
  -rw-rw----   1 djohnson users        2231 Aug 25 11:38 NEWS
  -rw-rw----   1 djohnson users        4377 Aug 25 11:38 PlotFile.cc
  -rw-rw----   1 djohnson users        3201 Aug 25 11:38 PlotFile.h
  -rw-r--r--   1 djohnson users       27004 Aug 26 21:36 PlotFile.o
  -rw-rw----   1 djohnson users        1306 Aug 25 11:38 README
  -rw-rw----   1 djohnson users        2591 Aug 25 11:38 SFile.cc
  -rw-rw----   1 djohnson users        1909 Aug 25 11:38 SFile.h
  -rw-r--r--   1 djohnson users       28700 Aug 26 21:36 SFile.o
  -rw-r--r--   1 djohnson users        2487 Aug 26 21:35 _G_config.h
  -rw-rw----   1 djohnson users        2634 Aug 25 11:38 builtinbuf.cc
  -rw-rw----   1 djohnson users        2295 Aug 25 11:38 builtinbuf.h
  -rw-r--r--   1 djohnson users       14360 Aug 26 21:35 builtinbuf.o
  -rw-rw----   1 djohnson users         372 Aug 25 11:38 cleanup.c
  -rw-r--r--   1 djohnson users        8292 Aug 26 21:35 cleanup.o
  drwxrwx---   2 djohnson users        1024 Aug 25 11:38 config
  -rw-rw----   1 djohnson users       16370 Aug 25 11:38 config.shared
  -rwxr-xr-x   1 djohnson users         322 Aug 26 21:34 config.status
  -rw-rw----   1 djohnson users        2566 Aug 25 11:38 configure.in
  drwxrwx---   2 djohnson users        1024 Aug 26 21:34 dbz
  -rw-rw----   1 djohnson users        8934 Aug 25 11:38 depend
  -rw-r--r--   1 djohnson users          90 Aug 26 21:34 dummy.h
  -rw-rw----   1 djohnson users       18928 Aug 25 11:38 editbuf.cc
  -rw-rw----   1 djohnson users        6882 Aug 25 11:38 editbuf.h
  -rw-r--r--   1 djohnson users       79448 Aug 26 21:36 editbuf.o
  -rw-rw----   1 djohnson users        5028 Aug 25 11:38 filebuf.cc
  -rw-r--r--   1 djohnson users       30084 Aug 26 21:35 filebuf.o
  -rw-rw----   1 djohnson users        3498 Aug 25 11:38 filedoalloc.c
  -rw-r--r--   1 djohnson users       14524 Aug 26 21:35 filedoalloc.o
  -rw-rw----   1 djohnson users       21286 Aug 25 11:38 fileops.c
  -rw-r--r--   1 djohnson users       23992 Aug 26 21:35 fileops.o
  -rw-rw----   1 djohnson users       74204 Aug 25 11:38 floatconv.c
  -rw-r--r--   1 djohnson users       50560 Aug 26 21:35 floatconv.o
  -rw-rw----   1 djohnson users        2223 Aug 25 11:38 floatio.h
  -rw-rw----   1 djohnson users        2609 Aug 25 11:38 fstream.cc
  -rw-rw----   1 djohnson users        3475 Aug 25 11:38 fstream.h
  -rw-r--r--   1 djohnson users       70964 Aug 26 21:35 fstream.o
  -rwxrwx---   1 djohnson users       21427 Aug 25 11:38 gen-params
  -rw-rw----   1 djohnson users       19942 Aug 25 11:38 genops.c
  -rw-r--r--   1 djohnson users       25884 Aug 26 21:35 genops.o
  -rw-rw----   1 djohnson users        3519 Aug 25 11:38 indstream.cc
  -rw-rw----   1 djohnson users        2925 Aug 25 11:38 indstream.h
  -rw-r--r--   1 djohnson users       16860 Aug 26 21:35 indstream.o
  -rw-rw----   1 djohnson users        1779 Aug 25 11:38 ioassign.cc
  -rw-r--r--   1 djohnson users       16076 Aug 26 21:35 ioassign.o
  -rw-rw----   1 djohnson users        3848 Aug 25 11:38 ioextend.cc
  -rw-r--r--   1 djohnson users        9068 Aug 26 21:35 ioextend.o
  -rw-rw----   1 djohnson users        1576 Aug 25 11:38 iofclose.c
  -rw-r--r--   1 djohnson users        8424 Aug 26 21:35 iofclose.o
  -rw-rw----   1 djohnson users        3570 Aug 25 11:38 iofdopen.c
  -rw-r--r--   1 djohnson users       13284 Aug 26 21:35 iofdopen.o
  -rw-rw----   1 djohnson users        1334 Aug 25 11:38 iofflush.c
  -rw-r--r--   1 djohnson users        7448 Aug 26 21:35 iofflush.o
  -rw-rw----   1 djohnson users        1541 Aug 25 11:38 iofgetpos.c
  -rw-r--r--   1 djohnson users        7656 Aug 26 21:35 iofgetpos.o
  -rw-rw----   1 djohnson users        1457 Aug 25 11:38 iofgets.c
  -rw-r--r--   1 djohnson users        7632 Aug 26 21:35 iofgets.o
  -rw-rw----   1 djohnson users        1708 Aug 25 11:38 iofopen.c
  -rw-r--r--   1 djohnson users        8576 Aug 26 21:35 iofopen.o
  -rw-rw----   1 djohnson users        1512 Aug 25 11:38 iofprintf.c
  -rw-r--r--   1 djohnson users        7680 Aug 26 21:35 iofprintf.o
  -rw-rw----   1 djohnson users        1360 Aug 25 11:38 iofputs.c
  -rw-r--r--   1 djohnson users        7708 Aug 26 21:35 iofputs.o
  -rw-rw----   1 djohnson users        1533 Aug 25 11:38 iofread.c
  -rw-r--r--   1 djohnson users        7728 Aug 26 21:35 iofread.o
  -rw-rw--s        1517---fwrite.o
  -rw-rw----   1 djohnson users        3009 Aug 25 11:38 iogetdelim.c
  -rw-r--r--   1 djohnson users        9388 Aug 26 21:35 io     8408 Aug 
26 21:35 iogetline.o
  -rw-rw----  -rw-r--r-:38 iop    2095 Aug 25 1drw-rw----   1 djohnson 
users 6 21:35 ioseekponson users      
  -rw-r--r--   1nson users      .c
  -rw-r--r--921 djohnson users        1502 Aug 25 11:38 iovsscanf.c
  -rw-r--r--   1 djohnson users        8192 Aug 26 21:35 iovsscanf.o
  -rw-rw----   1 djohnson users        3707 Aug 25 11:38 isgetline.cc
  -rw-retline.o
  -rw-2  1 djohnson usertream.cc
  -rw-r       2291 Aug 25 11:38 pfstre  1 djohnson users       18764 
Ars         791 Aug 26 21:36 std  -rw-ron users        8612 Aug 25 11:38 
strstream.cc
  -rw-rw----   1 djohnson users        4314 Aug 25 11:38 strstream.h
  -rw-r--r--   1 djohnson users       65528 Aug 26 21:36 strstream.o
  -rw-r--r--   1 djohnson users        1198 Aug 26 21:34 target-mkfrag
  drwxrwx---   2 djohnson users        1024 Aug 26 21:34 tests
  drwxrwx---   5 djohnson users        1024 Aug 26 21:34 testsuite

Re: Here are the g++ test results

[Jeffrey A Law]

  In message <Pine.PMDF.3.91.970827073910.538980029A-100000@MPS.OHIO-STATE.EDU>
you write:
  > Hi,
  > 	I did apply HJ Lu's patch and ran make ckeck-g++ and got the same 
  > results as you and HJ. Is it not possible to run the make checks without 
  > installing the untested compilers and header files?
I believe it is a bug in the testsuite, but I need to see the contents
of the $objdir/libio to make sure.

jeff

Re: Here are the g++ test results

[Joe Buck]

> 	I did apply HJ Lu's patch and ran make ckeck-g++ and got the same 
> results as you and HJ. Is it not possible to run the make checks without 
> installing the untested compilers and header files?

It's possible and not hard.  The tests just need to get the -nostdinc++
flag (to avoid using /usr/include/g++) as well as an -I flag to give them
the egcs libstdc++ headers.

Re: Here are the g++ test results

[djohnson]

Hi,
	I did apply HJ Lu's patch and ran make ckeck-g++ and got the same 
results as you and HJ. Is it not possible to run the make checks without 
installing the untested compilers and header files?

Doug

On Tue, 26 Aug 1997, Mumit Khan wrote:

> djohnson@mps.ohio-state.edu writes:
> > Hi,
> > 	Steven's results are the same as what I get with Linux 2.0.28, 
> > libc 5.4.33, ld.so 1.9.2, dejagnu-970707.
> 
> [ lots of unexpted failures ... ]
> 
> I just downloaded your logs for g++ and gcc, and now it makes sense why
> you and Steven might be getting all those failures. Note the references 
> to /usr/include/g++ in your log files, which means that you're using 
> iostream from libg++-2.7.[12], and not from the newer libio supplied
> with egcs-970825! Also Note that the compile flags don't include the 
> libio includes from the source tree, and since I had already installed 
> mine, it found the right ones anyway. I suggest you do a 'make install' 
> and then re-run the tests, and then we can compare notes again.
> 
> HJ Lu says in a followup that he has some i386-linux-gnulibc1 patches
> for libio/libstdc++. However, sine his test run gives the same results 
> as mine, hopefuly his patches cover areas that the test cases don't.
> 
> Regards,
> Mumit -- khan@xraylith.wisc.edu
> http://www.xraylith.wisc.edu/~khan/
> 

Re: Here are the g++ test results

[Jeffrey A Law]

  In message <Pine.PMDF.3.91.970826184842.538979005A-100000@MPS.OHIO-STATE.EDU>
you write:
  > # of expected passes		3192
  > # of unexpected failures	56
  > # of unexpected successes	2
  > # of expected failures		95
  > # of untested testcases		10
  > 
  > g++.log and gcc.log are available for interested parties by anon. ftp at 
  > niobium.mps.ohio-state.edu (gzipped). If any other info is needed please 
  > let me know.
Thanks.  I think I see the problem.

It appears that you're picking up include files from /usr/include/g++,
and for whatever reason they are not compatable with the current
compiler.

I believe this is a bug in the dejagnu framework since it should
be providing appropriate overriding -I arguments so that you pick
up include files from the source directory itself rather than the
previously installed include files.  To be sure I need a little more
information:

Did you build the entire tree -- in particular, did you build libstdc++
and libio?

What are the contents of your $objdir/libio (just the ls output is
fine).


Jeff

Re: Here are the g++ test results

[Mumit Khan]

djohnson@mps.ohio-state.edu writes:
> Hi,
> 	Steven's results are the same as what I get with Linux 2.0.28, 
> libc 5.4.33, ld.so 1.9.2, dejagnu-970707.

[ lots of unexpted failures ... ]

I just downloaded your logs for g++ and gcc, and now it makes sense why
you and Steven might be getting all those failures. Note the references 
to /usr/include/g++ in your log files, which means that you're using 
iostream from libg++-2.7.[12], and not from the newer libio supplied
with egcs-970825! Also Note that the compile flags don't include the 
libio includes from the source tree, and since I had already installed 
mine, it found the right ones anyway. I suggest you do a 'make install' 
and then re-run the tests, and then we can compare notes again.

HJ Lu says in a followup that he has some i386-linux-gnulibc1 patches
for libio/libstdc++. However, sine his test run gives the same results 
as mine, hopefuly his patches cover areas that the test cases don't.

Regards,
Mumit -- khan@xraylith.wisc.edu
http://www.xraylith.wisc.edu/~khan/

Re: Here are the g++ test results

[H.J. Lu]

> 
> Hi,
> 	Steven's results are the same as what I get with Linux 2.0.28, 
> libc 5.4.33, ld.so 1.9.2, dejagnu-970707.
> 
> Test Run By djohnson on Mon Aug 25 22:46:37 1997
> Target is i586-pc-linux-gnulibc1
> Host   is i586-pc-linux-gnu
> 		=== g++ Summary ===
> 
> # of expected passes		3192
> # of unexpected failures	56
> # of unexpected successes	2
> # of expected failures		95
> # of untested testcases		10
> 

If you are using Linux, please wait for my Linux patch. Here
are what you should get on x86-linux and x86-linux-gnulibc1.

		=== g++ Summary ===

# of expected passes		3262
# of unexpected successes	2
# of expected failures		81
# of untested testcases		10


H.J.

Re: Here are the g++ test results

[djohnson]

Hi,
	Steven's results are the same as what I get with Linux 2.0.28, 
libc 5.4.33, ld.so 1.9.2, dejagnu-970707.

Test Run By djohnson on Mon Aug 25 22:46:37 1997
Target is i586-pc-linux-gnulibc1
Host   is i586-pc-linux-gnu
		=== g++ Summary ===

# of expected passes		3192
# of unexpected failures	56
# of unexpected successes	2
# of expected failures		95
# of untested testcases		10

g++.log and gcc.log are available for interested parties by anon. ftp at 
niobium.mps.ohio-state.edu (gzipped). If any other info is needed please 
let me know.

Doug

On Tue, 26 Aug 1997, Mumit Khan wrote:

> "Steven J. Madsen" <steve@moonglade.com> writes:
> > Again, PPro 200, Linux 2.0.30, libc 5.4.37, binutils 2.8.1.0.15, ld.so
> > 1.9.5:
> > 
> >                 === g++ Summary ===
> > 
> > # of expected passes            3192
> > # of unexpected failures        56
> > # of unexpected successes       2
> > # of expected failures          95
> > # of untested testcases         10
> > /home/steve/ftp/egcs-970825/gcc/testsuite/../xgcc version egcs-2.90.02
> > 970825 (gcc2-970802 experimental)
> > 
> > -- 
> 
> Yikes! egcs-970825 does much better even on an HP-PA ;-)
> 
> Something not quite right here! Here're the results from my Ppro 200/128M
> RedHat 4.1 machine (libc 5.3.12, ld.so 1.7.14, binutils 2.7):
> 
> # of expected passes		3262
> # of unexpected successes	2
> # of expected failures		81
> # of untested testcases		10
> 
> Can you take a look at the g++.log (in gcc/testsuite) file to see what's
> going on for some of these unexpected failures? btw, I'm using the dejagnu
> 970707 snapshot from ftp://ftp.cygnus.com/pub/egcs/infrastructure , not the 
> released version.
> 
> Regards,
> Mumit -- khan@xraylith.wisc.edu
> http://www.xraylith.wisc.edu/~khan/
> 

Re: Here are the g++ test results

[Mumit Khan]

"Steven J. Madsen" <steve@moonglade.com> writes:
> Again, PPro 200, Linux 2.0.30, libc 5.4.37, binutils 2.8.1.0.15, ld.so
> 1.9.5:
> 
>                 === g++ Summary ===
> 
> # of expected passes            3192
> # of unexpected failures        56
> # of unexpected successes       2
> # of expected failures          95
> # of untested testcases         10
> /home/steve/ftp/egcs-970825/gcc/testsuite/../xgcc version egcs-2.90.02
> 970825 (gcc2-970802 experimental)
> 
> -- 

Yikes! egcs-970825 does much better even on an HP-PA ;-)

Something not quite right here! Here're the results from my Ppro 200/128M
RedHat 4.1 machine (libc 5.3.12, ld.so 1.7.14, binutils 2.7):

# of expected passes		3262
# of unexpected successes	2
# of expected failures		81
# of untested testcases		10

Can you take a look at the g++.log (in gcc/testsuite) file to see what's
going on for some of these unexpected failures? btw, I'm using the dejagnu
970707 snapshot from ftp://ftp.cygnus.com/pub/egcs/infrastructure , not the 
released version.

Regards,
Mumit -- khan@xraylith.wisc.edu
http://www.xraylith.wisc.edu/~khan/

Here are the g++ test results

[Steven J. Madsen]

Again, PPro 200, Linux 2.0.30, libc 5.4.37, binutils 2.8.1.0.15, ld.so
1.9.5:

                === g++ tests ===

Using /usr/local/bin/../share/dejagnu/baseboards/unix.exp as board
description file for target.
Using /usr/local/bin/../share/dejagnu/config/unix.exp as generic interface
file for target.
Using /home/steve/ftp/egcs-970825/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
WARNING: Assuming target board is the local machine (which is probably
wrong).
You may need to set your DEJAGNU environment variable.
Running /home/steve/ftp/egcs-970825/gcc/testsuite/g++.old-deja/old-deja.exp
...
FAIL: g++.brendan/copy9.C (test for excess errors)
FAIL: g++.brendan/crash15.C (test for excess errors)
FAIL: g++.brendan/crash30.C (test for excess errors)
FAIL: g++.brendan/crash38.C (test for excess errors)
FAIL: g++.brendan/crash49.C (test for excess errors)
FAIL: g++.brendan/crash52.C (test for excess errors)
FAIL: g++.brendan/crash62.C (test for excess errors)
FAIL: g++.brendan/cvt1.C (test for excess errors)
FAIL: g++.brendan/err-msg3.C (test for excess errors)
FAIL: g++.brendan/nest21.C (test for excess errors)
FAIL: g++.brendan/ptolemy2.C (test for excess errors)
XPASS: g++.brendan/scope4.C (test for excess errors)
FAIL: g++.brendan/template9.C (test for excess errors)
FAIL: g++.jason/template24.C (test for excess errors)
FAIL: g++.jason/template31.C (test for excess errors)
FAIL: g++.jason/typeid1.C (test for excess errors)
FAIL: g++.law/arg1.C (test for excess errors)
FAIL: g++.law/arg8.C (test for excess errors)
FAIL: g++.law/arm12.C (test for excess errors)
FAIL: g++.law/arm9.C (test for excess errors)
FAIL: g++.law/bad-error7.C (test for excess errors)
FAIL: g++.law/ctors10.C (test for excess errors)
FAIL: g++.law/ctors13.C (test for excess errors)
FAIL: g++.law/ctors17.C (test for excess errors)
FAIL: g++.law/cvt16.C (test for excess errors)
FAIL: g++.law/cvt7.C (test for excess errors)
FAIL: g++.law/missed-error2.C (test for excess errors)
FAIL: g++.law/nest3.C (test for excess errors)
FAIL: g++.law/operators32.C (test for excess errors)
FAIL: g++.law/operators33.C (test for excess errors)
FAIL: g++.law/refs1.C (test for excess errors)
FAIL: g++.law/vbase1.C (test for excess errors)
FAIL: g++.law/virtual3.C (test for excess errors)
FAIL: g++.law/visibility10.C (test for excess errors)
FAIL: g++.law/visibility13.C (test for excess errors)
FAIL: g++.law/visibility17.C (test for excess errors)
FAIL: g++.law/visibility25.C (test for excess errors)
FAIL: g++.law/visibility7.C (test for excess errors)
FAIL: g++.mike/eh12.C  Execution test
FAIL: g++.mike/eh14.C  Execution test
FAIL: g++.mike/eh18.C  Execution test
FAIL: g++.mike/eh2.C  Execution test
FAIL: g++.mike/eh23.C  Execution test
FAIL: g++.mike/eh25.C  Execution test
FAIL: g++.mike/eh26.C  Execution test
FAIL: g++.mike/eh27.C  Execution test
FAIL: g++.mike/eh28.C  Execution test
FAIL: g++.mike/eh3.C  Execution test
FAIL: g++.mike/eh31.C  Execution test
FAIL: g++.mike/eh47.C  Execution test
FAIL: g++.mike/eh55.C  Execution test
FAIL: g++.mike/net34.C (test for excess errors)
FAIL: g++.mike/net46.C (test for excess errors)
FAIL: g++.mike/p658.C (test for excess errors)
XPASS: g++.mike/p7325.C *-*-* Execution test
FAIL: g++.mike/p7912.C  Execution test
FAIL: g++.mike/p9706.C  Execution test
FAIL: g++.mike/rtti1.C (test for excess errors)

                === g++ Summary ===

# of expected passes            3192
# of unexpected failures        56
# of unexpected successes       2
# of expected failures          95
# of untested testcases         10
/home/steve/ftp/egcs-970825/gcc/testsuite/../xgcc version egcs-2.90.02
970825 (gcc2-970802 experimental)

-- 
Steve Madsen  <steve@moonglade.com>              PGP key available