Re: gcc 3.4 and Octave/lapack problems

[Dmitri A. Sergatskov]

address@hidden wrote:

> The problem is that -ffloat-store can really slow things down.  Dmitri
> observed a 20% slowdown in Octave using -ffloat-store everywhere.  I saw
  ^^^^^^^^^^^^^^^^^^^^^^^^

I noticed a slowdown with for loop in octave interpreter. But that of little 
importance
(since it is slow anyway). I do not see _any_
slowdown with functions which call some lapack or fft routines. In fact some of
the lapack routines (schur() e.g.) run faster (I guess they converge faster).
I still believe that this is a gcc bug/problem, but gcc people will not
talk to me unless I provide them a simple code sample. I have a simple code that
demonstrate the problem in lapack (see below), but that opens to interpretation 
that
this is a lapack problem.

Dmitri.
p.s. The following code linked with lapack shipped with FedoraCore 3 hangs for 
at least
few minutes:

address@hidden 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, lda, wr, wi, vl, ldvl, vr, ldvr,
     $ work, lwork, info)
      print *, 'dgeev info: ', info
      end
address@hidden test1]$ g77 xxx.f -llapack -lblas
address@hidden test1]$ ./a.out
  1.  2.  3.
  4.  5.  6.
  7.  8.  9.