Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

pick-up integer miss-match

Christian_G_2
Beginner
1,305 Views

just wonder if there is a way to pick-up integer miss-match (see simple example below) as it might frequnetly appear when porting from Win32 to x64. Any suggestions how I can find such flaws? Useful compiler options, etc..

program test

    integer(4)  i4

    integer(8)  i8

    i8 = 2

    do i = 1,19

        i4= i8   ! here is the miss-match that leads to problems for i>10

        write (*,*) 'i4= ', i4, ';   i8=', i8

        i8 = 10*i8

    enddo

    read(*,*)

end program test

0 Kudos
1 Solution
mecej4
Honored Contributor III
1,305 Views

Sometimes you can benefit by obtaining a second opinion using a different compiler:

misi.f90:11:12:

         i4= i8   ! here is the miss-match that leads to problems for i>10
            1
Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4) at (1) [-Wconversion]

says Gfortran.

View solution in original post

0 Kudos
7 Replies
Steven_L_Intel1
Employee
1,305 Views

It is not common for Fortran programs to have such issues going from 32-bit to 64-bit, other than if you declare integers that are supposed to hold addresses. The program you show would fail on either 32-bit or 64-bit.

What you're asking for, I think, is detection of integer overflow, not "mismatch". Fortran has defined semantics for mixed-kinds and numeric types. We don't detect integer overflow, though you're not the first to ask for it. I'll add your request to the list.

This is why it is generally recommended to use named constants, or intrinsics, for kinds in declarations. For example, if you are doing Windows programming we provide a HANDLE kind that is correct for both 32-bit and 64-bit. We also have the INT_PTR_KIND() intrinsic that returns the kind of an address. (There is also C_INTPTR_T in module ISO_C_BINDING.)

0 Kudos
Christian_G_2
Beginner
1,305 Views

Thanks Steve!

That was just an example what I mean and I know that the code fails for both Win32 and x64. Also, I'm fully aware of the HANDLE kind but the original developer did not use it The code was written for Win32, and many local variables in fact hold addresses. Now I try to spot them, and the most important question is: what is the most convenient way?

0 Kudos
Steven_L_Intel1
Employee
1,305 Views

Well, if you're passing these to Windows API routines, then the mismatch in the interface will cause a compile error. But if you're assigning values, there is no good way at present to alert you to the problem. We have seen suggestions for an optional "usage warning" any time there is an implicit type/kind conversion, but I don't see that happening for a while.

0 Kudos
Christian_G_2
Beginner
1,305 Views

Thanks Steve! 

also tried with \warn:all but this implicit type conversion remains silent. Guess I'll have to go through thousands of code lines and check it manually . It's actually wired that no such warning exists, isn't it?

0 Kudos
mecej4
Honored Contributor III
1,306 Views

Sometimes you can benefit by obtaining a second opinion using a different compiler:

misi.f90:11:12:

         i4= i8   ! here is the miss-match that leads to problems for i>10
            1
Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4) at (1) [-Wconversion]

says Gfortran.

0 Kudos
Steven_L_Intel1
Employee
1,305 Views

As I mentioned, we don't give warnings for usage that is specified in the standard, even though it might be problematic. I expect that in the future we will start to do so. As mecej4 says, gfortran and some other compilers do have such an option.

0 Kudos
Christian_G_2
Beginner
1,305 Views

thanks guys - guess I'll use Gfortran to assist me in finding these flaws.

0 Kudos
Reply