Bug 59137 - problem with - ZGGEV: Complex generalised eigenvalue computation
problem with - ZGGEV: Complex generalised eigenvalue computation
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: gcc (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-01-31 12:05 EST by Malcolm
Modified: 2007-04-18 12:39 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-02 15:15:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
FORTRAN source of test program to call zggev and demonstrate the problem (2.06 KB, text/plain)
2002-02-01 09:23 EST, Need Real Name
no flags Details
Test data to run with the program (5.81 KB, text/plain)
2002-02-01 09:24 EST, Need Real Name
no flags Details
Output from test - case1 compiles as g77 testzggev.f -otest1 -llapack (3.28 KB, text/plain)
2002-02-01 09:26 EST, Need Real Name
no flags Details
Output from test case2 compiled as g77 testzggev.f zggev.o zhgeqz.o -ocase2 -llapack (3.28 KB, text/plain)
2002-02-01 09:29 EST, Need Real Name
no flags Details
LAPACK routine (14.35 KB, text/plain)
2002-02-14 18:32 EST, Trond Eivind Glomsrxd
no flags Details
LAPACK routine (25.21 KB, patch)
2002-02-14 18:33 EST, Trond Eivind Glomsrxd
no flags Details | Diff

  None (edit)
Description Malcolm 2002-01-31 12:05:34 EST
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):


How reproducible:
Always

Steps to Reproduce:
1.Further info to be submitted by customer
2.
3.
	

Actual Results:  Results on the problem will be submitted

Expected Results:  as above

Additional info:

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.
Comment 1 Trond Eivind Glomsrxd 2002-01-31 12:09:56 EST
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.
Comment 2 Need Real Name 2002-02-01 05:58:59 EST
I am the originator of this problem. I will send details and sample code. John Fletcher
Comment 3 Need Real Name 2002-02-01 09:23:20 EST
Created attachment 44256 [details]
FORTRAN source of test program to call zggev and demonstrate the problem
Comment 4 Need Real Name 2002-02-01 09:24:38 EST
Created attachment 44257 [details]
Test data to run with the program
Comment 5 Need Real Name 2002-02-01 09:26:31 EST
Created attachment 44258 [details]
Output from test - case1 compiles as g77 testzggev.f -otest1 -llapack
Comment 6 Need Real Name 2002-02-01 09:29:11 EST
Created attachment 44259 [details]
Output from test case2 compiled as g77 testzggev.f zggev.o zhgeqz.o -ocase2 -llapack
Comment 7 Need Real Name 2002-02-01 09:36:17 EST
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
Comment 8 Need Real Name 2002-02-07 06:27:55 EST
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?
Comment 9 Need Real Name 2002-02-07 08:35:58 EST
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
Comment 10 Trond Eivind Glomsrxd 2002-02-07 10:33:58 EST
It changes automatically when the poster adds info to a NEEDINFO bug, which
didn't quite cover your case.
Comment 11 Trond Eivind Glomsrxd 2002-02-07 11:31:38 EST
It's fixed in lapack-3.0-13 (Rawhide), looking into it in more detail
Comment 12 Need Real Name 2002-02-13 06:37:46 EST
I now have the 3.0-13 rpms and will check it out.  Thank you. John
Comment 13 Need Real Name 2002-02-13 08:23:35 EST
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.

Comment 14 Trond Eivind Glomsrxd 2002-02-13 11:00:54 EST
The library referred to is not binary compatible with RHL 7.2 - it's still open.
Comment 15 Frank Hirtz 2002-02-14 11:56:16 EST
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.
Comment 16 Trond Eivind Glomsrxd 2002-02-14 18:29:10 EST
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.
Comment 17 Trond Eivind Glomsrxd 2002-02-14 18:32:46 EST
Created attachment 45759 [details]
LAPACK routine
Comment 18 Trond Eivind Glomsrxd 2002-02-14 18:33:36 EST
Created attachment 45760 [details]
LAPACK routine
Comment 19 Trond Eivind Glomsrxd 2002-04-04 17:25:34 EST
Still a problem with gcc-2.96-109
Comment 20 Richard Henderson 2004-10-02 15:15:44 EDT
Identical results with gcc-g77-3.2.3-20, lapack-3.0-20.

Note You need to log in before you can comment on or make changes to this bug.