libjava holding regression tester hostage

[Mike Stump]

The libjava failure:

FAIL: Array_3 -O3 execution - bytecode->native test
Running  
/Users/regress/tbox/cvs-gcc/gcc/libjava/testsuite/libjava.loader/ 
loader.exp ...
Running  
/Users/regress/tbox/cvs-gcc/gcc/libjava/testsuite/libjava.mauve/ 
mauve.exp ...
Running  
/Users/regress/tbox/cvs-gcc/gcc/libjava/testsuite/libjava.verify/ 
verify.exp ...

		=== libjava Summary ===

# of expected passes		3786
# of unexpected failures	1
# of expected failures		10
# of untested testcases		9
make[3]: *** [check-DEJAGNU] Error 1
make[2]: *** [check-am] Error 2
make[1]: *** [check-recursive] Error 1
make: *** [check-target-libjava] Error 2

appears to be holding the regression tester hostage.  :-(  This is  
stupid/bad.  I researched it, and it does this because automake  
generates:

libjava/testsuite/Makefile.in:

check-DEJAGNU: site.exp
         srcdir=`$(am__cd) $(srcdir) && pwd`; export srcdir; \
         EXPECT=$(EXPECT); export EXPECT; \
         runtest=$(RUNTEST); \
         if $(SHELL) -c "$$runtest --version" > /dev/null 2>&1; then \
           l='$(DEJATOOL)'; for tool in $$l; do \
             $$runtest $(AM_RUNTESTFLAGS) $(RUNTESTDEFAULTFLAGS)  
$(RUNTESTFLAGS); \
           done; \
         else echo "WARNING: could not find \`runtest'" 1>&2; :;\
         fi

but, this is wrong, it doesn't have a - on the front of the runtest  
command, so it propagates `normal' testsuite failures all the way up to  
the return status of make, which, we decided a while ago not to do.   
Now, if libjava always just works, maybe we could take a pass on it...   
but, if it doesn't, we should find some way to ignore the return code  
from runtest.