At first request to inverse a matrix [1 0; 0 1], octave hangs. Reproducible: Always Steps to Reproduce: $ octave octave:1> [1 0; 0 1]^-1 Actual Results: octave hang with 100% cpu usage Expected Results: octave:1> [1 0; 0 1]^-1 ans = 1 -0 0 1 octave:2> After Ctrl-C and asking again, inversion works. gdb showed a loop in dlamc1_/dlamc3_. Reproduced on 2 machines. emerge octave says: [ebuild R ] sci-mathematics/octave-2.1.73 USE="readline zlib -blas -debug -doc -emacs -hdf5 -mpi -static" 0 kB ... * Installed are: gfortran ... checking for i686-pc-linux-gnu-gfortran... i686-pc-linux-gnu-gfortran checking whether we are using the GNU Fortran 77 compiler... yes ... make.conf has: ... CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu" CXXFLAGS="${CFLAGS}" FEATURES="ccache parallel-fetch" ... and no line containing string '77' or 'fortran'. Google hints: http://osdir.com/ml/gnu.octave.bugs/2005-10/msg00042.html http://scicomp.ewha.ac.kr/netlib/lapack/faq_julie.html#1.25 I hope I didn't ever set any more agressive optimizing option than CFLAGS=-O2.
Please post your `emerge --info' too.
Created attachment 168612 [details] emerge --info output This is `emerge --info` from (second) machine with same hang symptoms (dlamc1_) and make.conf settings very similar to those given above.
What blas/lapack implementation are you are using (i.e. what does eselect blas/lapack show) give)? Have you tried recompiling your lapack and blas libs? Also, you may want to set some FFLAGS to be used with your Fortran compiler, something like FFLAGS=${CFLAGS} in /etc/make.conf should do. Thanks, Markus
It seems I have no blas/lapack: tux ~ # eselect blas/lapack show !!! Error: Can't load module blas/lapack Killed tux ~ # eselect blas show !!! Error: Can't load module blas Killed tux ~ # eselect lapack show !!! Error: Can't load module lapack Killed tux ~ # Setting FFLAGS in make.conf affects the bug: FFLAGS="${CFLAGS} -ffloat-store" # octave works as expected FFLAGS="${CFLAGS}" # octave hungs FFLAGS="-ffloat-store" # octave works as expected (-ffloat-store is from the first url mentioned in bug report) So, setting FFLAGS="-ffloat-store" in make.conf is a usable fix/workaround.
Ahh, so you are presumably using octave's internal blas/lapack routines. If you are planning on doing anything that requires non-trivial matrix and linear algebra I would strongly advice to emerge a separate blas and lapack library since these will likely be much more efficient. I'd recommend lapack-reference blas-reference which should give pretty reasonable results and emerge fast or blas/lapack-atlas if speed is very important (these take longer to compile though). Best, Markus
Thanks for the performance notice. I wish ebuild displayed that in pkg_postinst(). blas-reference (export USE=blas; emerge octave) did not affect the result: the result still depends on -ffloat-store. Adding lapack-reference (export USE=blas; emerge lapack; emerge octave) fixes the problem: without ffloat-store, [1 0; 0 1]^-1 does not hang.
(In reply to comment #6) > Adding lapack-reference (export USE=blas; emerge lapack; emerge octave) fixes > the problem: without ffloat-store, [1 0; 0 1]^-1 does not hang. > Great! Once octave-3.* will become stable these issues should be a thing of the past. I'll close this bug then as FIXED even though technically we've only come up with a workaround. I hope this is all right and please feel free to reopen if you have additional concerns. Best, Markus
