This is the mail archive of the
mailing list for the GCC project.
Re: Lapack tester
- From: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- To: Thomas Koenig <tkoenig at netcologne dot de>
- Cc: "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>, gcc at gcc dot gnu dot org
- Date: Wed, 18 Jan 2012 12:16:52 -0800
- Subject: Re: Lapack tester
- References: <4F171ED1.email@example.com>
On Wed, Jan 18, 2012 at 08:34:41PM +0100, Thomas Koenig wrote:
> I have set up a semi-automatic lapack tester on
> powerpc64-unknown-linux-gnu (gcc110 on the gcc compile farm).
> It downloads the current trunk, compiles it, then uses that
> compiler to compile the reference BLAS and Lapack and run the LAPACK
> test suite, cycling through the Lapack build with different compiler
> An example of the results is at
> It is inexpensive to add another set of options to the scripts.
> If there is interest, I could easily do so.
> I have found one problem, PR 51751, which could also be an upstream bug.
PR 51751 seems to concern only complex*16 failures. Have
you had a chance to look at the real and double precision
Being semi-automatic, can you run the timing tests, too? These
would obviously reveal possible performance regressions. It
would also be interesting to see if -ftree-vectorize helps
Against my better judgement, I'll suggest a run with
'-O3 -ffast-math'. It seems a large number of gfortran
users use -ffast-math.