Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so

[Georgi D. Sotirov]

Hello,

I encounter the following problem on Slackware Linux 13.0 with LAPACK 3.2.1 and Octave 3.2.3. When I run octave it uses almost the whole CPU time on the machine, without being able to finish. I've traced the problem to the following:

# gdb /usr/bin/octave
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-slackware-linux"...
(no debugging symbols found)
(gdb) r
Starting program: /usr/bin/octave
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
(no debugging symbols found)
[New Thread 0xb599e8e0 (LWP 3266)]
(no debugging symbols found)
^C
Program received signal SIGINT, Interrupt.
[Switching to Thread 0xb599e8e0 (LWP 3266)]
0xb66bb908 in dlamc3_ () from /usr/lib/liblapack.so.3.2.1
(gdb) bt
#0  0xb66bb908 in dlamc3_ () from /usr/lib/liblapack.so.3.2.1
#1  0xb66bc4c2 in dlamc1_ () from /usr/lib/liblapack.so.3.2.1
#2  0xb66bbca0 in dlamc2_ () from /usr/lib/liblapack.so.3.2.1
#3  0xb66bc576 in dlamch_ () from /usr/lib/liblapack.so.3.2.1
#4  0xb6837bc5 in d1mach_ () from /usr/lib/octave-3.2.3/libcruft.so
#5  0xb69f158d in oct_mach_info::init_float_format () from /usr/lib/octave-3.2.3/liboctave.so
#6  0xb69f1682 in oct_mach_info::oct_mach_info () from /usr/lib/octave-3.2.3/liboctave.so
#7  0xb69f16ee in oct_mach_info::instance_ok () from /usr/lib/octave-3.2.3/liboctave.so
#8  0xb69f17b7 in oct_mach_info::native_float_format () from /usr/lib/octave-3.2.3/liboctave.so
#9  0xb69de464 in octave_ieee_init () from /usr/lib/octave-3.2.3/liboctave.so
#10 0xb7789b77 in sysdep_init () from /usr/lib/octave-3.2.3/liboctinterp.so
#11 0xb772187a in octave_main () from /usr/lib/octave-3.2.3/liboctinterp.so
#12 0x080486da in main ()
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0xb62c65c4 in dlamc3_@plt () from /usr/lib/liblapack.so.3.2.1
(gdb) bt
#0  0xb62c65c4 in dlamc3_@plt () from /usr/lib/liblapack.so.3.2.1
#1  0xb66bc4c2 in dlamc1_ () from /usr/lib/liblapack.so.3.2.1
#2  0xb66bbca0 in dlamc2_ () from /usr/lib/liblapack.so.3.2.1
#3  0xb66bc576 in dlamch_ () from /usr/lib/liblapack.so.3.2.1
#4  0xb6837bc5 in d1mach_ () from /usr/lib/octave-3.2.3/libcruft.so
#5  0xb69f158d in oct_mach_info::init_float_format () from /usr/lib/octave-3.2.3/liboctave.so
#6  0xb69f1682 in oct_mach_info::oct_mach_info () from /usr/lib/octave-3.2.3/liboctave.so
#7  0xb69f16ee in oct_mach_info::instance_ok () from /usr/lib/octave-3.2.3/liboctave.so
#8  0xb69f17b7 in oct_mach_info::native_float_format () from /usr/lib/octave-3.2.3/liboctave.so
#9  0xb69de464 in octave_ieee_init () from /usr/lib/octave-3.2.3/liboctave.so
#10 0xb7789b77 in sysdep_init () from /usr/lib/octave-3.2.3/liboctinterp.so
#11 0xb772187a in octave_main () from /usr/lib/octave-3.2.3/liboctinterp.so
#12 0x080486da in main ()

It seems, that Octave is stuck on an infinite loop in LAPACK, which in my case is compiled as a separate shared library by gcc 4.3.3 with flags "-fimplicit-none -O -mieee-fp -march=i486 -mtune=i686 -fPIC". I have the same problem with flags "-fimplicit-none -O2 -march=i486 -mtune=i686 -fPIC" and also with "-O3" (I've though at one point it may be some optimization issue). Then, I noticed that octave runs normally if compiled without system's LAPACK (./configure --without-lapack). In this case LAPACK is compiled for libcruft with just "-O -mieee-fp" flags.

Any suggestions? Is the problem in Octave or it's in LAPACK? How could I help for the resolving of this problem?

P.S. I found similar problem discussed in this thread, but in this case Octave loops upon command execution.

[Dmitri A. Sergatskov]

On Thu, Oct 29, 2009 at 3:40 PM, Georgi D. Sotirov <gdsotirov@...> wrote:

> issue). Then, I noticed that octave runs normally if compiled without
> system's LAPACK (./configure --without-lapack). In this case LAPACK is
> compiled for libcruft with just "-O -mieee-fp" flags.
>
> Any suggestions? Is the problem in Octave or it's in LAPACK? How could I
> help for the resolving of this problem?
>

