building lib.lapack without optimization
Hi Pearu, It looks like an "optimization" problem With python setup_lapack.py build config_fc --noopt everything works fine. lib/lapack> python2.3 tests/test_lapack.py -v 10 Found 200 tests for __main__ check_gebal (__main__.test_clapack_complex) ... ok check_gehrd (__main__.test_clapack_complex) ... ok check_heev (__main__.test_clapack_complex) ... ok check_heev_complex (__main__.test_clapack_complex) ... ok check_heevd (__main__.test_clapack_complex) ... ok check_heevd_complex (__main__.test_clapack_complex) ... ok check_heevr (__main__.test_clapack_complex) ... ok check_heevr_complex (__main__.test_clapack_complex) ... ok check_heevr_irange (__main__.test_clapack_complex) ... ok check_heevr_irange_high (__main__.test_clapack_complex) ... ok check_heevr_irange_low (__main__.test_clapack_complex) ... ok check_heevr_vrange (__main__.test_clapack_complex) ... ok check_heevr_vrange_high (__main__.test_clapack_complex) ... ok check_heevr_vrange_low (__main__.test_clapack_complex) ... ok check_gebal (__main__.test_clapack_double) ... ok check_gehrd (__main__.test_clapack_double) ... ok check_syev (__main__.test_clapack_double) ... ok check_syevd (__main__.test_clapack_double) ... ok check_syevr (__main__.test_clapack_double) ... ok check_syevr_irange (__main__.test_clapack_double) ... ok check_syevr_irange_high (__main__.test_clapack_double) ... ok check_syevr_irange_low (__main__.test_clapack_double) ... ok check_syevr_irange_mid (__main__.test_clapack_double) ... ok check_syevr_vrange (__main__.test_clapack_double) ... ok check_syevr_vrange_high (__main__.test_clapack_double) ... ok check_syevr_vrange_low (__main__.test_clapack_double) ... ok check_syevr_vrange_mid (__main__.test_clapack_double) ... ok check_gebal (__main__.test_clapack_double_complex) ... ok check_gehrd (__main__.test_clapack_double_complex) ... ok check_heev (__main__.test_clapack_double_complex) ... ok check_heev_complex (__main__.test_clapack_double_complex) ... ok check_heevd (__main__.test_clapack_double_complex) ... ok check_heevd_complex (__main__.test_clapack_double_complex) ... ok check_heevr (__main__.test_clapack_double_complex) ... ok check_heevr_complex (__main__.test_clapack_double_complex) ... ok check_heevr_irange (__main__.test_clapack_double_complex) ... ok check_heevr_irange_high (__main__.test_clapack_double_complex) ... ok check_heevr_irange_low (__main__.test_clapack_double_complex) ... ok check_heevr_vrange (__main__.test_clapack_double_complex) ... ok check_heevr_vrange_high (__main__.test_clapack_double_complex) ... ok check_heevr_vrange_low (__main__.test_clapack_double_complex) ... ok check_gebal (__main__.test_clapack_float) ... ok check_gehrd (__main__.test_clapack_float) ... ok check_syev (__main__.test_clapack_float) ... ok check_syevd (__main__.test_clapack_float) ... ok check_syevr (__main__.test_clapack_float) ... ok check_syevr_irange (__main__.test_clapack_float) ... ok check_syevr_irange_high (__main__.test_clapack_float) ... ok check_syevr_irange_low (__main__.test_clapack_float) ... ok check_syevr_irange_mid (__main__.test_clapack_float) ... ok check_syevr_vrange (__main__.test_clapack_float) ... ok check_syevr_vrange_high (__main__.test_clapack_float) ... ok check_syevr_vrange_low (__main__.test_clapack_float) ... ok check_syevr_vrange_mid (__main__.test_clapack_float) ... ok check_gebal (__main__.test_flapack_complex) ... ok check_gehrd (__main__.test_flapack_complex) ... ok check_heev (__main__.test_flapack_complex) ... ok check_heev_complex (__main__.test_flapack_complex) ... ok check_heevd (__main__.test_flapack_complex) ... ok check_heevd_complex (__main__.test_flapack_complex) ... ok check_heevr (__main__.test_flapack_complex) ... ok check_heevr_complex (__main__.test_flapack_complex) ... ok check_heevr_irange (__main__.test_flapack_complex) ... ok check_heevr_irange_high (__main__.test_flapack_complex) ... ok check_heevr_irange_low (__main__.test_flapack_complex) ... ok check_heevr_vrange (__main__.test_flapack_complex) ... ok check_heevr_vrange_high (__main__.test_flapack_complex) ... ok check_heevr_vrange_low (__main__.test_flapack_complex) ... ok check_gebal (__main__.test_flapack_double) ... ok check_gehrd (__main__.test_flapack_double) ... ok check_syev (__main__.test_flapack_double) ... ok check_syevd (__main__.test_flapack_double) ... ok check_syevr (__main__.test_flapack_double) ... ok check_syevr_irange (__main__.test_flapack_double) ... ok check_syevr_irange_high (__main__.test_flapack_double) ... ok check_syevr_irange_low (__main__.test_flapack_double) ... ok check_syevr_irange_mid (__main__.test_flapack_double) ... ok check_syevr_vrange (__main__.test_flapack_double) ... ok check_syevr_vrange_high (__main__.test_flapack_double) ... ok check_syevr_vrange_low (__main__.test_flapack_double) ... ok check_syevr_vrange_mid (__main__.test_flapack_double) ... ok check_gebal (__main__.test_flapack_double_complex) ... ok check_gehrd (__main__.test_flapack_double_complex) ... ok check_heev (__main__.test_flapack_double_complex) ... ok check_heev_complex (__main__.test_flapack_double_complex) ... ok check_heevd (__main__.test_flapack_double_complex) ... ok check_heevd_complex (__main__.test_flapack_double_complex) ... ok check_heevr (__main__.test_flapack_double_complex) ... ok check_heevr_complex (__main__.test_flapack_double_complex) ... ok check_heevr_irange (__main__.test_flapack_double_complex) ... ok check_heevr_irange_high (__main__.test_flapack_double_complex) ... ok check_heevr_irange_low (__main__.test_flapack_double_complex) ... ok check_heevr_vrange (__main__.test_flapack_double_complex) ... ok check_heevr_vrange_high (__main__.test_flapack_double_complex) ... ok check_heevr_vrange_low (__main__.test_flapack_double_complex) ... ok check_gebal (__main__.test_flapack_float) ... ok check_gehrd (__main__.test_flapack_float) ... ok check_syev (__main__.test_flapack_float) ... ok check_syevd (__main__.test_flapack_float) ... ok check_syevr (__main__.test_flapack_float) ... ok check_syevr_irange (__main__.test_flapack_float) ... ok check_syevr_irange_high (__main__.test_flapack_float) ... ok check_syevr_irange_low (__main__.test_flapack_float) ... ok check_syevr_irange_mid (__main__.test_flapack_float) ... ok check_syevr_vrange (__main__.test_flapack_float) ... ok check_syevr_vrange_high (__main__.test_flapack_float) ... ok check_syevr_vrange_low (__main__.test_flapack_float) ... ok check_syevr_vrange_mid (__main__.test_flapack_float) ... ok ---------------------------------------------------------------------- Ran 108 tests in 0.245s OK lib/lapack>
On Tue, 30 Nov 2004, Nils Wagner wrote:
Hi Pearu,
It looks like an "optimization" problem
With
python setup_lapack.py build config_fc --noopt
everything works fine.
Ok, good. Now try rm -rf build python setup_lapack.py build config_fc --noarch This will use -O3 optimization but without architecture dependent optimization flags. Does it work? What gcc version are you using? Pearu
Pearu Peterson wrote:
On Tue, 30 Nov 2004, Nils Wagner wrote:
Hi Pearu,
It looks like an "optimization" problem
With
python setup_lapack.py build config_fc --noopt
everything works fine.
Ok, good.
Now try
rm -rf build python setup_lapack.py build config_fc --noarch
This will use -O3 optimization but without architecture dependent optimization flags.
Does it work?
No, the same failures as before (with python setup_lapack.py build)
What gcc version are you using?
lib/lapack> gcc -v Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.3/specs Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --enable-languages=c,c++,f77,objc,java,ada --disable-checking --libdir=/usr/lib --enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit i586-suse-linux Thread model: posix gcc version 3.3.3 (SuSE Linux)
Pearu
_______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.net http://www.scipy.net/mailman/listinfo/scipy-dev
On Tue, 30 Nov 2004, Nils Wagner wrote:
Pearu Peterson wrote:
Now try
rm -rf build python setup_lapack.py build config_fc --noarch
This will use -O3 optimization but without architecture dependent optimization flags.
Does it work?
No, the same failures as before (with python setup_lapack.py build)
Ok, now try to reduce optimization level: rm -rf build python setup_lapack.py build config_fc --noarch --opt="-O2" If that fails, then try --opt="-O", etc. If you have found working optimization level, then remove --noarch flag to see if architecture dependent flags are OK. The goal is to find optimization flags for the given compiler (i) that can be coded into scipy_distutils/gnufcompiler.py (ii) and to use these optimization flags for building Fortran LAPACK libraries needed for ATLAS.
What gcc version are you using?
gcc version 3.3.3 (SuSE Linux)
Btw, I am using gcc 3.3.5 (Debian Sid) with no problems. Pearu
Pearu Peterson wrote:
On Tue, 30 Nov 2004, Nils Wagner wrote:
Pearu Peterson wrote:
Now try
rm -rf build python setup_lapack.py build config_fc --noarch
This will use -O3 optimization but without architecture dependent optimization flags.
Does it work?
No, the same failures as before (with python setup_lapack.py build)
Ok, now try to reduce optimization level:
rm -rf build python setup_lapack.py build config_fc --noarch --opt="-O2"
If that fails, then try --opt="-O", etc.
If you have found working optimization level, then remove --noarch flag to see if architecture dependent flags are OK.
The goal is to find optimization flags for the given compiler (i) that can be coded into scipy_distutils/gnufcompiler.py (ii) and to use these optimization flags for building Fortran LAPACK libraries needed for ATLAS.
Here are my findings... python2.3 setup_lapack.py build config_fc --noarch --opt="-O2" yields ====================================================================== FAIL: check_heev_complex (__main__.test_clapack_complex) ---------------------------------------------------------------------- Traceback (most recent call last): File "tests/test_lapack.py", line 51, in check_heev_complex assert_array_almost_equal(dot(a,v[:,i]),w[i]*v[:,i]) File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 748, in assert_array_almost_equal assert cond,\ AssertionError: Arrays are not almost equal (mismatch 33.3333333333%): Array 1: [-1.2905481 -4.3758251e+00j -2.0410486 +1.3645462e+00j 3.5935487 +2.8312206e-07j] Array 2: [-1.2905486-4.3758267j -2.041049 +1.3645459j 3.5935484-0.j ] ====================================================================== FAIL: check_heev_complex (__main__.test_flapack_complex) ---------------------------------------------------------------------- Traceback (most recent call last): File "tests/test_lapack.py", line 51, in check_heev_complex assert_array_almost_equal(dot(a,v[:,i]),w[i]*v[:,i]) File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 748, in assert_array_almost_equal assert cond,\ AssertionError: Arrays are not almost equal (mismatch 33.3333333333%): Array 1: [-1.2905481 -4.3758251e+00j -2.0410486 +1.3645462e+00j 3.5935487 +2.8312206e-07j] Array 2: [-1.2905486-4.3758267j -2.041049 +1.3645459j 3.5935484-0.j ] ---------------------------------------------------------------------- Ran 108 tests in 0.248s FAILED (failures=2) ################################################################################################ python2.3 setup_lapack.py build config_fc --noarch --opt="-O" yields ====================================================================== FAIL: check_heev_complex (__main__.test_clapack_complex) ---------------------------------------------------------------------- Traceback (most recent call last): File "tests/test_lapack.py", line 51, in check_heev_complex assert_array_almost_equal(dot(a,v[:,i]),w[i]*v[:,i]) File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 748, in assert_array_almost_equal assert cond,\ AssertionError: Arrays are not almost equal (mismatch 33.3333333333%): Array 1: [-1.2905485 -4.3758260e+00j -2.0410489 +1.3645461e+00j 3.5935477 -4.4703484e-08j] Array 2: [-1.2905487-4.3758263j -2.041049 +1.364546j 3.5935492-0.j ] ====================================================================== FAIL: check_heev_complex (__main__.test_flapack_complex) ---------------------------------------------------------------------- Traceback (most recent call last): File "tests/test_lapack.py", line 51, in check_heev_complex assert_array_almost_equal(dot(a,v[:,i]),w[i]*v[:,i]) File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 748, in assert_array_almost_equal assert cond,\ AssertionError: Arrays are not almost equal (mismatch 33.3333333333%): Array 1: [-1.2905485 -4.3758260e+00j -2.0410489 +1.3645461e+00j 3.5935477 -4.4703484e-08j] Array 2: [-1.2905487-4.3758263j -2.041049 +1.364546j 3.5935492-0.j ] ---------------------------------------------------------------------- Ran 108 tests in 0.246s FAILED (failures=2) So any optimization fails. Nils
What gcc version are you using?
gcc version 3.3.3 (SuSE Linux)
Btw, I am using gcc 3.3.5 (Debian Sid) with no problems.
SuSE 9.2 comes with gcc 3.3.4. http://www.suse.de/de/private/products/suse_linux/prof/packages_professional... Do you have any experience with that version ?
Pearu
_______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.net http://www.scipy.net/mailman/listinfo/scipy-dev
On Tue, 30 Nov 2004, Nils Wagner wrote:
Here are my findings...
python2.3 setup_lapack.py build config_fc --noarch --opt="-O2" yields
====================================================================== FAIL: check_heev_complex (__main__.test_clapack_complex) ---------------------------------------------------------------------- Traceback (most recent call last): File "tests/test_lapack.py", line 51, in check_heev_complex assert_array_almost_equal(dot(a,v[:,i]),w[i]*v[:,i]) File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 748, in assert_array_almost_equal assert cond,\ AssertionError: Arrays are not almost equal (mismatch 33.3333333333%): Array 1: [-1.2905481 -4.3758251e+00j -2.0410486 +1.3645462e+00j 3.5935487 +2.8312206e-07j] Array 2: [-1.2905486-4.3758267j -2.041049 +1.3645459j 3.5935484-0.j ]
====================================================================== FAIL: check_heev_complex (__main__.test_flapack_complex) ---------------------------------------------------------------------- Traceback (most recent call last): File "tests/test_lapack.py", line 51, in check_heev_complex assert_array_almost_equal(dot(a,v[:,i]),w[i]*v[:,i]) File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 748, in assert_array_almost_equal assert cond,\ AssertionError: Arrays are not almost equal (mismatch 33.3333333333%): Array 1: [-1.2905481 -4.3758251e+00j -2.0410486 +1.3645462e+00j 3.5935487 +2.8312206e-07j] Array 2: [-1.2905486-4.3758267j -2.041049 +1.3645459j 3.5935484-0.j ]
So, -O2 fixes the problem. I'll make it default for gcc-3.3.3 compiler. Also, if your lapack libraries are built with -O3 then rebuilding them with -O2 should fix the segmentation faults.
So any optimization fails.
Note that in the failures the results are actually correct. Just the corresponding tests need some tuning.. So, I am not considering them as failures.
What gcc version are you using? gcc version 3.3.3 (SuSE Linux) Btw, I am using gcc 3.3.5 (Debian Sid) with no problems.
SuSE 9.2 comes with gcc 3.3.4. Do you have any experience with that version ?
I don't remember. Pearu
Pearu Peterson wrote:
On Tue, 30 Nov 2004, Nils Wagner wrote:
Here are my findings...
python2.3 setup_lapack.py build config_fc --noarch --opt="-O2" yields
====================================================================== FAIL: check_heev_complex (__main__.test_clapack_complex) ---------------------------------------------------------------------- Traceback (most recent call last): File "tests/test_lapack.py", line 51, in check_heev_complex assert_array_almost_equal(dot(a,v[:,i]),w[i]*v[:,i]) File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 748, in assert_array_almost_equal assert cond,\ AssertionError: Arrays are not almost equal (mismatch 33.3333333333%): Array 1: [-1.2905481 -4.3758251e+00j -2.0410486 +1.3645462e+00j 3.5935487 +2.8312206e-07j] Array 2: [-1.2905486-4.3758267j -2.041049 +1.3645459j 3.5935484-0.j ]
====================================================================== FAIL: check_heev_complex (__main__.test_flapack_complex) ---------------------------------------------------------------------- Traceback (most recent call last): File "tests/test_lapack.py", line 51, in check_heev_complex assert_array_almost_equal(dot(a,v[:,i]),w[i]*v[:,i]) File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 748, in assert_array_almost_equal assert cond,\ AssertionError: Arrays are not almost equal (mismatch 33.3333333333%): Array 1: [-1.2905481 -4.3758251e+00j -2.0410486 +1.3645462e+00j 3.5935487 +2.8312206e-07j] Array 2: [-1.2905486-4.3758267j -2.041049 +1.3645459j 3.5935484-0.j ]
So, -O2 fixes the problem. I'll make it default for gcc-3.3.3 compiler.
Also, if your lapack libraries are built with -O3 then rebuilding them with -O2 should fix the segmentation faults.
This is my make.inc. So, I will replace OPTS = -funroll-all-loops -fno-f2c -O3 with OPTS = -funroll-all-loops -fno-f2c -O2 Is that o.k. ? Nils #################################################################### # 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 = _LINUX # # 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 = g77 OPTS = -funroll-all-loops -fno-f2c -O3 DRVOPTS = $(OPTS) NOOPT = LOADER = g77 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
So any optimization fails.
Note that in the failures the results are actually correct. Just the corresponding tests need some tuning.. So, I am not considering them as failures.
What gcc version are you using?
gcc version 3.3.3 (SuSE Linux)
Btw, I am using gcc 3.3.5 (Debian Sid) with no problems.
SuSE 9.2 comes with gcc 3.3.4. Do you have any experience with that version ?
I don't remember.
Pearu
_______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.net http://www.scipy.net/mailman/listinfo/scipy-dev
On Tue, 30 Nov 2004, Nils Wagner wrote:
Also, if your lapack libraries are built with -O3 then rebuilding them with -O2 should fix the segmentation faults.
This is my make.inc. So, I will replace
OPTS = -funroll-all-loops -fno-f2c -O3
with
OPTS = -funroll-all-loops -fno-f2c -O2
Is that o.k. ?
Yes. Pearu
Pearu Peterson wrote:
On Tue, 30 Nov 2004, Nils Wagner wrote:
Also, if your lapack libraries are built with -O3 then rebuilding them with -O2 should fix the segmentation faults.
This is my make.inc. So, I will replace
OPTS = -funroll-all-loops -fno-f2c -O3
with
OPTS = -funroll-all-loops -fno-f2c -O2
Is that o.k. ?
Yes.
Pearu
_______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.net http://www.scipy.net/mailman/listinfo/scipy-dev
First of all, I have rebuild my lapack library with -O2. Secondly, I have installed ATLAS from scratch. From my ATLAS directory, issue : make killall arch=ARCH make startup arch=ARCH make install arch=ARCH Then I build a complete lapack library ATLAS does not provide a full LAPACK library. However, there is a simple way to get ATLAS to provide its faster LAPACK routines to a full LAPACK library. ATLAS's internal routines are distinct from LAPACK's, so it is safe to compile ATLAS's LAPACK routines directly into a netlib-style LAPACK library. First, download and install the standard LAPACK library from the LAPACK homepage <http://www.netlib.org/lapack>. Then, in your ATLAS/lib/ARCH directory (where you should have a liblapack.a), issue the following commands: mkdir tmp cd tmp ar x ../liblapack.a cp <your LAPACK path & lib> ../liblapack.a ar r ../liblapack.a *.o cd .. rm -rf tmp Again, scipy.test() failed with a segmentation fault. Am I missing something ? Nils
On Wed, 1 Dec 2004, Nils Wagner wrote:
First of all, I have rebuild my lapack library with -O2.
Secondly, I have installed ATLAS from scratch. From my ATLAS directory, issue :
make killall arch=ARCH make startup arch=ARCH make install arch=ARCH
Then I build a complete lapack library
ATLAS does not provide a full LAPACK library. However, there is a simple way to get ATLAS to provide its faster LAPACK routines to a full LAPACK library. ATLAS's internal routines are distinct from LAPACK's, so it is safe to compile ATLAS's LAPACK routines directly into a netlib-style LAPACK library. First, download and install the standard LAPACK library from the LAPACK homepage <http://www.netlib.org/lapack>. Then, in your ATLAS/lib/ARCH directory (where you should have a liblapack.a), issue the following commands:
mkdir tmp cd tmp ar x ../liblapack.a cp <your LAPACK path & lib> ../liblapack.a ar r ../liblapack.a *.o cd .. rm -rf tmp
Again, scipy.test() failed with a segmentation fault. Am I missing something ?
I think from the success of using Fortran blas/lapack libraries it is now clear that the issue is not in scipy. If you update scipy CVS tree, install scipy_core, then running in Lib/lapack python tests/test_lapack.py -v 10 should show test name before crashing python. Then study the corresponding test and try to find the simplest way to reproduce the segmentation fault. This probably means calling some function from flapack.so. Try using different arguments for this function to see if some combination does succeed. If not, create a C program that is using the corresponding routine to prove a possible bug in ATLAS or compiler. Then report your findings to scipy-dev and we'll try to find a workaround for you. Another option for you would be arrange a temporary account to your machine so that I could login and try to do some diagnostics myself. Regards, Pearu
Pearu Peterson wrote:
On Wed, 1 Dec 2004, Nils Wagner wrote:
First of all, I have rebuild my lapack library with -O2.
Secondly, I have installed ATLAS from scratch. From my ATLAS directory, issue :
make killall arch=ARCH make startup arch=ARCH make install arch=ARCH
Then I build a complete lapack library
ATLAS does not provide a full LAPACK library. However, there is a simple way to get ATLAS to provide its faster LAPACK routines to a full LAPACK library. ATLAS's internal routines are distinct from LAPACK's, so it is safe to compile ATLAS's LAPACK routines directly into a netlib-style LAPACK library. First, download and install the standard LAPACK library from the LAPACK homepage <http://www.netlib.org/lapack>. Then, in your ATLAS/lib/ARCH directory (where you should have a liblapack.a), issue the following commands:
mkdir tmp cd tmp ar x ../liblapack.a cp <your LAPACK path & lib> ../liblapack.a ar r ../liblapack.a *.o cd .. rm -rf tmp
Again, scipy.test() failed with a segmentation fault. Am I missing something ?
I think from the success of using Fortran blas/lapack libraries it is now clear that the issue is not in scipy.
If you update scipy CVS tree, install scipy_core, then running in Lib/lapack
python tests/test_lapack.py -v 10
should show test name before crashing python.
python2.3 tests/test_lapack.py -v 10 Found 66 tests for __main__ check_gebal (__main__.test_flapack_complex) ... ok check_heev (__main__.test_flapack_complex)Segmentation fault
Then study the corresponding test and try to find the simplest way to reproduce the segmentation fault. This probably means calling some function from flapack.so. Try using different arguments for this function to see if some combination does succeed.
Python 2.3.3 (#1, Apr 6 2004, 01:47:39) [GCC 3.3.3 (SuSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import scipy scipy.lib.lapack.flapack.cheev([[1,2],[2,2]]) (array([-0.56155282, 3.56155276],'f'), array([[-0.78820544+0.j, 0.61541224+0.j], [ 0.61541224+0.j, 0.78820544+0.j]],'F'), 0) scipy.lib.lapack.flapack.cheev([[1,2,3],[2,2,3],[3,3,6]]) Segmentation fault scipy.lib.lapack.flapack.cheev([[1j,2j],[3,2]]) Segmentation fault
If not, create a C program that is using the corresponding routine to prove a possible bug in ATLAS or compiler. Then report your findings to scipy-dev and we'll try to find a workaround for you.
gcc main.c -L/var/tmp/LAPACK -llapack -lg2c /home/nwagner> gdb a.out GNU gdb 6.1 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-suse-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run Starting program: /home/nwagner/a.out Program received signal SIGSEGV, Segmentation fault. 0x400961db in cheev_ () from /usr/lib/liblapack.so.3 I do not understand the usage of /usr/lib/liblapack.so.3. This library comes with SuSE as an rpm... Nils
Another option for you would be arrange a temporary account to your machine so that I could login and try to do some diagnostics myself.
Regards, Pearu
_______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.net http://www.scipy.net/mailman/listinfo/scipy-dev
-- Dr.-Ing. Nils Wagner Institut A für Mechanik Universität Stuttgart Pfaffenwaldring 9 D-70550 Stuttgart Tel.: (+49) 0711 685 6262 Fax.: (+49) 0711 685 6282 E-mail: nwagner@mecha.uni-stuttgart.de URL : http://www.mecha.uni-stuttgart.de
On Wed, 1 Dec 2004, Nils Wagner wrote:
If not, create a C program that is using the corresponding routine to prove a possible bug in ATLAS or compiler. Then report your findings to scipy-dev and we'll try to find a workaround for you.
gcc main.c -L/var/tmp/LAPACK -llapack -lg2c
/home/nwagner> gdb a.out
(gdb) run Starting program: /home/nwagner/a.out
Program received signal SIGSEGV, Segmentation fault. 0x400961db in cheev_ () from /usr/lib/liblapack.so.3
I do not understand the usage of /usr/lib/liblapack.so.3. This library comes with SuSE as an rpm...
Does anyone have a good reference about linking basics for Nils? Pearu
Pearu Peterson wrote:
On Wed, 1 Dec 2004, Nils Wagner wrote:
If not, create a C program that is using the corresponding routine to prove a possible bug in ATLAS or compiler. Then report your findings to scipy-dev and we'll try to find a workaround for you.
gcc main.c -L/var/tmp/LAPACK -llapack -lg2c
/home/nwagner> gdb a.out
(gdb) run Starting program: /home/nwagner/a.out
Program received signal SIGSEGV, Segmentation fault. 0x400961db in cheev_ () from /usr/lib/liblapack.so.3
I do not understand the usage of /usr/lib/liblapack.so.3. This library comes with SuSE as an rpm...
Does anyone have a good reference about linking basics for Nils?
I found one. http://sourceforge.net/tracker/index.php?func=detail&aid=1067122&group_id=1369&atid=101369 Nils
Pearu
_______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.net http://www.scipy.net/mailman/listinfo/scipy-dev
participants (2)
-
Nils Wagner -
Pearu Peterson