I ran into a curious problem with an interface block that I am using while converting an old library. This library contains specific implementations of standard functions like log and exp, the double-precision versions being called dexp and dlog. I have used this interface in a number of source files without any problem:

integer, parameter :: dp = kind(1.0d0)
interface
real(kind=dp) function dexp( x ) -- why is this a problem?
import :: dp
real(kind=dp), intent(in) :: x
end function dexp
end interface

But with one source file where I use that both gfortran and Intel Fortran claim that something is wrong, but I cannot determine what is wrong, quite probably it is staring me in the face, but I seem to be blind for it (mind you, I simply copied fragments from source files where this was no problem!).. My workaround is to comment it out.

Here is the source file:

! dgami.f90 --
! Original:
! july 1977 edition. w. fullerton, c3, los alamos scientific lab.
! ! evaluate the incomplete gamma function defined by
! ! gami = integral from t = 0 to x of exp(-t) * t**(a-1.0) .
! ! gami is evaluated for positive values of a and non-negative values
! of x. a slight deterioration of 2 or 3 digits accuracy will occur
! when gami is very large or very small, because logarithmic variables
! are used.
! function dgami (a, x)
use ieee_arithmetic

implicit none

integer, parameter :: dp = kind(1.0d0)

interface
real(kind=dp) function dgamit( a, x )
import :: dp
real(kind=dp), intent(in) :: a, x
end function dgamit

real(kind=dp) function dlngam( x )
import :: dp
real(kind=dp), intent(in) :: x
end function dlngam

real(kind=dp) function dexp( x )
import :: dp
real(kind=dp), intent(in) :: x
end function dexp

real(kind=dp) function dlog( x )
import :: dp
real(kind=dp), intent(in) :: x
end function dlog

!real(kind=dp) function dexp( x ) -- why is this a problem?
! import :: dp
! real(kind=dp), intent(in) :: x
!end function dexp
end interface

real(kind=dp) :: dgami
real(kind=dp) :: a, x

real(kind=dp) :: factor

if ( a <= 0.0d0 .or. x <= 0.0d0 ) then
dgami = ieee_value( x, ieee_quiet_nan )

else
dgami = 0.d0

if ( x /= 0.0d0 ) then
!
! the only error possible in the expression below is a fatal overflow.
factor = dexp (dlngam(a) + a*dlog(x))

dgami = factor * dgamit (a, x)
endif
endif

end function dgami

Can anyone point out what is wrong?

On Wednesday, October 12, 2022 at 7:27:36 AM UTC-4, arjen.m...@gmail.com wrote:
> I ran into a curious problem with an interface block that I am using while converting an old library. This library contains specific implementations of standard functions like log and exp, the double-precision versions being called dexp and dlog. I have used this interface in a number of source files without any problem:
>
> integer, parameter :: dp = kind(1.0d0)
> interface
> real(kind=dp) function dexp( x ) -- why is this a problem?
> import :: dp
> real(kind=dp), intent(in) :: x
> end function dexp
> end interface
>
> But with one source file where I use that both gfortran and Intel Fortran claim that something is wrong, but I cannot determine what is wrong, quite probably it is staring me in the face, but I seem to be blind for it (mind you, I simply copied fragments from source files where this was no problem!). My workaround is to comment it out.
>
> Here is the source file:
>
> ! dgami.f90 --
> ! Original:
> ! july 1977 edition. w. fullerton, c3, los alamos scientific lab.
> !
> ! evaluate the incomplete gamma function defined by
> !
> ! gami = integral from t = 0 to x of exp(-t) * t**(a-1.0) .
> !
> ! gami is evaluated for positive values of a and non-negative values
> ! of x. a slight deterioration of 2 or 3 digits accuracy will occur
> ! when gami is very large or very small, because logarithmic variables
> ! are used.
> !
> function dgami (a, x)
> use ieee_arithmetic
>
> implicit none
>
> integer, parameter :: dp = kind(1.0d0)
>
> interface
> real(kind=dp) function dgamit( a, x )
> import :: dp
> real(kind=dp), intent(in) :: a, x
> end function dgamit
>
> real(kind=dp) function dlngam( x )
> import :: dp
> real(kind=dp), intent(in) :: x
> end function dlngam
>
> real(kind=dp) function dexp( x )
> import :: dp
> real(kind=dp), intent(in) :: x
> end function dexp
>
> real(kind=dp) function dlog( x )
> import :: dp
> real(kind=dp), intent(in) :: x
> end function dlog
>
> !real(kind=dp) function dexp( x ) -- why is this a problem?
> ! import :: dp
> ! real(kind=dp), intent(in) :: x
> !end function dexp
> end interface
>
> real(kind=dp) :: dgami
> real(kind=dp) :: a, x
>
> real(kind=dp) :: factor
>
> if ( a <= 0.0d0 .or. x <= 0.0d0 ) then
> dgami = ieee_value( x, ieee_quiet_nan )
>
> else
> dgami = 0.d0
>
> if ( x /= 0.0d0 ) then
> !
> ! the only error possible in the expression below is a fatal overflow.
> factor = dexp (dlngam(a) + a*dlog(x))
>
> dgami = factor * dgamit (a, x)
> endif
> endif
>
> end function dgami
>
> Can anyone point out what is wrong?
the error messages make no sense, which is a red herring. You already have dexp defined above so it is a duplicate. It appears to confuse lthe compiler.

