Debug and Release versions give different answers

[blwiland]

I have a strange problem. I was making changes to a program andadded the following statement to check the value of a variable "aa":

write(2,*) aa

Simply adding that one statement changed the overall calculations and output significantly. When I removed that onestatement, the previous results returned. It was if I had somehow exceeded the size limits of the code, but no error message was generated. I was compiling and linking a debug version executableand using IVF 8.1.

I thencreated adebug version and release version with the statement in both. The two versions gave different answers.

This is alarge program with a lot of code and arrays. Is it possible for the program to become too big and start giving incorrect answers without some sort of error message being generated?

Bruce

[TimP]

I'm sure you're aware that the usual way to encounter such "surprises" is with un-initialized variables and subscript range violation. Default debug options would initialize many of those to zero, and avoid some optimizations which would break with incorrect source code. The -C options are meant to help with diagnosis.

[jim_dempsey]

As Tim suggestsyour problem would typically reside in un-initialized variables. The Debug options and Runtime options can be set to break on reading an un-initialized variable before writing to it. I would suggest you begin by enabling full debug capabilities including array limit checks and un-initialized variable usage.

Often you will find implicit variables in effect and either a typeo or a missing header file or mod filecausing a local variable to be created and used in place of the intended variable reference. Use of "implicit none" whenever you can will usualy catch most of the problems before debug phase but as we all know sometimes you have to live with the code you are given with and must keep the implicits as-is

Jim Dempsey

[garyrwaters5428]

The other difference that I have seen is in the result of code somewhat like the following (trying to tack the four most significant bits of a two-byte integer on to the end of a four byte integer):

real (kind=8) :: xx, lsb_value
integer (kind=4) :: int_var4
integer (kind=2) :: int_var2

lsb_value = 1.0d0 / 65536.0d0
xx = lsb_value * (int_var4 * 16.0d0 + ishft(ibits(int_var2,Z'F000'),-12) )

In some instances, the result of the ishft(...) is treated as positive, whereas sometimes it takes the sign of int_var2.  In Debug mode, I'm pretty sure that a positive value is always returned.  I think the sign might be inconsistent in Release mode.

-gary

[mecej4]

I don't think that you have correctly described the situation. The intrinsic IBITS takes three arguments, in the form IBITS(i, pos, len), whereas your code snippet shows only two, which the compiler will respond to with "Warning: The number of arguments is incompatible with intrinsic procedure, assume 'external'.   [IBiTS]"

Please present a complete example that demonstrates the behavior claimed.