dlamch has to be compiled with -O.

> P.S. I found similar problem discussed in this thread, but in this case
> Octave loops upon command execution.
>

Dmitri.
--
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Jaroslav Hajek-2]

On Thu, Oct 29, 2009 at 3:40 PM, Georgi D. Sotirov <gdsotirov@...> wrote:

> Hello,
>
> I encounter the following problem on Slackware Linux 13.0 with LAPACK 3.2.1
> and Octave 3.2.3. When I run octave it uses almost the whole CPU time on the
> machine, without being able to finish. I've traced the problem to the
> following:
>
> # gdb /usr/bin/octave
> GNU gdb 6.8
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i486-slackware-linux"...
> (no debugging symbols found)
> (gdb) r
> Starting program: /usr/bin/octave
> (no debugging symbols found)
> [Thread debugging using libthread_db enabled]
> (no debugging symbols found)
> [New Thread 0xb599e8e0 (LWP 3266)]
> (no debugging symbols found)
> ^C
> Program received signal SIGINT, Interrupt.
> [Switching to Thread 0xb599e8e0 (LWP 3266)]
> 0xb66bb908 in dlamc3_ () from /usr/lib/liblapack.so.3.2.1
> (gdb) bt
> #0  0xb66bb908 in dlamc3_ () from /usr/lib/liblapack.so.3.2.1
> #1  0xb66bc4c2 in dlamc1_ () from /usr/lib/liblapack.so.3.2.1
> #2  0xb66bbca0 in dlamc2_ () from /usr/lib/liblapack.so.3.2.1
> #3  0xb66bc576 in dlamch_ () from /usr/lib/liblapack.so.3.2.1
> #4  0xb6837bc5 in d1mach_ () from /usr/lib/octave-3.2.3/libcruft.so
> #5  0xb69f158d in oct_mach_info::init_float_format () from
> /usr/lib/octave-3.2.3/liboctave.so
> #6  0xb69f1682 in oct_mach_info::oct_mach_info () from
> /usr/lib/octave-3.2.3/liboctave.so
> #7  0xb69f16ee in oct_mach_info::instance_ok () from
> /usr/lib/octave-3.2.3/liboctave.so
> #8  0xb69f17b7 in oct_mach_info::native_float_format () from
> /usr/lib/octave-3.2.3/liboctave.so
> #9  0xb69de464 in octave_ieee_init () from
> /usr/lib/octave-3.2.3/liboctave.so
> #10 0xb7789b77 in sysdep_init () from /usr/lib/octave-3.2.3/liboctinterp.so
> #11 0xb772187a in octave_main () from /usr/lib/octave-3.2.3/liboctinterp.so
> #12 0x080486da in main ()
> (gdb) c
> Continuing.
> ^C
> Program received signal SIGINT, Interrupt.
> 0xb62c65c4 in dlamc3_@plt () from /usr/lib/liblapack.so.3.2.1
> (gdb) bt
> #0  0xb62c65c4 in dlamc3_@plt () from /usr/lib/liblapack.so.3.2.1
> #1  0xb66bc4c2 in dlamc1_ () from /usr/lib/liblapack.so.3.2.1
> #2  0xb66bbca0 in dlamc2_ () from /usr/lib/liblapack.so.3.2.1
> #3  0xb66bc576 in dlamch_ () from /usr/lib/liblapack.so.3.2.1
> #4  0xb6837bc5 in d1mach_ () from /usr/lib/octave-3.2.3/libcruft.so
> #5  0xb69f158d in oct_mach_info::init_float_format () from
> /usr/lib/octave-3.2.3/liboctave.so
> #6  0xb69f1682 in oct_mach_info::oct_mach_info () from
> /usr/lib/octave-3.2.3/liboctave.so
> #7  0xb69f16ee in oct_mach_info::instance_ok () from
> /usr/lib/octave-3.2.3/liboctave.so
> #8  0xb69f17b7 in oct_mach_info::native_float_format () from
> /usr/lib/octave-3.2.3/liboctave.so
> #9  0xb69de464 in octave_ieee_init () from
> /usr/lib/octave-3.2.3/liboctave.so
> #10 0xb7789b77 in sysdep_init () from /usr/lib/octave-3.2.3/liboctinterp.so
> #11 0xb772187a in octave_main () from /usr/lib/octave-3.2.3/liboctinterp.so
> #12 0x080486da in main ()
>
> It seems, that Octave is stuck on an infinite loop in LAPACK, which in my
> case is compiled as a separate shared library by gcc 4.3.3 with flags
> "-fimplicit-none -O -mieee-fp -march=i486 -mtune=i686 -fPIC". I have the
> same problem with flags "-fimplicit-none -O2 -march=i486 -mtune=i686 -fPIC"
> and also with "-O3" (I've though at one point it may be some optimization
> issue). Then, I noticed that octave runs normally if compiled without
> system's LAPACK (./configure --without-lapack). In this case LAPACK is
> compiled for libcruft with just "-O -mieee-fp" flags.
>
> Any suggestions? Is the problem in Octave or it's in LAPACK? How could I
> help for the resolving of this problem?
>

