gcc 3.4 and Octave/lapack problems

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

gcc 3.4 and Octave/lapack problems

Dmitri A. Sergatskov-2
I was playing with freshly released Fedora Core 3 and noticed that
the Octave (2.1.57) included with this distribution has a problem with
some lapack functions. In particular:

octave:1> a=rand(100);
octave:2> tic; eig(a); toc
error: dgeev failed to converge
octave:2>

It is quite reproducible, except sometimes it hangs for few minutes and I kill
it (Ctrl-C) before the error show up.
The Octave in FC3 is compiled against reference lapack-3.

I removed octave,lapack and blas and compiled my own version of octave
(both 2.157 and 2.1.61 versions) against ATLAS (which I compile myself as well).
I used "-O2 -march=athlon-xp" flags.
The result was the same.

Finally, the solution was to use FFLAGS="-O2 -ffloat-store -march-athlon-xp".
There were multiple discussions that -ffloat-store slows things down,
but so far I have not noticed any. In fact some procedures run almost
20% faster (schur()) -- I assume it is iterative and now converges faster.

I filed this problem to redhat as a bug against gcc
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138683
and Jakub Jelinek responded that:

<<<<
        For code that relies on computation not being done with extra
        precision -ffloat-store is a must and lapack clearly relies on it.
        Why things worked in this particular case with < GCC 3.4 and don't work anymore
        is most probably because GCC is now better at optimizing and likely will have
        less spills to memory (and only spills to memory on the mis-designed i387 FPU
        round to the declared precision instead of using full long double precision).
 >>>>

He also promised to look at the code (dgeev.f and perhaps other?) which causes the
problem, but it is hard for me to figure out all parameters it is called with, so
perhaps somebody can help me with it.

Also, if -ffloat-store indeed the must for lapack/octave, should we make it a default?

Any help and insightful thoughts would be greatly appreciated.

Sincerely,

Dmitri.
--


Reply | Threaded
Open this post in threaded view
|

gcc 3.4 and Octave/lapack problems

John W. Eaton-6
On 11-Nov-2004, Dmitri A. Sergatskov <[hidden email]> wrote:

| Also, if -ffloat-store indeed the must for lapack/octave, should we
| make it a default?

It seems like this might be a reasonable change to make.  We'll need a
configure check since -ffloat-store probably only makes sense for
gcc/g++/g77.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: gcc 3.4 and Octave/lapack problems

Dmitri A. Sergatskov-2
John W. Eaton wrote:
> On 11-Nov-2004, Dmitri A. Sergatskov <[hidden email]> wrote:
>
> | Also, if -ffloat-store indeed the must for lapack/octave, should we
> | make it a default?
>
> It seems like this might be a reasonable change to make.  We'll need a
> configure check since -ffloat-store probably only makes sense for
> gcc/g++/g77.

I guess one of the questions weather we shall pass it to g77 only
(at the moment that looks sufficient), or to all three?
I noticed that loop performance drops some 20% if I have
it in CXXFLAGS. I do not see any difference if CFLAGS have
it or not.

Any insights?

>
> jwe
>

Dmitri.
--


Reply | Threaded
Open this post in threaded view
|

Re: gcc 3.4 and Octave/lapack problems

John W. Eaton-6
On 11-Nov-2004, Dmitri A. Sergatskov <[hidden email]> wrote:

| John W. Eaton wrote:
| > On 11-Nov-2004, Dmitri A. Sergatskov <[hidden email]> wrote:
| >
| > | Also, if -ffloat-store indeed the must for lapack/octave, should we
| > | make it a default?
| >
| > It seems like this might be a reasonable change to make.  We'll need a
| > configure check since -ffloat-store probably only makes sense for
| > gcc/g++/g77.
|
| I guess one of the questions weather we shall pass it to g77 only
| (at the moment that looks sufficient), or to all three?
| I noticed that loop performance drops some 20% if I have
| it in CXXFLAGS. I do not see any difference if CFLAGS have
| it or not.
|
| Any insights?

If we are going to use -ffloat-store for Fortran code because it
produces better results (or at least results that are more likely to
agree with what we would expect from 64-bit IEEE floating point
arithmetic) then it seems to me that we should use it for the C and
C++ code as well.  Or maybe you would prefer to have bad results
faster?  :-)

I've made changes to configure so that we check to see if the
compilers accept -ffloat-store, but only on x86 platforms when using
platforms when using the GNU compilers (individual checks are made for
each).

