What are the compilation arguments required to avoid Intel Fortran having extended precision on single precision variables (REAL*4 to only store 32bits)

[jdall4]

I recently moved from CVF to Intel parallel Studio XE Version 18.0.30.15. Unfortunately the results for my program differ following the compilers and it seems to be related to the floating point representation of numbers. The difference arise when assigning a single precision variable in a double precision variable. With the Intel Fortran compiler it looks like there is an extended precision applied to the single variable. I am looking for a way to get rid of the extended precision but could not find any compilation arguments achieving this (my application calculates the transient behavior of a Gas Turbine and end up crashing with Intel, I need to align exactly the calculations to understand the crash).

The bit of code where I observe a difference is doing an simple interpolation​ using single precision parameter. For the example below the value calculated is 1.001070 (this is a single precision parameter and all 7 significant figures are shown). According to the web sites http://www.binaryconvert.com/result_float.html?decimal=049046048048049048055048 and https://www.h-schmidt.net/FloatConverter/IEEE754.html, the binary approximation of this single is 1.0010700225830078125.  When assigning the calculated single 1.001070 to a double in CFV I get 1.00107002258301,this is the expected result. However when run with Intel the double get assigned to 1.0010702610015869.  In Intel Fortran, if I manually assign the single to 1.001070 then the double get assigned to the expected value of 1.00107002258301. This leads me to think that when the single variable is calculated in Intel FORTRAN, it retain some extended accuracy. To support that I write the single and double with additional precision and they both match.

I tried to add the following compilation arguments without any success:

/Qimf-arch-consistency:true

/Qfma-

/fp:consistent

/Qimf-use-svml

Is there any option that would make my single precision variable (REAL*4) to stick to 32bits?

program test

REAL*4 V(3)

REAL*4 FT(3)

double precision DRRNRAT

double precision CWRE

REAL*4 X, F

OPEN(72,FILE='C:\Temp\test\Debug\test.txt',Access = 'append',Status='unknown')

! Manually assign a value of 1.001070 to a single

F = 1.001070

CWRE = F ! assign a single in a double

write(72,*) 'Case 1:',F,CWRE ! displays Case 1: 1.001070 1.00107002258301

write(72,"(f18.16)") F ! displays 1.0010700225830078

write(72,"(f18.16)") CWRE ! displays 1.0010700225830078

!-----------------------------------------

! Calculate a value of 1.001070 in a single and then assign to double

DRRNRAT = 1.16039185201801

X = DRRNRAT ! assign a double in a single!

V(1) = 1.000000

V(2) = 1.200000

V(3) = 1.500000

FT(1) = 1.000000

FT(2) = 1.001300

FT(3) = 1.002600

DO 360 I = 1 , 2

K = I + 1

DO 360 J = K , 3

360 FT(J)=((X-V(I))*FT(J)-(X-V(J))*FT(I))/(V(J)-V(I))

F = FT(3) ! assign a single to a single, this shows as 1.001070 in debug

CWRE = F ! assign a single to a double

write(72,*) 'Case 2:',F,CWRE

! CFV displays  Case 2: 1.001070 1.00107002258301

! Intel displays Case 2: 1.001070 1.00107026100159

write(72,"(f18.16)") F ! displays 1.0010702610015869

write(72,"(f18.16)") CWRE ! displays 1.0010702610015869

CLOSE(72)

end program test

Many thanks to anyone who can explain how to fix (or what I am not understanding if FP representation)

Jonathan

[DHilt]

There is the compiler option /real-size:32

I'm not sure how that will react with code having explicit declarations of double precision variables.

Sorry. Good luck.