the SLAMCH and DLAMCH routines are sensitive to compiler
optimizations. I use the settings (in make.inc from LAPACK tarball)
NOOPT    = -mieee-fp -ffloat-store -fPIC
and it works well. I think that in future releases these routines will
be replaced by querying Fortran 90 internals.

hth

--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Michael Goffioul-2]

On Mon, Nov 2, 2009 at 9:58 AM, Jaroslav Hajek <highegg@...> wrote:
> the SLAMCH and DLAMCH routines are sensitive to compiler
> optimizations. I use the settings (in make.inc from LAPACK tarball)
> NOOPT    = -mieee-fp -ffloat-store -fPIC
> and it works well. I think that in future releases these routines will
> be replaced by querying Fortran 90 internals.

Will this still be F77 compatible or will it definitely require a F90
compiler?

Michael.

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Jaroslav Hajek-2]

On Mon, Nov 2, 2009 at 11:22 AM, Michael Goffioul
<michael.goffioul@...> wrote:

> On Mon, Nov 2, 2009 at 9:58 AM, Jaroslav Hajek <highegg@...> wrote:
>> the SLAMCH and DLAMCH routines are sensitive to compiler
>> optimizations. I use the settings (in make.inc from LAPACK tarball)
>> NOOPT    = -mieee-fp -ffloat-store -fPIC
>> and it works well. I think that in future releases these routines will
>> be replaced by querying Fortran 90 internals.
>
> Will this still be F77 compatible or will it definitely require a F90
> compiler?
>
> Michael.
>

See
http://www.netlib.org/lapack/lapack-3.2.html#_7_install_procedure

--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Michael Goffioul-2]

On Mon, Nov 2, 2009 at 10:24 AM, Jaroslav Hajek <highegg@...> wrote:
> See
> http://www.netlib.org/lapack/lapack-3.2.html#_7_install_procedure

Too bad. I think I'll definitely be out of the game then.

Michael.
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Jaroslav Hajek-2]

On Mon, Nov 2, 2009 at 11:27 AM, Michael Goffioul
<michael.goffioul@...> wrote:
> On Mon, Nov 2, 2009 at 10:24 AM, Jaroslav Hajek <highegg@...> wrote:
>> See
>> http://www.netlib.org/lapack/lapack-3.2.html#_7_install_procedure
>
> Too bad. I think I'll definitely be out of the game then.
>
> Michael.
>

I think Octave will long stay buildable with lapack 3.1 and earlier.
IMHO we should do so unless F90 becomes also required for Octave.

--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[John W. Eaton-3]

On  2-Nov-2009, Jaroslav Hajek wrote:

| On Mon, Nov 2, 2009 at 11:27 AM, Michael Goffioul
| <michael.goffioul@...> wrote:
| > On Mon, Nov 2, 2009 at 10:24 AM, Jaroslav Hajek <highegg@...> wrote:
| >> See
| >> http://www.netlib.org/lapack/lapack-3.2.html#_7_install_procedure
| >
| > Too bad. I think I'll definitely be out of the game then.
| >
| > Michael.
| >
|
| I think Octave will long stay buildable with lapack 3.1 and earlier.
| IMHO we should do so unless F90 becomes also required for Octave.

Maybe it is time for me to ask again whether we should continue to
distribute portions of the reference lapack and blas with Octave.

I'd rather not distribute old versions of these libraries with Octave,
so maybe now is the time to drop them and simply require that there
are external blas and lapack libraries available when building Octave.

Comments?

jwe
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Jaroslav Hajek-2]

On Mon, Nov 2, 2009 at 5:00 PM, John W. Eaton <jwe@...> wrote:

