IF statement works in the opposite way

Question

I have a subroutine ran_init ( length ), in which one IF statement works incorrectly.

The code below is a highly simplified version of my original code:

MODULE ran_state
USE nrtype
IMPLICIT NONE

INTEGER, PARAMETER :: K4B = SELECTED_INT_KIND ( 9 )
INTEGER ( K4B ), PARAMETER :: hg = HUGE ( 1_K4B ), hgm = -hg, hgng = hgm - 1
INTEGER ( K4B ), SAVE :: lenran = 0

CONTAINS

SUBROUTINE ran_init ( length )
USE nrtype; USE nrutil, ONLY: nrerror
IMPLICIT NONE

INTEGER ( K4B ), INTENT ( IN ) :: length
INTEGER ( K4B ) :: hgt

IF ( length < lenran ) RETURN
hgt = hg
PRINT *, hgt, hgt + 1, hgng, hgt + 1 - hgng
IF ( hgt + 1 .NE. hgng ) CALL nrerror ( 'ran_init: arith assump 3 fails' )

END SUBROUTINE

END MODULE ran_state

This code returns the result:

  2147483647 -2147483648 -2147483648           0
 nrerror: ran_init: arith assump 3 fails
STOP program terminated by nrerror

It is seen that values hgt + 1 and hgng are equal to one another, but at the IF statement these values are interpreted as unequal.

Why this can happen?

UPD №1 Some technical details:

I use gfortran as a compiler
the command gfortran --version returns

GNU Fortran (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609

I compile my programs with flags

-O2 -Wall -Wextra -fbacktrace -fcheck=all -g -o

with a level of optimization does not affect on results.

my OS is Ubuntu 16.04LTS 64-bit

UPD №2

I don't know WHY, but if one create a new variable, say, hgtp of type INTEGER ( K4B ) and replace lines

hgt = hg
PRINT *, hgt, hgt + 1, hgng, hgt + 1 - hgng
IF ( hgt + 1 .NE. hgng ) CALL nrerror ( 'ran_init: arith assump 3 fails' )

with lines

hgt = hg
hgtp = hgt + 1
PRINT *, hgt, hgt + 1, hgng, hgt + 1 - hgng
IF ( hgtp .NE. hgng ) CALL nrerror ( 'ran_init: arith assump 3 fails' )

the IF-statement begins to interpret the condition hgtp .NE. hgng as true.

Maybe something to do with integer overflow that turns an int32.max+1 into int32.min. Or some optimization w.r.t. that: something above int32.max is not-equal to any integer. — Joop Eggen, Aug 18 '22 at 13:42
@JoopEggen but why ```PRINT *, hgt + 1``` returns -2147483648? — Vlad Yurchenko, Aug 18 '22 at 13:48
That PRINT outputs the overflown value correctly is very likely. However `2147483647 + 1 .EQ. -2147483648` looks like false though it is true for 32-bits integers, and `.NE.` looks like true. If the comparison fails then **I have no idea,** 64 bits comparison, overflow detection. _Fortran developer wanted._ — Joop Eggen, Aug 18 '22 at 14:16
No valid Fortran program can have that arithmetic condition false (assuming default integer has no larger range than `integer(k4b)`) so a compiler can assume it's always true. For more detail, we'll need to know about how you are compilng (compiler, compiler version, compiler flags, system) and ideally a complete example program. — francescalus, Aug 18 '22 at 15:22
[Does Fortran have undefined behavior?](https://stackoverflow.com/q/57558684/8559300) contains a lot of relevant information. — veryreverie, Aug 19 '22 at 09:08

janneb · Answer 1 · 2022-08-19T06:24:14.660

You're running into integer overflow, which is an undefined operation in Fortran. Meaning that the Fortran processor (compiler and runtime) is allowed to do anything it likes with it, like doing some more or less random calculation, abort the compilation with an error message, abort the program at runtime with an error message, or launch the rockets to start WWIII.

What it means that you cannot rely on some particular behavior if integer overflow happens. Generally compilers will optimize the code to be as fast as possible, assuming no overflow occurs (because then it's undefined behavior and it's the responsibility of the programmer to ensure that the program doesn't get into such a state).

Further, there's two kinds overflow here:

hgt + 1 is kind of obvious, since hgt is equal to HUGE().
hgm - 1 is also an overflow. It's not an overflow on hardware that uses two's complement representation of integers (which is, practically speaking, all hardware out there these days outside maybe some museum piece), however the Fortran model numbers are symmetrical so in the Fortran standard it's an overflow, and again, all bets are off.

(The above assuming you're running on a system where the default integer has the same kind as K4B which should be most systems out there these days unless you're using some -fdefault-integer-8 or such options)

very interesting explanation, I have to figure it out. Thank you! — Vlad Yurchenko, Aug 19 '22 at 09:20

lastchance · Accepted Answer · 2022-08-18T19:54:41.423

2

MODULE ran_state
    IMPLICIT NONE

    INTEGER, PARAMETER :: K4B = SELECTED_INT_KIND ( 9 )
    INTEGER ( K4B ), PARAMETER :: hg = HUGE ( 1_K4B ), hgm = -hg, hgng = hgm - 1
    INTEGER ( K4B ), SAVE :: lenran = 0

CONTAINS

    SUBROUTINE ran_init ( length )
        INTEGER ( K4B ), INTENT ( IN ) :: length
        INTEGER ( K4B ) :: hgt, temp

        hgt = hg
        PRINT *, hgt, hgt + 1, hgng, hgt + 1 - hgng

        temp = hgt + 1
        IF ( temp    /= hgng ) print *, 'temp fails'
        IF ( hgt + 1 /= hgng ) print *, '3    fails'
    END SUBROUTINE

END MODULE ran_state


program main
    use ran_state
    call ran_init( 0_K4B )
end program main

With ifort (intel fortran), default flags:

  2147483647 -2147483648 -2147483648           0

With gfortran, default flags:

  2147483647 -2147483648 -2147483648           0
 3    fails

Something odd about gfortran?

edited Aug 18 '22 at 19:54

answered Aug 18 '22 at 19:46

lastchance

1,436
1
3
12

2

If you ask a Fortran compiler to compile something which isn't Fortran, it doesn't seem fair to describe the output as "odd" – francescalus Aug 18 '22 at 22:03
If you look at the resulting assembler code. `gfortran` version 8 and higher, with allowed optimization, both `print` are triggered. I also don't know how to prohibit the optimization of the second `if`. `ifort` 2021.1.2 without keys optimizes both `if`, but in a different way. `ifort -O0` performs unoptimized 32-bit calculations. – Serge3leo Aug 19 '22 at 03:55
@lastchance you have given a good recipe to avoid the trouble from my question, by introducing an additional variable ```temp```. Thank you! – Vlad Yurchenko Aug 19 '22 at 09:22
To be fair, @Vlad, my code was only there to make the code compileable and enable people to test it. – lastchance Aug 19 '22 at 09:51
3

The correct answer ought to be that of @janneb - if you have overflow (or other undefined behaviour) then all bets are off with the Fortran optimiser. Changing compiler flags with gfortran shows that, in fact. – lastchance Aug 19 '22 at 09:57
@lastchance got what you say, thank you! – Vlad Yurchenko Aug 19 '22 at 11:12

IF statement works in the opposite way

2 Answers2