/fpconstant compiler switch

[JSpielbauer]

RecentlyI updated some single precision code to double precision. This is some very old FORTRAN written on a VAX that has been updated to work on PCs using a number ofdifferent versions of FORTRAN but most recentlyIntel FORTRAN.

The problem is that there was a call from one subroutine to another and in that call a hard-coded value of -100. was passed to a function that expected a double precision value.

Here are the code snippets.

Notice -100. is hard coded in the function call (I know this is bad)

IF(S.EQ.0. .OR. H.EQ.0.)RETURN
CALL DPRT(R,-100.,PMIN)
X(2)=-10.

DPRT expects a double precision argument!

SUBROUTINE DPRT(A,TT,PP)
!DEC$ATTRIBUTES DLLEXPORT :: DPRT
IMPLICIT NONE
REAL(8) t, p, A(58), PP,TT

Upon debugging I see the value of TT is garbage inside the DPRT function.

I went in and found the /fpconstant compiler switch "Extend Precision of Single-Precision Constants" hoping that this would solve the problem. But it did not work.

I'm guessing the compiler switch is not meant to fix the error I found, but can someone explain why?

I was hoping to find a compiler switch because I don't know of a good way to search the code for all the instances where a hard-coded constant like this may have been used. Currently I change the -100. to -100.0D0 to solve the problem.

Thanks

Jim

[TimP]

real-size:64 may be an option on your way to completing the conversion. While you were about it, you might have considered naming the kind for ease of conversion:
integer, parameter :: wp=selected_real_kind(12)
real(wp) .....
.....
call(....,-100_wp,...)

[Steven_L_Intel1]

The purpose of the /fpconstant switch is to handle a situation such as the following:

DOUBLE PRECISION PI
PI = 3.1415926535897

The constant is in the form of a single-precision real, but the programmer expected all the digits to be used. VAX Fortran would keep the constant in the highest precision internally and then convert down on the assignment, but this is not legal as of Fortran 90, so the constant is single precision. If you use /fpconstant, then the value is kept in higher precision just like VAX Fortran would do. It doesn't help you here.

As suggested, you could see if /real_size:64 helps, but I think it would be better for you to fix the arguments. At least the compiler is helping you by pointing out where it is needed.