Steps to reproduce: 0. Download lapack (blas source included) from: http://www.netlib.org/lapack/lapack.tgz. 1. Build blas: gfortran -c BLAS_SRC\*.f -O3 ar -r libblas.a *.o 2. Build lapack: gfortran -c LAPACK_SRC\*.f -O3 ar -r liblapack.a *.o 3. Run following testcase (testcase.f): ------ code --------------------------------- PROGRAM TESTCASE IMPLICIT NONE REAL A(3,3) REAL X(3) REAL WORK(9) INTEGER INFO A(1,1)= 1. A(2,1)= 0. A(3,1)= 0. A(1,2)= 0. A(2,2)= 1. A(3,2)= 0. A(1,3)= 0. A(2,3)= 0. A(3,3)= 1. CALL DSYEV('N','L',3,A,3,X,WORK,3*3,INFO); END PROGRAM ------ end code ----------------------------- build with gfortran -c testcase.f -O3 gfortran testcase.o -L. -llapack -lblas Result: a.exe runs into an infinite loop. Builds are on Win32 XP with gFortran 4.3.0 20061021 (experimental). Same occurs with previous versions of gFortran. F.E. Karaoulanis (www.nemesis-project.org)
DSYEV is expecting double precision arrays. You are giving it default real kind arrays. This is a bug in your code. If you want gfortran to detect this type of problem, use LAPACK95.
I just tried to submit a reduced test case. Please reconsider this bug with these two cases (one linking with a Fortran program and one with a C/C++ one): =========================================================================== Test case #1 [Fortran with DOUBLE PRECISION] =========================================================================== PROGRAM TESTCASE IMPLICIT NONE DOUBLE PRECISION A(3,3) DOUBLE PRECISION X(3) DOUBLE PRECISION WORK(9) INTEGER INFO A(1,1)= 1. A(2,1)= 0. A(3,1)= 0. A(1,2)= 0. A(2,2)= 1. A(3,2)= 0. A(1,3)= 0. A(2,3)= 0. A(3,3)= 1. CALL DSYEV('N','L',3,A,3,X,WORK,3*3,INFO); END PROGRAM =========================================================================== Test case #2 [C/C++] =========================================================================== extern "C" void dsyev_(char* JOBZ,char* UPLO,int* N,double* A,int* LDA, double* W,double* WORK,int* LWORK,int* INFO); int main() { int N=3; double x[3]; double a[3*3]; a[0] = 1; a[3] = 0; a[6] = 0; a[1] = 0; a[4] = 1; a[7] = 0; a[2] = 0; a[5] = 0; a[8] = 1; char JOBZ='N'; char UPLO='L'; int LDA=N; int LWORK=3*3; double WORK[LWORK]; int INFO; dsyev_(&JOBZ,&UPLO,&N,&a[0],&LDA,&x[0],&WORK[0],&LWORK,&INFO); return 0; } The result is in both cases identical: an infinite loop. Kind regards, F.E. Karaoulanis (www.nemesis-project.org)
Let me check this out and see if I can duplicate the problem.
What compiler option did you use to compile BLAS and LAPACK?
(In reply to comment #4) > What compiler option did you use to compile BLAS and LAPACK? It is mentioned on http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29621#c0: 1. Build blas: gfortran -c BLAS_SRC\*.f -O3 ar -r libblas.a *.o 2. Build lapack: gfortran -c LAPACK_SRC\*.f -O3 ar -r liblapack.a *.o ... which means the (default) optimization options as provided by -O3 only.
I can't make this go into an infinite loop on FreeBSD. Can you rebuild blas and lapack with -O1 and see if the problem still occurs? I'm not sure if this is an optimization problem or a target problem (cygwin or mingW?)
Using gfortran: I get AOK, no infinite loop. See information that follows. Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc43/configure --prefix=/home/jerry/gcc/usr --enable-languages=c,fortran --disable-libmudflap --enable-libgomp --enable-maintainer-mode Thread model: posix gcc version 4.3.0 20061025 (experimental) I built blas and lapack at -O3 I compiled testcase.f with -O3 I used the link line used in Comment #1. The test program compiled, linked, and executed AOK on i686-linux I am using ranlib 2.17 and ar 2.17 The next questionis what tool versions are you using. I also used the make script from the lapack distribution with make.inc as follows: #################################################################### # LAPACK make include file. # # LAPACK, Version 3.0 # # June 30, 1999 # #################################################################### # SHELL = /bin/sh # # The machine (platform) identifier to append to the library names # PLAT = _gfc # # Modify the FORTRAN and OPTS definitions to refer to the # compiler and desired compiler options for your machine. NOOPT # refers to the compiler options desired when NO OPTIMIZATION is # selected. Define LOADER and LOADOPTS to refer to the loader and # desired load options for your machine. # FORTRAN = gfc OPTS = -O3 DRVOPTS = $(OPTS) NOOPT = LOADER = gfc LOADOPTS = # # The archiver and the flag(s) to use when building archive (library) # If you system has no ranlib, set RANLIB = echo. # ARCH = ar ARCHFLAGS= cr RANLIB = ranlib # # The location of the libraries to which you will link. (The # machine-specific, optimized BLAS library should be used whenever # possible.) # BLASLIB = ../../blas$(PLAT).a LAPACKLIB = lapack$(PLAT).a TMGLIB = tmglib$(PLAT).a EIGSRCLIB = eigsrc$(PLAT).a LINSRCLIB = linsrc$(PLAT).a I copied the resulting libraries to libraries matching the names you used.
What platform are you using that has the problem?
I confirm that the same problem exists with -O1. It might be a target problem (gfortran used comes from a mingw build, dated 2006-10-21 and linked as an installer in http://gcc.gnu.org/wiki/GFortranBinaries). As mentioned in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29621#c0 the platform is Win32. Anyway, just to mention that other LAPACK routines tested (DGESV, DSPSV, DGBSV just to name some) run perfectly fine.
Starting from http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options I compiled both BLAS/LAPACK using the following compiler flags: -fdefer-pop -fguess-branch-probability -fcprop-registers -fif-conversion -fif-conversion2 -ftree-ccp -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-ter -ftree-lrs -ftree-sra -ftree-copyrename -ftree-fre -ftree-ch -funit-at-a-time -fmerge-constants -fthread-jumps -fcrossjumping -foptimize-sibling-calls -fcse-follow-jumps -fcse-skip-blocks -fgcse -fgcse-lm -fexpensive-optimizations -frerun-cse-after-loop -fcaller-saves -fpeephole2 -fschedule-insns -fschedule-insns2 -fsched-interblock -fsched-spec -fregmove -fstrict-aliasing -fdelete-null-pointer-checks -freorder-blocks -freorder-functions -falign-functions -falign-jumps -falign-loops -falign-labels -ftree-vrp -ftree-pre -finline-functions -funswitch-loops -fgcse-after-reload which (including -fdelayed-branch which I deliberately ommited since I got complaints for not being supported on my platform), are set to be the default flags turned on by -O3. No infinitely looping was observed now for the above test cases, which means that the bug(?) exists in some other flag(s) triggerred by -O3.
I built the libraries and the test program with two different builds on my XP box. One is more or less a default cygwin build, th eother is a mingw build I downloaded. They are dated about 10/11/2006 (10/10/2006). In both cases I get a clean execution of the resulting program. I wonder if you have a mingw or cygwin installation problem. Regarding your comment on optimization flags. -O3 is know to do some things not covered by the flags documented.
I used (on three different XP boxes) the source code as provided by netlib http://www.netlib.org/lapack/lapack.tgz, the latest gfortran binaries, namely http://quatramaran.ens.fr/~coudert/gfortran/gfortran-windows.exe, posted on http://gcc.gnu.org/wiki/GFortranBinaries, and dated 2006-10-21 (mingw build), and I followed the (fairly) straightforward instructions given in the description. I also used g77 (included in mingw 3.4.2., now dropped from the gcc mainline) always ending up in the same result, reproducible by anyone but me, hence I do not think that this should be filed then as a bug. I appreciate your time very much. Kind regards, F.E. Karaoulanis._
Subject: Re: lapack runs into infinite loop with -03 On Sat, Oct 28, 2006 at 01:34:48AM -0000, fkar at nemesis-project dot org wrote: > > I used (on three different XP boxes) the source code as provided by netlib > http://www.netlib.org/lapack/lapack.tgz, > the latest gfortran binaries, namely > http://quatramaran.ens.fr/~coudert/gfortran/gfortran-windows.exe, > posted on > http://gcc.gnu.org/wiki/GFortranBinaries, > and dated 2006-10-21 (mingw build), and I followed the (fairly) straightforward > instructions given in the description. I also used g77 (included in mingw > 3.4.2., now dropped from the gcc mainline) always ending up in the same result, > reproducible by anyone but me, hence I do not think that this should be filed > then as a bug. > I appreciate your time very much. > Are you building slamch.f and dlamch.f with -O3 or even -O1? Don't. These files try to determine machine values (e.g., epsilon). Optimization can give some really strange answers.
(In reply to comment #13) > Are you building slamch.f and dlamch.f with -O3 or even -O1? > Don't. These files try to determine machine values (e.g., > epsilon). Optimization can give some really strange answers. Thank you!!! That totally solved the problem and now the program executes fine. Is this a bug after all?
Subject: Re: lapack runs into infinite loop with -03 On Sat, Oct 28, 2006 at 02:07:00AM -0000, fkar at nemesis-project dot org wrote: > > > Are you building slamch.f and dlamch.f with -O3 or even -O1? > > Don't. These files try to determine machine values (e.g., > > epsilon). Optimization can give some really strange answers. > > Thank you!!! > That totally solved the problem and now the program executes fine. > > Is this a bug after all? > No. It is very old Fortran code that tries to be clever. Unfortunately, aggressive optimization will break the cleverness.
One final note. This behavior is described in the lapack FAQ. http://www.netlib.org/lapack/faq.html#1.25