Re: GCC 3.0 Release Criteria

[Toon Moene <toon at moene dot indiv dot nluug dot nl>]

Mark Mitchell wrote:

> >>>>> "Jonathan" == Jonathan Thornburg <jthorn@galileo.thp.univie.ac.at> writes:

>     Jonathan> I'm surprised to see LAPACK 2.0 (dated 30 Sept 1994
>     Jonathan> according to the Netlib web site) specified, when LAPACK
>     Jonathan> 3.0update is available (dated 31 Oct 1999).  Is there a
>     Jonathan> deep reason for this?
> 
> Yes.  Our Fortran maintainer indicated that GCC 2.95.x did not work
> with LAPACK 3.0.  I don't know that anyone has worked on solving those
> problems yet.  GCC 3.0 will be monotonically no worse that GCC 2.95.x;
> there's no guarantee that all open issues will be resolved.

As I've already explained, this was slack on my side - I'm sorry about
that.

I've come a bit further towards releasing testing criteria w.r.t.
LAPACK-3.0 and g77-3.0.

First of all, the Segmentation Violations due to too large arrays in
main programs are all in "timing" programs.  So my suggestion would be
to limit ourselves to the "testing" programs of LAPACK to do g77
testing.  Of course, those with > 0.5 Gbyte RAM workstations are invited
to spend cycles on the "timing" programs (Hi, Philipp !).

Furthermore, to run the LAPACK testing programs as a form of g77
testing, some things have to be done.

1. Some changes have to made to the top level Makefile (and include file 
   for the Makefile) as distributed in lapack-3.0.tgz.

2. To successfully run two or more tests of the lapack test suite,
   a specific series of shell commands has to be issued.

Mark, I need to indicate the above somewhere on the gcc-3.0 release
criteria list.  Please indicate an appropriate place.

AFAICS, lapack-3.0 compiled with gcc/g77-2.95.2 on i686-pc-linux-gnu
runs OK; here's the list of "failed" messages coming out of the testing
programs:

./BLAS/zblat1.out:                                       FAIL
./TESTING/ssep.out: SST drivers:      1 out of  14256 tests failed to
pass the threshold
./TESTING/ssep.out: SST:    1 out of  4662 tests failed to pass the
threshold
./TESTING/ssep.out: SST drivers:      1 out of  14256 tests failed to
pass the threshold
./TESTING/sgd.out: SXV drivers:     37 out of   5000 tests failed to
pass the threshold
./TESTING/csep.out: CST:    1 out of  4662 tests failed to pass the
threshold
./TESTING/csep.out: CST drivers:      2 out of  11664 tests failed to
pass the threshold
./TESTING/cgd.out: CGV drivers:      4 out of   1092 tests failed to
pass the threshold
./TESTING/dgd.out: DXV drivers:    200 out of   5000 tests failed to
pass the threshold
./TESTING/zgd.out: ZGV drivers:      4 out of   1092 tests failed to
pass the threshold
./TESTING/zgd.out: ZXV drivers:     24 out of   5000 tests failed to
pass the threshold

Last - for reference with gcc/g77-2.95.2 - the lapack-3.0 test suite
does not compile on Alpha (and probably all other 64 bit targets) unless
the compile time flag -femulate-complex is specified.  This should have
been repaired in the upcoming release (i.e. a snapshot *should* compile
lapack without -femulate-complex).

Finally, trying to run the testsuite on alphaev6-unknown-linux-gnu with
gcc-2.95.2 *and* -femulate-complex got me into the following trouble:

Program received signal SIGFPE, Arithmetic exception.
ieeeck_ (ispec=0x200ea698, zero=0x200ea69c, one=0x200ea6a0) at
ieeeck.f:50
50            IF( POSINF.LE.ONE ) THEN
Current language:  auto; currently fortran

This is probably due to a denormal floating point number.  If that
cannot be repaired in the lapack sources, we have to compile with -mieee
on Alpha's.

Hope this helps - more info tomorrow,

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://xena.eas.asu.edu/~andy (under construction)