Mixed kind integer overflow

[clodius__william]

For ifort 18.0.2 I get the following messages in attempting to compile one of my codes:

ifort -c sbox_hashes.f90

sbox_hashes.f90(321): error #6384: The INTEGER(KIND=4) value is out-of-range.

              ] - 2_int64**32, kind=int64 ), int(                 & 

-------------------------^

sbox_hashes.f90(450): error #6384: The INTEGER(KIND=4) value is out-of-range.

              ], kind=int64 ) >= 2_int64**31 ), kind=int32 )

----------------------------------------^

sbox_hashes.f90(63): error #7747: Invalid parameter expression.   [INT]

        mulvey_maps(0:255) = int( merge( int(                     &

-----------------------------^

compilation aborted for sbox_hashes.f90 (code 1)

 I suspect the third message is caused by the other two. I had expected that in mixing integer kind values in an expression the result would have the kind value with the largest number of digits. In that case the indicated expression should result in an in range value. Am I mistaken about the effect of mixing kind values?

[Steve_Lionel]

I think we need to see a minimal but complete source that reproduces the problem. 

[clodius__william]

Below is a simplified version of the code. Note the original version had what I believe was the opposite comparison from what I need to avoid over flows. The idea was to map in a standard conforming way integers sampled from 0 to 2**32-1, to -2**31 to 2**31-1 using the usual interpretation of the two's complement sign bit. The calculations are initially performed in 64 bits. There are nominally three arrays i n the merge, the array of the original samples, the original samples -2**32, and a logical array that is true if the elements of the first array is less than 2**31. The result of the merge should be 64 bit integers between -2**31 and 2**31-1, that the INT then maps to 32 bit integers. The original code hand arrays of 256 elements not 8, and several procedures that used the final array. Note also that errors seem to be raised at the same locations in the code, regardless of the form of the comparison used in the merge, and whether the factors are computed in place or assigned to a parameter that is used in place.

module simplified_mulvey

    use, intrinsic:: iso_fortran_env, only: &
        int8, int16, int32, int64

    implicit none

    integer(int64), parameter:: two_31 = 2_int64**31, two_32 = 2_int64**32

! Ramdom integers used by Bret Mulvey in his substitution box (S-Box) hash.  As
! the integer can exceed 2**31 and gfortran objects to transforming the values
! to a 32 bit integer, use value if < 2**31, else use value - 2**32.
    integer(int32), parameter ::                              &
        mulvey_maps(0:7) = int( merge( int(                   &
            [ int(z'F53E1837',int64), int(z'5F14C86B',int64), &
              int(z'9EE3964C',int64), int(z'FA796D53',int64), &
              int(z'32223FC3',int64), int(z'4D82BC98',int64), &
              int(z'A0C7FA62',int64), int(z'63E2C982',int64)  &
              ], kind=int64 ), int(                           & 
            [ int(z'F53E1837',int64), int(z'5F14C86B',int64), &
              int(z'9EE3964C',int64), int(z'FA796D53',int64), &
              int(z'32223FC3',int64), int(z'4D82BC98',int64), &
              int(z'A0C7FA62',int64), int(z'63E2C982',int64)  &
              ] - 2_int64**32, kind=int64 ), int(             & 
            [ int(z'F53E1837',int64), int(z'5F14C86B',int64), &
              int(z'9EE3964C',int64), int(z'FA796D53',int64), &
              int(z'32223FC3',int64), int(z'4D82BC98',int64), &
              int(z'A0C7FA62',int64), int(z'63E2C982',int64)  &
              ], kind=int64 ) < 2_int64**31 ), kind=int32 )

end module simplified_mulvey

[Steve_Lionel]

I stared at this a while, and made some tweaks for testing. What I end up with is a belief that you have found one or more compiler bugs. Please report them to the Intel online service center. As best as I can tell, this should compile without errors, but I don't discount the possibility I overlooked something.