[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
64bit foundation bug in Octave2.9.3
From: |
John W. Eaton |
Subject: |
64bit foundation bug in Octave2.9.3 |
Date: |
Wed, 15 Jun 2005 11:12:29 -0400 |
On 15-Jun-2005, Clinton Chee wrote:
| Version 2.9.3
| Platform: SGI Altix Itanium2 (linux)
| Compilers: Intel F/C/CC
|
|
| Dear All,
|
| I was following up on Daniel's test of simple indexing to stress test
| the octave64 capability.
|
| ccc(2^4)=0;
|
| this should create a vector of 16 entries filled with zeros
| and it works!
|
| ccc(2^32)=0;
|
| this should create a vector of 4294967296 entries filled with zeros
| BUT it doesn't
|
| After some investigation, I found:
| ccc(2^31) --> octave thinks it is ---> ccc(2147483648) CORRECT
| ccc(2^31+50) --> octave thinks it is ---> ccc( -2147483598) WRONG
| ccc(2^31+100) --> octave thinks it is ---> ccc( -2147483548) WRONG
| ccc(2^32) --> octave thinks it is ---> ccc(0) WRONG
|
| In short, there's an error in the indexing which still seems to be "int"
| instead of the "octave_idx_type" index which I supposed to have change.
|
| I tried tracing the bug but can't really nail it down. I can't find
| which class or function which I've missed changing the index. From the
| backtrace of a process that is actually giving the right result (eg,
| ccc(2^30) = 0; ), the following backtrace from gdb is obtained.
I did a liitle more checking on a 64-bit system with the latest CVS
sources and when I try
x(2^32) = 0;
and break in
Array<double>::resize_and_fill (octave_idx_type n, const double& val)
the value of N is 4294967296. On the system I'm using, this
subsequently fails with an out of memory message, but I don't see that
anything is incorrect in the indexing.
jwe