From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041020 Firefox/0.10.1 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): lapack-3.0-25, octave-2.1.57-7 How reproducible: Always Steps to Reproduce: 1.run octave 2.at the octave prompt: a=rand(100); tic; eig(a); toc 3. 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. Additional info: 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. jakub 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 program xxx 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) enddo call dgeev (jobvl, jobvr, n, a, n, wr, wi, vl, ldvl, vr, ldvr, $ work, lwork, info) print *, 'dgeev info: ', info end (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 [dima@localhost test1]$ ------------------------- 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. Sincerely, Dmitri.
Thank you for your notices. The problem was fixed. Ivana Varekova
Solved with -27, closing now.