jwe


Reply | Threaded
Open this post in threaded view
|

Re: gcc 3.4 and Octave/lapack problems

Dmitri A. Sergatskov-2
John W. Eaton wrote:

>
> If we are going to use -ffloat-store for Fortran code because it
> produces better results (or at least results that are more likely to
> agree with what we would expect from 64-bit IEEE floating point
> arithmetic) then it seems to me that we should use it for the C and
> C++ code as well.  Or maybe you would prefer to have bad results
> faster?  :-)

I really do not quite understand all this, but here is some thoughts:

If I follow this logic then one needs to use -ffloat-store _always_.
Which means that gcc is broken. This is being disputed by
Jakub... It seems to me that the issue is only with one (or may be few)
of the lapack (fortran) files and this -ffloat-store is more a
workaround for the bug(?) in lapack code. In that case I do not
see why would we need this switch for C and C++. Perhaps we need to talk
to lapack people. I did file a bug to Redhat against lapack, but
have not heard back yet...

I still suspect that recent gcc with aggressive optimization
is not being ISO-complaint. (Apparently ISO C forbids  excess precision
after an explicit conversion to double (cast or affectation)).
But I cannot come up with the a simple sample code that demonstrates
this problem.

>
> jwe
>

Dmitri.
--


Reply | Threaded
Open this post in threaded view
|

Re: gcc 3.4 and Octave/lapack problems

Dmitri A. Sergatskov-2
In reply to this post by John W. Eaton-6
BTW, according to  Jakub Jelinek
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138683)

<<<<
...
        IMHO you want to open a bug against lapack (and/or octave) and request that
        it be compiled in two versions on IA-32: -ffloat-store and -mfpmath=sse -msse2
        (the latter for P4 & recent AMD CPUs).
...
 >>>>

Dmitri.
--


Reply | Threaded
Open this post in threaded view
|

Re: gcc 3.4 and Octave/lapack problems

John W. Eaton-6
On 11-Nov-2004, Dmitri A. Sergatskov <[hidden email]> wrote:

| BTW, according to  Jakub Jelinek
| (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138683)
|
| <<<<
| ...
| IMHO you want to open a bug against lapack (and/or octave) and request that
| it be compiled in two versions on IA-32: -ffloat-store and -mfpmath=sse -msse2
| (the latter for P4 & recent AMD CPUs).
| ...
|  >>>>

If we have to know whether we are using a P4 or some recent AMD CPU
(how recent, what does that mean?) to decide whether to use these
options, then someone else will have to write the configure tests.

In any case, seems like trouble for binary packages.

I would prefer to find a reasonable solution that will work on all
platforms.  Those who want the absolute best performance (possibly at
the expense of accuracy) can always build for their platform with
special options.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: gcc 3.4 and Octave/lapack problems

Dmitri A. Sergatskov-2
John W. Eaton wrote:

> On 11-Nov-2004, Dmitri A. Sergatskov <[hidden email]> wrote:
>
> | BTW, according to  Jakub Jelinek
> | (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138683)
> |
> | <<<<
> | ...
> | IMHO you want to open a bug against lapack (and/or octave) and request that
> | it be compiled in two versions on IA-32: -ffloat-store and -mfpmath=sse -msse2
> | (the latter for P4 & recent AMD CPUs).
> | ...
> |  >>>>
>
> If we have to know whether we are using a P4 or some recent AMD CPU
> (how recent, what does that mean?) to decide whether to use these

sse2 exists only in Athlon64 and Opteron chips. sse is single precision
and probably irrelevant.

>
> I would prefer to find a reasonable solution that will work on all
> platforms.  Those who want the absolute best performance (possibly at
> the expense of accuracy) can always build for their platform with
> special options.

I would argue that if some code requires compilation with a special flag to
produce expected results, then either code is broken or compiler is broken.
To be practical, it looks at the moment that recompiling lapack with
FFLAGS="-ffloat-store" solves the problem.
So my guess (since I cannot come up with a sample demonstration code) that
the code in question relies on (ISO?)
standards of double precision operation and gcc breaks it. If no C or C++
code in octave made those assumptions then we save without this option
to C and C++ compilers.

Those are just mine uneducated thoughts...

>
> jwe
>

Dmitri.
--


Reply | Threaded
Open this post in threaded view
|

Re: gcc 3.4 and Octave/lapack problems

