This is the mail archive of the
gcc@gcc.gnu.org
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.7080001@netcologne.de>
On Wed, Jan 18, 2012 at 08:34:41PM +0100, Thomas Koenig wrote:
> Hello,
>
> 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
> options.
>
> An example of the results is at
>
> http://gcc.gnu.org/ml/gcc-testresults/2012-01/msg01757.html
>
> 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
errors?
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
performance.
Against my better judgement, I'll suggest a run with
'-O3 -ffast-math'. It seems a large number of gfortran
users use -ffast-math.
--
Steve