Red Hat Bugzilla – Bug 59137
problem with - ZGGEV: Complex generalised eigenvalue computation
Last modified: 2007-04-18 12:39:38 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901
Description of problem:
The problem is caused by compiling part of the LAPACK code using the g77
compiler with optimisation switched on.
Specifically, ZGGEV calls ZHGEQZ.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Further info to be submitted by customer
Actual Results: Results on the problem will be submitted
Expected Results: as above
I extracted the source of ZHGEQZ and compiled it separately using g77 version
2.96 as supplied as standard with RH 7.2. Levels of optimisation -O2 and -O3
cause the problem. This may not be the complete problem, but it is certainly a
large part of it.
My guess is that the distribution of LAPACK and BLAS use the optimisation.
Right now, no problem is given.... Yes, the package is compiled with
optimization. Information about archictecture, name-version-release and a test
program (with output - expected and actual), are needed.
I am the originator of this problem. I will send details and sample code. John Fletcher
Created attachment 44256 [details]
FORTRAN source of test program to call zggev and demonstrate the problem
Created attachment 44257 [details]
Test data to run with the program
Created attachment 44258 [details]
Output from test - case1 compiles as g77 testzggev.f -otest1 -llapack
Created attachment 44259 [details]
Output from test case2 compiled as g77 testzggev.f zggev.o zhgeqz.o -ocase2 -llapack
Equipment used Dell Pentium IV PC running Red Hat 7.2.
GCC 2.96 as supplied with RH 7.2
LAPACK library as supplied with RH 7.2
For test1 the library is linked directly.
For test2 the source code of the routines ZGGEV.F and ZHGEQZ.F have been extracted from the source rpm
supplied with RH 7.2 and compiled without optimisation.
g77 -c zggev.f
g77 -c zhgeqz.f
The bug is that the output eigenvalues from the two tests are different.
The difference starts in line 5 with a small discrepance and propagates.
Further testing shows that the results from test1 are not consistent when the eigenvalues are multiplied back with the eigenvectors.
The only way I can account for this is that the optimisation operations of the compiler are the cause.
Please let me know if you need more information.
Why has the status not changed from NEEDINFO to reflect the information I supplied several days ago? Do I need to take action on this?
Is it possible to supply a version compiled with GCC 3.0x for me to test at this end?
I have done two further sets of tests.
(a) I have linked both cases with -lblas -static to see if that caused the problem.
It makes no difference to either case.
(b) I have compiled testzggev.f and linked it with the Intel MKL lapack and blas.
The output coincides with test case2, i.e. with the case where the routines
zggev.f and zhgeqz.f are compiled locally.
This all points to a problem with the lapack library as supplied with RH 7.2
It changes automatically when the poster adds info to a NEEDINFO bug, which
didn't quite cover your case.
It's fixed in lapack-3.0-13 (Rawhide), looking into it in more detail
I now have the 3.0-13 rpms and will check it out. Thank you. John
I have now tested as follows using lapack 3.0-13 and blas 3.0-13. gcc is 2.96-98. System is RH 7.2 on Intel.
g77 testzggev -otestzggev -llapack
testzggev < use30.dat > test13.out
This runs and gives the same answers as test2.out above which I believe to be correct.
g77 testzggev.f -otestzggevs -llapack -lblas -static
testzggevs < use30.dat
This runs and gives a segmentation fault before running the calculation.
The library referred to is not binary compatible with RHL 7.2 - it's still open.
We seem to be close on this one. I grabbed the source rpm for lapack from the
rawhide directory, rebuilt and then upgraded a 7.2 system. Here are the results:
[root@londo fmhirtz]# rpm -q blas
[root@londo fmhirtz]# rpm -q lapack
[root@londo fmhirtz]# g77 testzggev.f -otestzggev -llapack
[root@londo fmhirtz]# g77 testzggev.f -otestzggevs -llapack -lblas -static
[root@londo fmhirtz]# ./testzggev < use30.dat > test1.out
[root@londo fmhirtz]# ./testzggevs < use30.dat > test2.out
[root@londo fmhirtz]# diff -a test1.out test2.out
< 6 (0.448909422,-1197.31847) (10.270903,0.) (0.0437069089,-116.573827)
> 6 (0.448909428,-1197.31847) (10.270903,0.) (0.0437069095,-116.573827)
This was the only difference in the output from the two different versions.
3.0-13 has no code changes at all. It's just rebuilt with our current
development compiler (which is a bit experimental ATM). Reassigning as compiler
problem, will attach the LAPACK files in question.
Created attachment 45759 [details]
Created attachment 45760 [details]
Still a problem with gcc-2.96-109
Identical results with gcc-g77-3.2.3-20, lapack-3.0-20.