Joseph P. Skudlarek
In reply to this post by John W. Eaton-6
Reading the gcc documentation, one finds that the -ffloat-store is an
expensive hack to attempt to avoid the excess precision in the floating
pointer registers on Intel FPUs.  Based on recent experience with
DONLP2, a noteworthy nonlinear solver, using -ffloat-store everywhere is
an unnecessarily costly workaround.

The problem we saw in DONLP2, and I suspect in the numerical subroutines
used by Octave, is that they automatically calculate the machine
floating pointer characteristics.  When floating pointer numbers are
left in Intel FPU registers during those calculations, they have extra
precision (80 bits, I think), instead of the 64 bits that doubles have
in memory.  Therefore, the calculated values of vital constants like
"machine epsilon" are wrong.

The problem is that -ffloat-store can really slow things down.  Dmitri
observed a 20% slowdown in Octave using -ffloat-store everywhere.  I saw
a 75% slowdown in DONLP2 compiling with -ffloat-store.  Rather than use
-ffloat-store everywhere, it should be enough to use it to compile just
the numerical libraries (but that might still be a big performance
impact).  An alternative is to compile just the code which automaticly
determines the machine constants with -ffloat-store, or even rewrite
those routines.  For example, the routine "dmach" (eg,
http://www.netlib.org/blas/dmach.f) looks like it uses the same approach
that failed for donlp2_f77, and therefore, would need to be compiled
with -ffloat-store, or be rewritten.

We could avoid --float-store, and instead, set the floating point
control word to avoid extended precision, as suggested by g77 info; but
that seems suboptimal and nonportable.  To fix DONLP2, we explicity
coded to avoid extended precision when computing epsmac and tolmac,
using a wrapper function ("double_identity") around the intemediate
results which, in effect, forced the compiler to discard the extra
(extended) precision.  Here's a little snippet of that reworked code:

      external double_identity
      double precision double_identity

      EPSMAC = TWO**(-20)
100   CONTINUE
      EPSMAC=EPSMAC/TWO
      TERM=double_identity(ONE+EPSMAC)
      IF ( TERM .NE. ONE ) GOTO 100
      EPSMAC=EPSMAC+EPSMAC
      TOLMAC=EPSMAC
200   CONTINUE
      TOL1=TOLMAC
      TOLMAC=double_identity(TOLMAC/TWOP4)
      IF ( TOLMAC .NE. ZERO ) GOTO 200
      TOLMAC=TOL1

Here are the double_identity routines.

C     Purpose: discard extra (ie, extended) precision to enable (donlp2)
C     computing epsmac properly without recourse to the -ffloat-store
C     hack which hurts performance.

C     We do this by forcing the value into array storage and passing the
C     array to a helper routine, since we don't want the optimizing
C     compiler to always be able to pass the value in a register with
C     extended precision.

C     To be very cautious (paranoid?), we could put double_identity
C     into a separate compilation unit to prevent (stronger) compile
C     time interprocedural optimization from optimizing out
C     double_identity_helper, and then double_identity.

      double precision function double_identity(asis_value)
      double precision asis_value
      double precision hide_value(1)
      double precision double_identity_helper
      external double_identity_helper

      hide_value(1) = asis_value
      double_identity = double_identity_helper(hide_value)
      return
      end

      double precision function double_identity_helper(hide_value)
      double precision hide_value(1)

      double_identity_helper = hide_value(1)
      return
      end

C []

Hope this helps.

/Jskud

>------ Begin Included Message ------
> From: "John W. Eaton" <[hidden email]>
> Date: Thu, 11 Nov 2004 22:47:21 -0500
> To: "Dmitri A. Sergatskov" <[hidden email]>
> Cc: [hidden email]
> Subject: Re: gcc 3.4 and Octave/lapack problems
> X-CAE-MailScanner-Information: Please contact [hidden email] if this message contains a virus or has been corrupted in delivery.
> X-CAE-MailScanner: Found to be clean (hedwig)
>
> On 11-Nov-2004, Dmitri A. Sergatskov <[hidden email]> wrote:
>
> | John W. Eaton wrote:
> | > On 11-Nov-2004, Dmitri A. Sergatskov <[hidden email]> wrote:
> | >
> | > | Also, if -ffloat-store indeed the must for lapack/octave, should we
> | > | make it a default?
> | >
> | > It seems like this might be a reasonable change to make.  We'll need a
> | > configure check since -ffloat-store probably only makes sense for
> | > gcc/g++/g77.
> |
> | I guess one of the questions weather we shall pass it to g77 only
> | (at the moment that looks sufficient), or to all three?
> | I noticed that loop performance drops some 20% if I have
> | it in CXXFLAGS. I do not see any difference if CFLAGS have
> | it or not.
> |
> | Any insights?
>
> If we are going to use -ffloat-store for Fortran code because it
> produces better results (or at least results that are more likely to
> agree with what we would expect from 64-bit IEEE floating point
> arithmetic) then it seems to me that we should use it for the C and
> C++ code as well.  Or maybe you would prefer to have bad results
> faster?  :-)
>
> I've made changes to configure so that we check to see if the
> compilers accept -ffloat-store, but only on x86 platforms when using
> platforms when using the GNU compilers (individual checks are made for
> each).
>
> jwe
>
>------  End Included Message  ------


