Bug 59137
|
Description
Malcolm
2002-01-31 17:05:34 UTC
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. John Fletcher 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
blas-3.0-12
[root@londo fmhirtz]# rpm -q lapack
lapack-3.0-13
[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
73c73
< 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]
LAPACK routine
Created attachment 45760 [details]
LAPACK routine
Still a problem with gcc-2.96-109 Identical results with gcc-g77-3.2.3-20, lapack-3.0-20. |