Hi Lachele,
> gfortran -c -O0 -fno-second-underscore -ffree-form -o mt19937.o
> _mt19937.f
> _mt19937.f:324.30:
>
> data temper_b /z'EFC60000'/
> 1
> Error: Arithmetic overflow converting INTEGER(8) to INTEGER(4) at (1)
> _mt19937.f:323.30:
I don't see this problem compiling with gfortran 4.1.2. Everything compiles
okay although when I run the test cases with mpirun -np 4 both the pb_ivcap
test cases crash with signal 11 (segfault):
==============================================================
cd pb_ivcap5 && ./Run.pb_ivcap5
rank 1 in job 151 caffeine.sdsc.edu_41279 caused collective abort of all
ranks
exit status of rank 1: killed by signal 11
./Run.pb_ivcap5: Program error
So whoever maintains the PB code should probably take a look at this.
These are largely broken in serial as well I believe.
AS for the compile problem you are seeing. Looking at the error message it
is complaining that EFC60000 will not fit in an Integer 4 which is correct
(if the Int 4 is signed) - it should fit in an unsigned integer. However,
looking at the code we have:
integer, parameter :: intg = selected_int_kind( 9 )
which should set intg to an integer required to store -10^9 < n < 10^9 which
would be 3B9ACA00 in hex. A signed 32 bit int can store -0x8000000 to
0x8000000 which is a greater range than -0x3B9ACA00 to 0x3B9ACA00 so the
selected_int_kind call should return integer*4.
Then looking further through the code we have:
integer, parameter :: intg = selected_int_kind( 9 )
integer, public, parameter :: wi = intg
integer( kind = wi ) :: seed_d, matrix_a, matrix_b, temper_a, temper_b
data temper_b /z'EFC60000'/
So temper_b is set to of kind wi which is equal to intg so should be int*4
and then the code tries to stuff EFC60000 into that int*4 which of course
cannot work. So how does this code ever work????
Comments anyone...?
All the best
Ross
Received on Fri Dec 05 2008 - 10:35:52 PST
