Bug 29621 - lapack runs into infinite loop with -03
Summary: lapack runs into infinite loop with -03
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-27 19:08 UTC by fotis k.
Modified: 2006-10-28 03:07 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description fotis k. 2006-10-27 19:08:54 UTC
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)
Comment 1 kargl 2006-10-27 19:33:17 UTC
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.
Comment 2 fotis k. 2006-10-27 21:14:36 UTC
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)
Comment 3 Jerry DeLisle 2006-10-27 21:44:01 UTC
Let me check this out and see if I can duplicate the problem.
Comment 4 kargl 2006-10-27 21:47:09 UTC
What compiler option did you use to compile BLAS and LAPACK?
Comment 5 fotis k. 2006-10-27 21:51:40 UTC
(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.




Comment 6 kargl 2006-10-27 22:07:33 UTC
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?)
Comment 7 Jerry DeLisle 2006-10-27 22:13:42 UTC
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.

Comment 8 Jerry DeLisle 2006-10-27 22:15:10 UTC
What platform are you using that has the problem?
Comment 9 fotis k. 2006-10-27 22:29:55 UTC
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. 
Comment 10 fotis k. 2006-10-27 23:39:52 UTC
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.

Comment 11 Jerry DeLisle 2006-10-28 00:47:02 UTC
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.
Comment 12 fotis k. 2006-10-28 01:34:48 UTC
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._
Comment 13 Steve Kargl 2006-10-28 01:40:29 UTC
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.

Comment 14 fotis k. 2006-10-28 02:07:00 UTC
(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?
Comment 15 Steve Kargl 2006-10-28 02:59:33 UTC
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.

Comment 16 kargl 2006-10-28 03:07:35 UTC
One final note.  This behavior is described in the lapack FAQ.  http://www.netlib.org/lapack/faq.html#1.25