Reply | Threaded
Open this post in threaded view
|

Re: gcc 3.4 and Octave/lapack problems

Dmitri A. Sergatskov-2
[hidden email] 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:

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




Reply | Threaded
Open this post in threaded view
|

Re: gcc 3.4 and Octave/lapack problems

Quentin Spencer
I also installed Fedora Core 3 and saw the same problems. I looked this
morning on the Red Hat ftp server and noticed the development branch had
an updated version of lapack:
http://download.fedora.redhat.com/pub/fedora/linux/core/development/SRPMS/lapack-3.0-26.src.rpm
I downloaded the SRPM and rebuilt it, and the linear algebra functions
like eig appear to be working correctly now (I'm using the same octave
2.1.61 I compiled yesterday with no changes). I have attached the SPEC
file. It appears to only change the -O flags. This updated release was
in response to a separate bug that was reported in lapack:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138447

I haven't done very thorough testing (I haven't tested Dmitri's Fortran
code, for example), but I don't see any problems so far.

Quentin


Summary: The LAPACK libraries for numerical linear algebra.
Name: lapack
Version: 3.0
Release: 26
License: Freely distributable
Group: Development/Libraries
URL: http://www.netlib.org/lapack/
# If you want the source, look for the files with the .gz prefix
Source0: http://www.netlib.org/lapack/lapack.tar.bz2
Source1: http://www.netlib.org/lapack/manpages.tar.bz2
Source2: Makefile.blas
Source3: Makefile.lapack
Source4: http://www.netlib.org/lapack/lapackqref.ps
Source5: http://www.netlib.org/blas/blasqr.ps
Patch0: lapack-20010525.patch
Obsoletes: lapack-man
BuildRequires: gcc-g77, libf2c
BuildRoot: %{_tmppath}/lapack-%{version}-root

%description
LAPACK (Linear Algebra PACKage) is a standard library for numerical
linear algebra. LAPACK provides routines for solving systems of
simultaneous linear equations, least-squares solutions of linear
systems of equations, eigenvalue problems, and singular value
problems. Associated matrix factorizations (LU, Cholesky, QR, SVD,
Schur, and generalized Schur) and related computations (i.e.,
reordering of Schur factorizations and estimating condition numbers)
are also included. LAPACK can handle dense and banded matrices, but
not general sparse matrices. Similar functionality is provided for
real and complex matrices in both single and double precision. LAPACK
is coded in Fortran77 and built with gcc.

%package -n blas
Summary: The BLAS (Basic Linear Algebra Subprograms) library.
Group: Development/Libraries
Obsoletes: lapack-blas blas-man

%description -n blas
BLAS (Basic Linear Algebra Subprograms) is a standard library which
provides a number of basic algorithms for numerical algebra. Man
pages for blas are available in the blas-man package.

%prep
%setup -q -n LAPACK
%setup -q -D -T -a 1 -n LAPACK
%patch0 -p1
cp -f $RPM_SOURCE_DIR/Makefile.blas BLAS/SRC/Makefile
cp -f $RPM_SOURCE_DIR/Makefile.lapack SRC/Makefile

#Empty
rm -f man/manl/zbcon.l

%build
cd BLAS/SRC
FFLAGS="$RPM_OPT_FLAGS" make static
cp libblas.a ../..
make clean
FFLAGS="$RPM_OPT_FLAGS -fPIC" make shared
cp libblas.so.3.0.3 ../..
cd ../..
ln -s libblas.so.3.0.3 libblas.so