> the error messages make no sense, which is a red herring. You already have dexp defined above so it is a duplicate. It appears to confuse lthe compiler.

gfortran gives very confusing messages; ifort is technically correct, and nvfortran correctly complains about a duplicate but seems to be pointing to the arguments; more like it is trying to add the duplicate for a generic interface. But gfortran messages really went off the map.

(test1) urbanjs@venus:/tmp$ nvfortran xx.f90 -c
NVFORTRAN-S-0042-x is a duplicate dummy argument (xx.f90: 42)
NVFORTRAN-W-0119-Redundant specification for x (xx.f90: 44)
0 inform, 1 warnings, 1 severes, 0 fatal for dgami

On Wednesday, October 12, 2022 at 2:31:01 PM UTC+2, John wrote:
> > the error messages make no sense, which is a red herring. You already have dexp defined above so it is a duplicate. It appears to confuse lthe compiler.
> gfortran gives very confusing messages; ifort is technically correct, and nvfortran correctly complains about a duplicate but seems to be pointing to the arguments; more like it is trying to add the duplicate for a generic interface. But gfortran messages really went off the map.
>
>
> (test1) urbanjs:/tmp$ nvfortran xx.f90 -c
> NVFORTRAN-S-0042-x is a duplicate dummy argument (xx.f90: 42)
> NVFORTRAN-W-0119-Redundant specification for x (xx.f90: 44)
> 0 inform, 1 warnings, 1 severes, 0 fatal for dgami
Yes, I first tried to understand the gfortran messages and then tried Intel Fortran. While I understand it is a duplicate, I have used this same code, like I said, in other files without any complaints. Anyway, you confimr that I did not overlook anything obvious.

Regards,

Arjen

On Wednesday, October 12, 2022 at 2:45:11 PM UTC+2, Arjen Markus wrote:

> Yes, I first tried to understand the gfortran messages and then tried Intel Fortran. While I understand it is a duplicate, I have used this same code, like I said, in other files without any complaints. Anyway, you confimr that I did not overlook anything obvious.
>
> Regards,
>
> Arjen

I stared at the messages from gfortran for a long time and, temporarily blinded by them, was unable to grasp the meaning of the messages from Intel Fortran.

Regards,

Arjen

Am 12.10.22 um 14:57 schrieb Arjen Markus:
> On Wednesday, October 12, 2022 at 2:45:11 PM UTC+2, Arjen Markus wrote:
>
>> Yes, I first tried to understand the gfortran messages and then tried Intel Fortran. While I understand it is a duplicate, I have used this same code, like I said, in other files without any complaints. Anyway, you confimr that I did not overlook anything obvious.
>>
>> Regards,
>>
>> Arjen
>
> I stared at the messages from gfortran for a long time and, temporarily blinded by them, was unable to grasp the meaning of the messages from Intel Fortran.
>
> Regards,
>
> Arjen

Hi Arjen,
supposedly this is sort of a bug when gfortran/gcc flushes its error
messages. An error is triggered, I would guess, by the duplicate
interface for dexp, but parsing seems to continue. And then gfortran
stumbles over the following problem. In an interface like
real(kind=dp) function dexp (x)
import dp
....

the usage of dp comes before the import of dp. This confused several
compilers before, and some wouldn't allow that for some time. Here, the
parsing is somehow stopped because of the duplicate dexp interface,
and then the import is not correctly parsed, such that gfortran doesn't
understand the constant in real(kind=dp) and throws the error message:
46 | real(kind=dp) function dexp( x ) ! -- why is this a
problem?
| 1
Error: Parameter ‘dp’ at (1) has not been declared or is a variable,
which does not reduce to a constant expression
foo.f90:47:19:

47 | import :: dp
| 1
Error: IMPORT statement at (1) only permitted in an INTERFACE body

--
Juergen Reuter
Theoretical Particle Physics
Deutsches Elektronen-Synchrotron (DESY)
Hamburg, Germany

On Wednesday, October 12, 2022 at 8:57:05 AM UTC-4, arjen.m...@gmail.com wrote:
> On Wednesday, October 12, 2022 at 2:45:11 PM UTC+2, Arjen Markus wrote:
>
> > Yes, I first tried to understand the gfortran messages and then tried Intel Fortran. While I understand it is a duplicate, I have used this same code, like I said, in other files without any complaints. Anyway, you confimr that I did not overlook anything obvious.
> >
> > Regards,
> >
> > Arjen
> I stared at the messages from gfortran for a long time and, temporarily blinded by them, was unable to grasp the meaning of the messages from Intel Fortran.
>
> Regards,
>
> Arjen

