Use of intrinsic function TAN as arg fcn.causes linker error

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

program tfztest
   implicit none
   integer iflag
   real ae, b, c, re
   external fzero
   intrinsic tan
!
   print *,' Fzero Quick Check'
   re = 1.0E-6
   ae = 1.0E-6
   b = 3.0E0
   c = 3.2E0
   call fzero(tan,b,c,(b),re,ae,iflag)  ! (b) avoids aliasing
   if (iflag == 1) then
      print '(1x,A,2F12.4,i4)','Zero of tan at ',b,c,iflag
   else
      print *,' Failure in Fzero, iflag = ',iflag
   end if
end program tfztest 

and the second file, fzero.f90, is a standard root-finder for a function of one variable. The program works as expected with 32-bit FTN95. With /64, however, an error occurs at link time:

R:\SLATEC\tests\t34>ftn95 /64 f*.f90
...
slink64 f*.obj /file:fztest
[SLINK64 v3.10, Copyright (c) Silverfrost Ltd. 2015-2023]
Loading R:\SLATEC\TESTS\T34\FZERO.OBJ
Loading R:\SLATEC\TESTS\T34\FZTEST.OBJ
Creating executable file fztest.exe
The following symbols were not defined:

TAN@

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.

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.

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.