cd SRC
# Some files don't like -O2, but -Os is fine
RPM_OPT_SIZE_FLAGS=$(echo $RPM_OPT_FLAGS | sed 's|-O2|-Os|')
FFLAGS="$RPM_OPT_SIZE_FLAGS" make dlamch.o slamch.o
FFLAGS="$RPM_OPT_FLAGS" make static

cp liblapack.a ..
make clean
FFLAGS="$RPM_OPT_SIZE_FLAGS -fPIC" make dlamch.o slamch.o
FFLAGS="$RPM_OPT_FLAGS -fPIC" make shared
cp liblapack.so.3.0.3 ..
cd ..
cp %{SOURCE4} lapackqref.ps
cp %{SOURCE5} blasqr.ps

%install
rm -fr ${RPM_BUILD_ROOT}
mkdir -p ${RPM_BUILD_ROOT}%{_libdir}
mkdir -p ${RPM_BUILD_ROOT}%{_mandir}/manl

for f in liblapack.so.3.0.3 libblas.so.3.0.3 libblas.a liblapack.a; do
  cp -f $f ${RPM_BUILD_ROOT}%{_libdir}/$f
done

find blas/man/manl -type f -printf "%{_mandir}/manl/%f*\n" > blasmans

# These are also in the BLAS package
rm -f man/manl/lsame.l*
rm -f man/manl/xerbla.l*
find man/manl -type f -printf "%{_mandir}/manl/%f*\n" > lapackmans