> On  2-Nov-2009, Jaroslav Hajek wrote:
>
> | On Mon, Nov 2, 2009 at 11:27 AM, Michael Goffioul
> | <michael.goffioul@...> wrote:
> | > On Mon, Nov 2, 2009 at 10:24 AM, Jaroslav Hajek <highegg@...> wrote:
> | >> See
> | >> http://www.netlib.org/lapack/lapack-3.2.html#_7_install_procedure
> | >
> | > Too bad. I think I'll definitely be out of the game then.
> | >
> | > Michael.
> | >
> |
> | I think Octave will long stay buildable with lapack 3.1 and earlier.
> | IMHO we should do so unless F90 becomes also required for Octave.
>
> Maybe it is time for me to ask again whether we should continue to
> distribute portions of the reference lapack and blas with Octave.
>
> I'd rather not distribute old versions of these libraries with Octave,
> so maybe now is the time to drop them and simply require that there
> are external blas and lapack libraries available when building Octave.
>
> Comments?
>
> jwe
>

I think the BLAS and LAPACK are a little special in the sense that
they're (AFAIK) the only strong requirement for Octave. If any other
dependency is missing, Octave will build and work, though with some
crippled functionality.
OTOH, BLAS and LAPACK are now almost universally available, so maybe
nobody actually needs this feature. In that case, I think it's fine to
drop these sources. It will also plausibly reduce Octave's code size.


--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Søren Hauberg]

man, 02 11 2009 kl. 18:11 +0100, skrev Jaroslav Hajek:
> I think the BLAS and LAPACK are a little special in the sense that
> they're (AFAIK) the only strong requirement for Octave. If any other
> dependency is missing, Octave will build and work, though with some
> crippled functionality.
> OTOH, BLAS and LAPACK are now almost universally available, so maybe
> nobody actually needs this feature. In that case, I think it's fine to
> drop these sources. It will also plausibly reduce Octave's code size.

One advantage of dropping BLAS and LAPACK from the sources is that the
user don't end up using these by accident instead of using the system
libraries.

Søren

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Sergei Steshenko-2]

--- On Mon, 11/2/09, Michael Goffioul <michael.goffioul@...> wrote:

> From: Michael Goffioul <michael.goffioul@...>
> Subject: Re: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so
> To: "Jaroslav Hajek" <highegg@...>
> Cc: "Georgi D. Sotirov" <gdsotirov@...>, bug-octave@...
> Date: Monday, November 2, 2009, 2:27 AM
> On Mon, Nov 2, 2009 at 10:24 AM,
> Jaroslav Hajek <highegg@...>
> wrote:
> > See
> > http://www.netlib.org/lapack/lapack-3.2.html#_7_install_procedure
>
> Too bad. I think I'll definitely be out of the game then.
>
> Michael.
> _______________________________________________

Isn't 'gfortran' coming with latest 'gcc' good enough ? My understanding is
that 'gfortran' is f95, i.e. even later than f90.

Thanks,
  Sergei.



     
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Jaroslav Hajek-2]

On Tue, Nov 3, 2009 at 11:51 AM, Sergei Steshenko <sergstesh@...> wrote:

>
>
> --- On Mon, 11/2/09, Michael Goffioul <michael.goffioul@...> wrote:
>
>> From: Michael Goffioul <michael.goffioul@...>
>> Subject: Re: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so
>> To: "Jaroslav Hajek" <highegg@...>
>> Cc: "Georgi D. Sotirov" <gdsotirov@...>, bug-octave@...
>> Date: Monday, November 2, 2009, 2:27 AM
>> On Mon, Nov 2, 2009 at 10:24 AM,
>> Jaroslav Hajek <highegg@...>
>> wrote:
>> > See
>> > http://www.netlib.org/lapack/lapack-3.2.html#_7_install_procedure
>>
>> Too bad. I think I'll definitely be out of the game then.
>>
>> Michael.
>> _______________________________________________
>
>
> Isn't 'gfortran' coming with latest 'gcc' good enough ? My understanding is
> that 'gfortran' is f95, i.e. even later than f90.
>
> Thanks,
>  Sergei.
>

gfortran is almost complete f2003 plus a few f2008 features. Yes, it's
more than sufficient to compile LAPACK.
But IIRC, Michael's problem was elsewhere, something about the runtime
libraries (MSVC vs. GCC).

--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Michael Goffioul-2]

On Tue, Nov 3, 2009 at 10:51 AM, Sergei Steshenko <sergstesh@...> wrote:
>> Too bad. I think I'll definitely be out of the game then.
>>
>> Michael.
>> _______________________________________________
>
>
> Isn't 'gfortran' coming with latest 'gcc' good enough ? My understanding is
> that 'gfortran' is f95, i.e. even later than f90.

