Red Hat Bugzilla – Bug 138791
gcc 3.4 with default flags miscompile lapack/octave, needs extra flags
Last modified: 2007-11-30 17:10:54 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041020
Description of problem:
Current versions of gcc-3.4 miscompiles lapack/octave combination,
so some itterative functions fail to converge (or converge
very slow -- more then 100 time slow then in e.g. FC2).
See bug 138683 for more details and possible solution/workaround.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
2.at the octave prompt: a=rand(100); tic; eig(a); toc
Actual Results: It either takes forever (many minutes) or aborts
with an error.
Expected Results: It should print "0.04" (i.e. 40 millisecond), or
about, on any reasonably modern hardware.
All this problems are on Athlon-XP platforms. I do not have
genuine Intel system to check it. (athlon-xp/2000MHz/500Meg)
My workaround was to recompile both lapack and octave with
FFLAGS="-O2 -ffloat-store". That solves the problem and does not
show any measurable slowdown to my programs. firstname.lastname@example.org has
more elaborate suggestions.
This is a small test problem that demostrates the problem. Linked with
default lapack it hangs. Linked with lapack rebuilt with
FFLAGS="-ffloat-store" it executes as expected.
[dima@localhost test1]$ cat xxx.f
character*1 jobvl, jobvr
integer n, ldvl, ldvr, lwork
parameter (jobvl='N', jobvr='N')
parameter (n = 3, ldvl = 3, ldvr = 3, lwork = 9)
double precision a(n,n)
double precision wr(n)
double precision wi(n)
double precision vl(ldvl,n)
double precision vr(ldvr,n)
double precision work(lwork)
integer info, i, j
data a /1.0d0, 4.0d0, 7.0d0,
$ 2.0d0, 5.0d0, 8.0d0,
$ 3.0d0, 6.0d0, 9.0d0/
do i = 1, n
print *, (a(i,j), j = 1, n)
call dgeev (jobvl, jobvr, n, a, n, wr, wi, vl, ldvl, vr, ldvr,
$ work, lwork, info)
print *, 'dgeev info: ', info
(linking with good libraries)
[dima@localhost test1]$ g77 xxx.f -llapack -lblas
[dima@localhost test1]$ ./a.out
1. 2. 3.
4. 5. 6.
7. 8. 9.
(with shipped libraries it hangs here)
dgeev info: 0
It appears to me that if some code needs to be compiled with special
flags to produce a correct output then either code has a bug or
compiler is non-conformant. -ffloat-store looks like a workaround
rather than a solution.
Thank you for your notices.
The problem was fixed.
Solved with -27, closing now.