64bit foundation bug in Octave2.9.3

[Clinton Chee]

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.



octave:1> ccc(2^30)=0;

Program received signal SIGINT, Interrupt.
[Switching to Thread 2305843009213902096 (LWP 1607)]
0x4000000003250b40 in Array<double>::resize_and_fill () at Array.cc:745
745             xelem (i) = val;
Current language:  auto; currently c++
(gdb) bt
#0  0x4000000003250b40 in Array<double>::resize_and_fill () at Array.cc:745
#1  0x400000000328b500 in assign1 (address@hidden,
    address@hidden) at Array.cc:2488
#2  0x40000000032899e0 in assign2<double, double> () at Array.cc:2737
#3  0x400000000328bd00 in assign (address@hidden, address@hidden,
address@hidden)
    at Array.cc:2434
#4  0x400000000084d320 in octave_base_matrix<NDArray>::assign ()
    at ov-base-mat.cc:207
#5  0x40000000017ca910 in oct_assignop_assign (address@hidden)
    at ./OPERATORS/op-m-s.cc:106
#6  0x4000000000a07270 in numeric_assign (this=0x10,
address@hidden,
    address@hidden, address@hidden) at ov.cc:1510
#7  0x4000000000851a40 in octave_base_matrix<NDArray>::subsasgn ()
    at ov-base-mat.cc:84
#8  0x40000000009ec9e0 in subsasgn (this=0x6000000000a70900, address@hidden,
    address@hidden, address@hidden) at ov.cc:909
#9  0x40000000007e1430 in subsasgn (this=0x60000fffffff9ec0,
    address@hidden, address@hidden,
address@hidden)
    at ov-base.cc:173
#10 0x40000000009ec9e0 in subsasgn (this=0x60000fffffff9ec0,
    address@hidden, address@hidden,
address@hidden)
    at ov.cc:909
#11 0x40000000009ef5d0 in octave_value::assign () at ov.cc:956
#12 0x40000000015682c0 in assign (address@hidden) at
oct-lvalue.cc:37
#13 0x40000000010bcb40 in tree_simple_assignment::rvalue () at
pt-assign.cc:107
#14 0x40000000010bda90 in rvalue (nargout=2) at pt-assign.cc:70
#15 0x40000000011c8300 in tree_statement::eval () at pt-stmt.cc:136
#16 0x40000000011cabd0 in tree_statement_list::eval () at pt-stmt.cc:171
#17 0x400000000076c1a0 in main_loop () at toplev.cc:168
---Type <return> to continue, or q <return> to quit---q
Quit
(gdb) quit
The program is running.  Exit anyway? (y or n) y



*** Please note that the line numbers above may be different from the
real 2.9.3 version, since I am using my own development version.


Thanks
---------------------------------------------------------------------------
Clinton Chee
Computational Scientist
High Performance Computing Unit
Room 2075, Red Centre
University of New South Wales
Australia 2035
chee at parallel stop hpc stop unsw stop edu stop au
Tel: 61 2 9385 6915
----------------------------------------------------------------------------