As Jaroslav pointed out, gfortran is not compatible with MS compilers.
The only free solution is f2c, which is f77 only.

Michael.
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Sergei Steshenko-2]

--- On Tue, 11/3/09, Michael Goffioul <michael.goffioul@...> wrote:

> From: Michael Goffioul <michael.goffioul@...>
> Subject: Re: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so
> To: "Sergei Steshenko" <sergstesh@...>
> Cc: "Jaroslav Hajek" <highegg@...>, "Georgi D. Sotirov" <gdsotirov@...>, bug-octave@...
> Date: Tuesday, November 3, 2009, 3:45 AM
> On Tue, Nov 3, 2009 at 10:51 AM,
> Sergei Steshenko <sergstesh@...>
> wrote:
> >> Too bad. I think I'll definitely be out of the
> game then.
> >>
> >> Michael.
> >> _______________________________________________
> >
> >
> > Isn't 'gfortran' coming with latest 'gcc' good enough
> ? My understanding is
> > that 'gfortran' is f95, i.e. even later than f90.
>
> As Jaroslav pointed out, gfortran is not compatible with MS
> compilers.
> The only free solution is f2c, which is f77 only.
>
> Michael.
>

Well, there is cross-gcc, i.e. you can compile for Windows on a Linux/UNIX
box. Though it doesn't guarantee MS compilers compatibility.

And there is MinGW 'gcc'.

Should 'octave' for Windows be necessarily compiled by MS compilers ?

Thanks,
  Sergei.


     
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Michael Goffioul-2]

On Tue, Nov 3, 2009 at 11:59 AM, Sergei Steshenko <sergstesh@...> wrote:

>
>
> --- On Tue, 11/3/09, Michael Goffioul <michael.goffioul@...> wrote:
>
>> From: Michael Goffioul <michael.goffioul@...>
>> Subject: Re: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so
>> To: "Sergei Steshenko" <sergstesh@...>
>> Cc: "Jaroslav Hajek" <highegg@...>, "Georgi D. Sotirov" <gdsotirov@...>, bug-octave@...
>> Date: Tuesday, November 3, 2009, 3:45 AM
>> On Tue, Nov 3, 2009 at 10:51 AM,
>> Sergei Steshenko <sergstesh@...>
>> wrote:
>> >> Too bad. I think I'll definitely be out of the
>> game then.
>> >>
>> >> Michael.
>> >> _______________________________________________
>> >
>> >
>> > Isn't 'gfortran' coming with latest 'gcc' good enough
>> ? My understanding is
>> > that 'gfortran' is f95, i.e. even later than f90.
>>
>> As Jaroslav pointed out, gfortran is not compatible with MS
>> compilers.
>> The only free solution is f2c, which is f77 only.
>>
>> Michael.
>>
>
> Well, there is cross-gcc, i.e. you can compile for Windows on a Linux/UNIX
> box. Though it doesn't guarantee MS compilers compatibility.
>
> And there is MinGW 'gcc'.
>
> Should 'octave' for Windows be necessarily compiled by MS compilers ?

No. OTOH, do we want octave to be only compilable by gcc?

Michael.
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Ben Abbott]

On Nov 2, 2009, at 4:58 AM, Jaroslav Hajek wrote:

