Bug 138791 - gcc 3.4 with default flags miscompile lapack/octave, needs extra flags
gcc 3.4 with default flags miscompile lapack/octave, needs extra flags
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: lapack (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Ivana Varekova
https://bugzilla.redhat.com/bugzilla/...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-11 01:39 EST by Dmitri A. Sergatskov
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-12-07 03:23:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dmitri A. Sergatskov 2004-11-11 01:39:41 EST
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@redhat.com has
more elaborate suggestions.
Comment 1 Dmitri A. Sergatskov 2004-11-12 02:24:31 EST
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 10:15:40 EST
Thank you for your notices.
The problem was fixed.
Ivana Varekova
Comment 3 Ivana Varekova 2004-12-07 03:23:14 EST
 Solved with -27, closing now.

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