cp -f blas/man/manl/* ${RPM_BUILD_ROOT}%{_mandir}/manl
cp -f man/manl/* ${RPM_BUILD_ROOT}%{_mandir}/manl

cd ${RPM_BUILD_ROOT}%{_libdir}
ln -sf liblapack.so.3.0.3 liblapack.so
ln -sf liblapack.so.3.0.3 liblapack.so.3
ln -sf liblapack.so.3.0.3 liblapack.so.3.0
ln -sf libblas.so.3.0.3 libblas.so
ln -sf libblas.so.3.0.3 libblas.so.3
ln -sf libblas.so.3.0.3 libblas.so.3.0

%post -p /sbin/ldconfig

%postun -p /sbin/ldconfig

%post -n blas -p /sbin/ldconfig

%postun -n blas -p /sbin/ldconfig

%clean
rm -fr ${RPM_BUILD_ROOT}

%files -f lapackmans
%defattr(-,root,root)
%doc README lapackqref.ps
%{_libdir}/liblapack.*

%files -n blas -f blasmans
%defattr(-,root,root)
%doc blasqr.ps
%{_libdir}/libblas.*

%changelog
* Thu Nov 11 2004 Ivana Varekova <[hidden email]>
- fix build problem bug #138447

* Tue Jun 15 2004 Elliot Lee <[hidden email]>
- rebuilt

* Tue Mar 02 2004 Elliot Lee <[hidden email]>
- rebuilt

* Fri Feb 13 2004 Elliot Lee <[hidden email]>
- rebuilt

* Wed Dec 31 2003 Jeff Johnson <[hidden email]> 3.0-23
- link -lg2c explicitly into liblapack and libblas (#109079).

* Wed Aug 20 2003 Jeremy Katz <[hidden email]> 3.0-22
- nuke -man subpackages (#97506)

* Wed Jun 04 2003 Elliot Lee <[hidden email]>
- rebuilt

* Wed Jan 22 2003 Tim Powers <[hidden email]>
- rebuilt

* Sun Nov 10 2002 Jeff Johnson <[hidden email]> 3.0-19
- rebuild with x86_64.

* Thu Jul 18 2002 Trond Eivind Glomsrød <[hidden email]> 3.0-18
- Remove an empty man page (#63569)

* Fri Jun 21 2002 Tim Powers <[hidden email]>
- automated rebuild

* Thu May 23 2002 Tim Powers <[hidden email]>
- automated rebuild

* Wed May  1 2002 Trond Eivind Glomsrød <[hidden email]> 3.0-15
- Rebuild

* Thu Feb 21 2002 Trond Eivind Glomsrød <[hidden email]> 3.0-14
- Rebuild

* Wed Jan 09 2002 Tim Powers <[hidden email]>
- automated rebuild

* Mon Aug 13 2001 Trond Eivind Glomsrød <[hidden email]> 3.0-12
- The man-pages for xerbla and lsame were in blas-man and lapack-man (#51605)

* Fri Jun  8 2001 Trond Eivind Glomsrød <[hidden email]>
- Reenable optimization for IA64

* Fri May 25 2001 Trond Eivind Glomsrød <[hidden email]>
- Add all patches from the LAPACK site as of 2001-05-25
- Use this workaround for IA64 instead
- Remove SPARC workaround
- Don't exclude IA64

* Thu Dec 07 2000 Trond Eivind Glomsrød <[hidden email]>
- rebuild for main distribution

* Mon Nov 20 2000 Trond Eivind Glomsrød <[hidden email]>
- add the LAPACK Quick Reference Guide to the docs
- add the BLAS Quick Reference Guide to the docs

* Tue Aug 01 2000 Trond Eivind Glomsrød <[hidden email]>
- fix lack of ldconfig in postuninstall script

* Mon Jul 24 2000 Prospector <[hidden email]>
- rebuilt

* Mon Jul 10 2000 Trond Eivind Glomsrød <[hidden email]>
- updated with the latest updates (new tarfile..) from netlib

* Thu Jun 15 2000 Trond Eivind Glomsrød <[hidden email]>
- use %%{_mandir}
- added some flags to work around SPARC compiler bug

* Wed Jan 19 2000 Tim Powers <[hidden email]>
- bzipped sources to conserve space

* Tue Jan  4 2000 Jeff Johnson <[hidden email]>
- build for PowerTools 6.2.

* Sat Dec 25 1999 Joachim Frieben <[hidden email]>
- updated to version v3.0 + update as of Tue Nov 30 1999

* Sat Oct 23 1999 Joachim Frieben <[hidden email]>
- updated Red Hat makefiles to v3.0

* Mon Aug 2 1999 Tim Powers <[hidden email]>
- updated to v3.0
- built for 6.1

* Mon Apr 12 1999 Michael Maher <[hidden email]>
- built package for 6.0

* Sat Oct 24 1998 Jeff Johnson <[hidden email]>
- new description/summary text.

* Fri Jul 17 1998 Jeff Johnson <[hidden email]>
- repackage for powertools.

* Sun Feb 15 1998 Trond Eivind Glomsrød <[hidden email]>
 [lapack-2.0-9]
 - No code updates, just built with a customized rpm -
   this should make dependencies right.

* Sat Feb 07 1998 Trond Eivind Glomsrød <[hidden email]>
 [lapack-2.0-8]
 - Total rewrite of the spec file
 - Added my own makefiles - libs should build better,
   static libs should work (and be faster than they
        would be if they had worked earlier ;)
 - No patch necessary anymore.
 - Renamed lapack-blas and lapack-blas-man to
   blas and blas-man. "Obsoletes:" tag added.
   (oh - and as always: Dedicated to the girl I
   love, Eline Skirnisdottir)

* Sat Dec 06 1997 Trond Eivind Glomsrød <[hidden email]>
 [lapack-2.0-7]
  - added a dependency to glibc, so people don't try with libc5

* Thu Nov 20 1997 Trond Eivind Glomsrød <[hidden email]>
  [lapack-2.0-6]
  - removed etime.c
  - compiled with egcs, and for glibc 2.0

* Sun Oct 12 1997 Trond Eivind Glomsrød <[hidden email]>
  [lapack-2.0-5]
  - added a changelog
  - cleaned up building of shared libs
  - now uses a BuildRoot
  - cleaned up the specfile
Reply | Threaded
Open this post in threaded view
|

Re: gcc 3.4 and Octave/lapack problems

Dmitri A. Sergatskov-2
Quentin Spencer wrote:

> I also installed Fedora Core 3 and saw the same problems. I looked this
> morning on the Red Hat ftp server and noticed the development branch had
> an updated version of lapack:
> http://download.fedora.redhat.com/pub/fedora/linux/core/development/SRPMS/lapack-3.0-26.src.rpm 
>
> I downloaded the SRPM and rebuilt it, and the linear algebra functions
> like eig appear to be working correctly now (I'm using the same octave
> 2.1.61 I compiled yesterday with no changes). I have attached the SPEC
> file. It appears to only change the -O flags. This updated release was
> in response to a separate bug that was reported in lapack:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138447
>

Thanks for pointing this bug out to me. I add my $0.10 to it :)
I believe a) this is a gcc issue, b) the "fix" by recompiling
with -O is fortuitous, and real fix is to do -ffloat-store.

> I haven't done very thorough testing (I haven't tested Dmitri's Fortran
> code, for example), but I don't see any problems so far.

Besides problems with eig() I found that schur() would run much slower
with broken lapack.

>
> Quentin
>

Dmitri.
--