> On Thu, Oct 29, 2009 at 3:40 PM, Georgi D. Sotirov  
> <gdsotirov@...> wrote:
>> Hello,
>>
>> I encounter the following problem on Slackware Linux 13.0 with  
>> LAPACK 3.2.1
>> and Octave 3.2.3. When I run octave it uses almost the whole CPU  
>> time on the
>> machine, without being able to finish. I've traced the problem to the
>> following:
>>
>> # gdb /usr/bin/octave
>> GNU gdb 6.8
>> Copyright (C) 2008 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show  
>> copying"
>> and "show warranty" for details.
>> This GDB was configured as "i486-slackware-linux"...
>> (no debugging symbols found)
>> (gdb) r
>> Starting program: /usr/bin/octave
>> (no debugging symbols found)
>> [Thread debugging using libthread_db enabled]
>> (no debugging symbols found)
>> [New Thread 0xb599e8e0 (LWP 3266)]
>> (no debugging symbols found)
>> ^C
>> Program received signal SIGINT, Interrupt.
>> [Switching to Thread 0xb599e8e0 (LWP 3266)]
>> 0xb66bb908 in dlamc3_ () from /usr/lib/liblapack.so.3.2.1
>> (gdb) bt
>> #0  0xb66bb908 in dlamc3_ () from /usr/lib/liblapack.so.3.2.1
>> #1  0xb66bc4c2 in dlamc1_ () from /usr/lib/liblapack.so.3.2.1
>> #2  0xb66bbca0 in dlamc2_ () from /usr/lib/liblapack.so.3.2.1
>> #3  0xb66bc576 in dlamch_ () from /usr/lib/liblapack.so.3.2.1
>> #4  0xb6837bc5 in d1mach_ () from /usr/lib/octave-3.2.3/libcruft.so
>> #5  0xb69f158d in oct_mach_info::init_float_format () from
>> /usr/lib/octave-3.2.3/liboctave.so
>> #6  0xb69f1682 in oct_mach_info::oct_mach_info () from
>> /usr/lib/octave-3.2.3/liboctave.so
>> #7  0xb69f16ee in oct_mach_info::instance_ok () from
>> /usr/lib/octave-3.2.3/liboctave.so
>> #8  0xb69f17b7 in oct_mach_info::native_float_format () from
>> /usr/lib/octave-3.2.3/liboctave.so
>> #9  0xb69de464 in octave_ieee_init () from
>> /usr/lib/octave-3.2.3/liboctave.so
>> #10 0xb7789b77 in sysdep_init () from /usr/lib/octave-3.2.3/
>> liboctinterp.so
>> #11 0xb772187a in octave_main () from /usr/lib/octave-3.2.3/
>> liboctinterp.so
>> #12 0x080486da in main ()
>> (gdb) c
>> Continuing.
>> ^C
>> Program received signal SIGINT, Interrupt.
>> 0xb62c65c4 in dlamc3_@plt () from /usr/lib/liblapack.so.3.2.1
>> (gdb) bt
>> #0  0xb62c65c4 in dlamc3_@plt () from /usr/lib/liblapack.so.3.2.1
>> #1  0xb66bc4c2 in dlamc1_ () from /usr/lib/liblapack.so.3.2.1
>> #2  0xb66bbca0 in dlamc2_ () from /usr/lib/liblapack.so.3.2.1
>> #3  0xb66bc576 in dlamch_ () from /usr/lib/liblapack.so.3.2.1
>> #4  0xb6837bc5 in d1mach_ () from /usr/lib/octave-3.2.3/libcruft.so
>> #5  0xb69f158d in oct_mach_info::init_float_format () from
>> /usr/lib/octave-3.2.3/liboctave.so
>> #6  0xb69f1682 in oct_mach_info::oct_mach_info () from
>> /usr/lib/octave-3.2.3/liboctave.so
>> #7  0xb69f16ee in oct_mach_info::instance_ok () from
>> /usr/lib/octave-3.2.3/liboctave.so
>> #8  0xb69f17b7 in oct_mach_info::native_float_format () from
>> /usr/lib/octave-3.2.3/liboctave.so
>> #9  0xb69de464 in octave_ieee_init () from
>> /usr/lib/octave-3.2.3/liboctave.so
>> #10 0xb7789b77 in sysdep_init () from /usr/lib/octave-3.2.3/
>> liboctinterp.so
>> #11 0xb772187a in octave_main () from /usr/lib/octave-3.2.3/
>> liboctinterp.so
>> #12 0x080486da in main ()
>>
>> It seems, that Octave is stuck on an infinite loop in LAPACK, which  
>> in my
>> case is compiled as a separate shared library by gcc 4.3.3 with flags
>> "-fimplicit-none -O -mieee-fp -march=i486 -mtune=i686 -fPIC". I  
>> have the
>> same problem with flags "-fimplicit-none -O2 -march=i486 -
>> mtune=i686 -fPIC"
>> and also with "-O3" (I've though at one point it may be some  
>> optimization
>> issue). Then, I noticed that octave runs normally if compiled without
>> system's LAPACK (./configure --without-lapack). In this case LAPACK  
>> is
>> compiled for libcruft with just "-O -mieee-fp" flags.
>>
>> Any suggestions? Is the problem in Octave or it's in LAPACK? How  
>> could I
>> help for the resolving of this problem?
>>
>
> the SLAMCH and DLAMCH routines are sensitive to compiler
> optimizations. I use the settings (in make.inc from LAPACK tarball)
> NOOPT    = -mieee-fp -ffloat-store -fPIC
> and it works well. I think that in future releases these routines will
> be replaced by querying Fortran 90 internals.
>
> hth

I just noticed this thread. I've burned a unexpected amount of time  
trying to compile a fortran program  that requires lapack under  
Windows. Today I switched from lapack 3.2.1 to lapack 3.1.1 and my  
problems have disappeared.

I have also traced the problem to dlamch ... thus, I'm responding  
because using lapack 3.1.1 may resolve this problem as well.

Ben



_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Georgi D. Sotirov]

