Bug 138791

Summary: gcc 3.4 with default flags miscompile lapack/octave, needs extra flags
Product: [Fedora] Fedora Reporter: Dmitri A. Sergatskov <dasergatskov>
Component: lapackAssignee: Ivana Varekova <varekova>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
URL: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138683
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-12-07 08:23:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Dmitri A. Sergatskov 2004-11-11 06:39:41 UTC 
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.
Comment 1 Dmitri A. Sergatskov 2004-11-12 07:24:31 UTC 
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.
Comment 2 Ivana Varekova 2004-11-30 15:15:40 UTC 
Thank you for your notices.
The problem was fixed.
Ivana Varekova
Comment 3 Ivana Varekova 2004-12-07 08:23:14 UTC 
 Solved with -27, closing now.