Yes, same experience. The intel message was technically correct but vague, and the gfortran errors already had me looking for UNICODE characters, etc.. ; so saw it by eye first. I nice "duplicate interface for dexp" message would have been nice to have gotten from any of them.

43 | function dexp( x )
| 1
Error: Symbol ‘dexp’ at (1) already has an explicit interface

Using dp before the import does seem to be conflating it. Get a nice message if routine is instead

function dexp( x )
import :: dp
real(kind=dp), intent(in) :: x
real(kind=dp) :: dexp
end function dexp

On Wednesday, October 12, 2022 at 8:18:15 AM UTC-4, John wrote:

> On Wednesday, October 12, 2022 at 7:27:36 AM UTC-4, arjen.m...@gmail.com wrote:
> ..
> > Can anyone point out what is wrong?
> the error messages make no sense, which is a red herring. You already have dexp defined above so it is a duplicate. It appears to confuse lthe compiler.

One processor gave the following which seems informative enough:
--- begin message ---
C:\temp>ifort /c /standard-semantics dgami.f90
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.7.0 Build 20220726_000000
Copyright (C) 1985-2022 Intel Corporation. All rights reserved.

dgami.f90(42): error #6623: The procedure name of the INTERFACE block conflicts with a name in the encompassing scoping unit. [DEXP]
real(kind=dp) function dexp( x ) ! -- why is this a problem?
-----------------------^
compilation aborted for dgami.f90 (code 1)
--- end message ---

Dismayingly, OP didn't include in the original post the compiler messages received nor any details on the processors themselves.

On Wednesday, October 12, 2022 at 4:27:36 AM UTC-7, arjen.m...@gmail.com wrote:
> I ran into a curious problem with an interface block that I am using while
> converting an old library. This library contains specific implementations
> of standard functions like log and exp, the double-precision versions being
> called dexp and dlog.
> I have used this interface in a number of source files without any problem:
> integer, parameter :: dp = kind(1.0d0)
> interface
> real(kind=dp) function dexp( x ) -- why is this a problem?
> import :: dp
> real(kind=dp), intent(in) :: x
> end function dexp
> end interface

Using the names of existing Fortran library functions as names of your functions
does complicate things.

Traditionally, you put the name in an EXTERNAL statement when you use them.

In Fortran 66, there are intrinsic functions, which the compiler normally generates
code for inline, and external functions, which are calls to actual library functions.

That distinction was important, as the latter could be used as an actual argument
to another function or subroutine. (For example, an argument to a numerical
integration routine.)

While Fortran now calls all the functions in the standard intrinsic, the
distinction is still there. There is a list of functions that can be used as
an actual argument, and ones that can't.

DLOG and DEXP are listed in the ones that can, called "unrestricted".

It might be less confusing to rename them, such as MYDLOG and MYDEXP.

$ f18 -fsyntax-only t2.f90
../t2.f90:29:24: error: 'dexp' is already declared in this scoping unit
real(kind=dp) function dexp( x ) ! -- why is this a problem?
^^^^
../t2.f90:19:24: Previous declaration of 'dexp'
real(kind=dp) function dexp( x )
^^^^

On Wednesday, October 12, 2022 at 10:27:36 PM UTC+11, arjen.m...@gmail.com wrote:
> I ran into a curious problem with an interface block that I am using while converting an old library. This library contains specific implementations of standard functions like log and exp, the double-precision versions being called dexp and dlog. I have used this interface in a number of source files without any problem:
..
Why not just convert dexp, dlog to exp and log?

On Thursday, October 13, 2022 at 1:34:32 AM UTC+2, Robin Vowels wrote:
> On Wednesday, October 12, 2022 at 10:27:36 PM UTC+11, arjen wrote:
> > I ran into a curious problem with an interface block that I am using while converting an old library. This library contains specific implementations of standard functions like log and exp, the double-precision versions being called dexp and dlog. I have used this interface in a number of source files without any problem:
> .
> Why not just convert dexp, dlog to exp and log?

Thanks for all your reactions. I am trying to modernise the original code and the source I posted is a first step in that direction. The incomprehensibility of the messages I got with gfortran led to me being blinded for the actual problem.
The original library supplies its own, apparently portable, versions of the standard functions (single and double-precision). I will turn to the standard implementation later, but to ensure that the results are the same, I have left in the library's substitutes.

(It also provided me with an opportunity to post here: as I had not seen any posts for a surprisingly long time, I was beginning to wonder if we had a Google outage again, like a couple of years ago)
Regards,

Arjen