forums.silverfrost.com

[mecej4]

The Zip file https://www.dropbox.com/scl/fi/h5dv3i9a4rr5lvz15g4fs/xfzero.zip?rlkey=ot6eqa8xfth5j7ovokdcypmyo&dl=0 contains two source files. The driver, fztest.f90, is just

[JohnCampbell]

In this example, would you need to provide an interface for fzero ?

I expect there could be problems with using an intrinsic, where the kind being expected is not identified ?

Is 32-bit FTN95 correct when working in this case ?

Providing an external function of known kind would work, but that does not answer the problem with this usage.

I tried:
1) Use interface
interface
subroutine fzero (f,B,C,R,Re,Ae,Iflag)
real Ae, B, C, R, Re
integer Iflag
real, external :: f
end subroutine fzero
end interface

This did not solve the problem ?

2) Indicate real*4 TAN
real, intrinsic :: tan
I tried to define the real kind.
This compiled with no reported error but failed at link ?

3) Remove using intrinsizc in fzero call
real, external :: tanz

This worked, which is what I used before F90 intrinsic were available and I needed real*8 tan when switching between CDC mainframe and Pr1me Mini.

I still do not understand how the compiler knows which Kind TAN to use, although FTN95 /32 appeared to solve the problem.

[PaulLaidler]

At first sight it looks like TAN$ is simply missing from the export table for clearwin64.dll. For double precsision (and FTN95) you must pass DTAN but again DTAN$ is missing. (I realise that it's TAN@ that is reported as missing but SLINK64 handles the @.)

I will make a note to investigate further.

[PaulLaidler]

This failure has now been fixed for the next release of clearwin64.dll.

For double precision, FTN95 requires that you use DTAN as the intrinsic.