• Curious problem with an interface block (conversion of old code)

    From Arjen Markus@21:1/5 to All on Wed Oct 12 04:27:33 2022
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John@21:1/5 to arjen.m...@gmail.com on Wed Oct 12 05:18:13 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Arjen Markus@21:1/5 to John on Wed Oct 12 05:44:47 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Arjen Markus@21:1/5 to Arjen Markus on Wed Oct 12 05:57:03 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John@21:1/5 to All on Wed Oct 12 05:30:59 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From JRR@21:1/5 to All on Wed Oct 12 16:19:19 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John@21:1/5 to arjen.m...@gmail.com on Wed Oct 12 07:20:37 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From FortranFan@21:1/5 to John on Wed Oct 12 07:47:36 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to arjen.m...@gmail.com on Wed Oct 12 08:19:41 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Peter Klausler US@21:1/5 to All on Wed Oct 12 10:45:29 2022
    $ 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 )
    ^^^^

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to arjen.m...@gmail.com on Wed Oct 12 16:34:30 2022
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Arjen Markus@21:1/5 to Robin Vowels on Thu Oct 13 00:10:40 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)