RE: amber-developers: Two build/test issues

From: Ross Walker <>
Date: Mon, 3 Nov 2008 15:30:40 -0800

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
  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
Received on Fri Dec 05 2008 - 10:35:52 PST
Custom Search