Jaroslav Hajek wrote:

On Thu, Oct 29, 2009 at 3:40 PM, Georgi D. Sotirov gdsotirov@... wrote:
  

Hello,

I encounter the following problem on Slackware Linux 13.0 with LAPACK 3.2.1
and Octave 3.2.3. When I run octave it uses almost the whole CPU time on the
machine, without being able to finish. I've traced the problem to the
following:

# gdb /usr/bin/octave
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-slackware-linux"...
(no debugging symbols found)
(gdb) r
Starting program: /usr/bin/octave
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
(no debugging symbols found)
[New Thread 0xb599e8e0 (LWP 3266)]
(no debugging symbols found)
^C
Program received signal SIGINT, Interrupt.
[Switching to Thread 0xb599e8e0 (LWP 3266)]
0xb66bb908 in dlamc3_ () from /usr/lib/liblapack.so.3.2.1
(gdb) bt
#0  0xb66bb908 in dlamc3_ () from /usr/lib/liblapack.so.3.2.1
#1  0xb66bc4c2 in dlamc1_ () from /usr/lib/liblapack.so.3.2.1
#2  0xb66bbca0 in dlamc2_ () from /usr/lib/liblapack.so.3.2.1
#3  0xb66bc576 in dlamch_ () from /usr/lib/liblapack.so.3.2.1
#4  0xb6837bc5 in d1mach_ () from /usr/lib/octave-3.2.3/libcruft.so
#5  0xb69f158d in oct_mach_info::init_float_format () from
/usr/lib/octave-3.2.3/liboctave.so
#6  0xb69f1682 in oct_mach_info::oct_mach_info () from
/usr/lib/octave-3.2.3/liboctave.so
#7  0xb69f16ee in oct_mach_info::instance_ok () from
/usr/lib/octave-3.2.3/liboctave.so
#8  0xb69f17b7 in oct_mach_info::native_float_format () from
/usr/lib/octave-3.2.3/liboctave.so
#9  0xb69de464 in octave_ieee_init () from
/usr/lib/octave-3.2.3/liboctave.so
#10 0xb7789b77 in sysdep_init () from /usr/lib/octave-3.2.3/liboctinterp.so
#11 0xb772187a in octave_main () from /usr/lib/octave-3.2.3/liboctinterp.so
#12 0x080486da in main ()
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0xb62c65c4 in dlamc3_@plt () from /usr/lib/liblapack.so.3.2.1
(gdb) bt
#0  0xb62c65c4 in dlamc3_@plt () from /usr/lib/liblapack.so.3.2.1
#1  0xb66bc4c2 in dlamc1_ () from /usr/lib/liblapack.so.3.2.1
#2  0xb66bbca0 in dlamc2_ () from /usr/lib/liblapack.so.3.2.1
#3  0xb66bc576 in dlamch_ () from /usr/lib/liblapack.so.3.2.1
#4  0xb6837bc5 in d1mach_ () from /usr/lib/octave-3.2.3/libcruft.so
#5  0xb69f158d in oct_mach_info::init_float_format () from
/usr/lib/octave-3.2.3/liboctave.so
#6  0xb69f1682 in oct_mach_info::oct_mach_info () from
/usr/lib/octave-3.2.3/liboctave.so
#7  0xb69f16ee in oct_mach_info::instance_ok () from
/usr/lib/octave-3.2.3/liboctave.so
#8  0xb69f17b7 in oct_mach_info::native_float_format () from
/usr/lib/octave-3.2.3/liboctave.so
#9  0xb69de464 in octave_ieee_init () from
/usr/lib/octave-3.2.3/liboctave.so
#10 0xb7789b77 in sysdep_init () from /usr/lib/octave-3.2.3/liboctinterp.so
#11 0xb772187a in octave_main () from /usr/lib/octave-3.2.3/liboctinterp.so
#12 0x080486da in main ()

It seems, that Octave is stuck on an infinite loop in LAPACK, which in my
case is compiled as a separate shared library by gcc 4.3.3 with flags
"-fimplicit-none -O -mieee-fp -march=i486 -mtune=i686 -fPIC". I have the
same problem with flags "-fimplicit-none -O2 -march=i486 -mtune=i686 -fPIC"
and also with "-O3" (I've though at one point it may be some optimization
issue). Then, I noticed that octave runs normally if compiled without
system's LAPACK (./configure --without-lapack). In this case LAPACK is
compiled for libcruft with just "-O -mieee-fp" flags.

Any suggestions? Is the problem in Octave or it's in LAPACK? How could I
help for the resolving of this problem?

    

