Re: Building octave with large matrices support

[John W. Eaton]

On 28-Aug-2009, Jaroslav Hajek wrote:

| It doesn't need to. I don't think there's a good way to safely inquire
| the integer size used in BLAS, but if your Fortran uses 64bit and BLAS
| 32bit, you may get garbage in the upper 32bit of the result from
| ISAMAX, hence the test will fail. But you may also get zero as a side
| effect (if the output is via a 64-bit register that is zeroed first).
| Hmmm. Maybe I can improve the test even further. The problem is that
| args are passed by pointers, so as long as no argument is actually
| outside the 32-bit range, it won't make a difference. And you
| certainly don't want a configure test with an 8GB array...
| 
| The converse, i.e. 32-bit Fortran calling 64-bit BLAS, is almost bound
| to fail in the existing test.

Writing tests for LAPACK shoudn't be too hard because it has some
routines that take integer arrays as arguments (for example, a pivot
vector).  If you pass a vector of pivots in an 8-byte integer array
and the routine is compiled for 4-byte integers, I think any
computation that uses the array will have to be wrong, so we could
easily test for that, and it doesn't require large arrays.
Unfortunately, I don't think that method will work for the BLAS
because it doesn't seem to have any routines that require integer
arrays.

| > | I think we should at least check that the Fortran integer matches
| > | octave_idx_type, which is an assumption made throughout Octave
| > | sources.
| >
| > Yes, this should be done so that the Fortran code that is distributed
| > with Octave will compile correctly, but we also need to check all
| > other libraries that we link with and that we pass octave_idx_type
| > values to.  What's the best way to do that?  I assume it will require
| > running test programs.  Maybe we should move any further discussion to
| > the maintainers list?
| 
| The problem is most imminent in Fortran 77-style libraries, which
| typically don't provide any header files. That includes BLAS and
| LAPACK, ARPACK and QRUPDATE. The latter three less likely, because
| they will typically be compiled by system's Fortran compiler using
| default settings. But there are lots of BLASes. I'll see what I can
| do.

Maybe I'm misunderstanding your comment, but default settings are
probably not 8-byte integers.  For example, on my system, the default
settings would be 4-byte integer values, and I would need to use
something like -fdefault-integer-8 with gfortran to make code compiled
by gfortran work with Octave when building with --enable64.  Even
though I'm running an amd64 Debian system, the numerical libraries
that are distributed in Debian packages are all compiled with 4-byte
Fortran INTEGER values.  I think that's the correct thing to do for
Fortran standard conformance if REAL is a 4-byte value.  So building
Octave with --enable-64 most likely requires rebuilding all the
numerical libraries so that the integer values are 8-byte integers.

jwe