the SLAMCH and DLAMCH routines are sensitive to compiler
optimizations. I use the settings (in make.inc from LAPACK tarball)
NOOPT    = -mieee-fp -ffloat-store -fPIC
and it works well. I think that in future releases these routines will
be replaced by querying Fortran 90 internals.

hth

  

Hello,

Thank you for this suggestion. These compilation flags ultimately solved the problem. Octave now works perfectly on Slackware 13.0 with system's LAPACK.

Kind Regards,



_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Georgi D. Sotirov]

Søren Hauberg wrote:

man, 02 11 2009 kl. 18:11 +0100, skrev Jaroslav Hajek:
  

I think the BLAS and LAPACK are a little special in the sense that
they're (AFAIK) the only strong requirement for Octave. If any other
dependency is missing, Octave will build and work, though with some
crippled functionality.
OTOH, BLAS and LAPACK are now almost universally available, so maybe
nobody actually needs this feature. In that case, I think it's fine to
drop these sources. It will also plausibly reduce Octave's code size.
    

One advantage of dropping BLAS and LAPACK from the sources is that the
user don't end up using these by accident instead of using the system
libraries.

Søren

  

Hello,

Wow, I didn't thought that my thread will trigger such discussion. Anyway, as software developer and Slackware package builder, I think the best is to use system libraries, even a bit harder in cases like this one. This gives even better flexibility to a redistributable packages as Octave.

Best Regards,



_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Sergei Steshenko-2]

--- On Tue, 11/3/09, Michael Goffioul <michael.goffioul@...> wrote:

> From: Michael Goffioul <michael.goffioul@...>
> Subject: Re: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so
> To: "Sergei Steshenko" <sergstesh@...>
> Cc: "Jaroslav Hajek" <highegg@...>, "Georgi D. Sotirov" <gdsotirov@...>, bug-octave@...
> Date: Tuesday, November 3, 2009, 12:39 PM
> On Tue, Nov 3, 2009 at 11:59 AM,
> Sergei Steshenko <sergstesh@...>
> wrote:
> >
> >
> > --- On Tue, 11/3/09, Michael Goffioul <michael.goffioul@...>
> wrote:
> >
> >> From: Michael Goffioul <michael.goffioul@...>
> >> Subject: Re: Octave loops infinitely in dlamc3_
> from /usr/lib/liblapack.so
> >> To: "Sergei Steshenko" <sergstesh@...>
> >> Cc: "Jaroslav Hajek" <highegg@...>,
> "Georgi D. Sotirov" <gdsotirov@...>,
> bug-octave@...
> >> Date: Tuesday, November 3, 2009, 3:45 AM
> >> On Tue, Nov 3, 2009 at 10:51 AM,
> >> Sergei Steshenko <sergstesh@...>
> >> wrote:
> >> >> Too bad. I think I'll definitely be out
> of the
> >> game then.
> >> >>
> >> >> Michael.
> >> >>
> _______________________________________________
> >> >
> >> >
> >> > Isn't 'gfortran' coming with latest 'gcc'
> good enough
> >> ? My understanding is
> >> > that 'gfortran' is f95, i.e. even later than
> f90.
> >>
> >> As Jaroslav pointed out, gfortran is not
> compatible with MS
> >> compilers.
> >> The only free solution is f2c, which is f77 only.
> >>
> >> Michael.
> >>
> >
> > Well, there is cross-gcc, i.e. you can compile for
> Windows on a Linux/UNIX
> > box. Though it doesn't guarantee MS compilers
> compatibility.
> >
> > And there is MinGW 'gcc'.
> >
> > Should 'octave' for Windows be necessarily compiled by
> MS compilers ?
>
> No. OTOH, do we want octave to be only compilable by gcc?
>
> Michael.
>

I think you are hiding the real issue in your question.

The real issue that for 'octave' to be compiled wherever, one needs decent
C/C++ compiler + f95 (or later) compiler (because of the latest LAPACK).

The truth is that 'gcc' suite contains both, so going with 'gcc' is the
path of least resistance.

Another possible positive outcome of going with 'gcc' on all OSes is that
C/C++/Fortran quirks will be much more similar - this will make bug fixing
easier.

Regards,
  Sergei.


     
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Søren Hauberg]

tir, 03 11 2009 kl. 20:39 +0000, skrev Michael Goffioul:
> > Should 'octave' for Windows be necessarily compiled by MS compilers ?
>
> No. OTOH, do we want octave to be only compilable by gcc?

There are many (some more silly than others) measures of code quality.
One sign of good quality is that the code compiles with several
different compilers. So, while I only use gcc, I do appreciate the fact
that Octave also works with MSVC.

Søren

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave