Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Doublure in a function definition

Robert_van_Amerongen
New Contributor III
955 Views

By having a typo I found something that I feel to be a compilererror.
I have isolated it in a small example program that is given below.

[bash]  MODULE de
!
  CONTAINS
!
    INTEGER FUNCTION m1(n)
      IMPLICIT none
      INTEGER,INTENT(in) :: n 
!      INTEGER :: m2             !  <<< problem line
      m1=m2(n)**2
      RETURN
    END FUNCTION m1
!
    INTEGER FUNCTION m2(n)
      IMPLICIT none
      INTEGER,INTENT(in) :: n
      m2=10*n
      RETURN
    END FUNCTION m2
!
  END MODULE de
!
!
  PROGRAM cep
  USE de
  IMPLICIT none
  write(*,*) m1(1)
  write(*,*) m1(2)
  END
!                                        "stand alone" external function m2
!  INTEGER FUNCTION m2(k)
!  IMPLICIT none
!  INTEGER,INTENT(in) :: k
!  m2=k
!  RETURN
!  END[/bash]


If the "problem" line is commented out, and the external function m2 is
commented out (lower part of the source), everything wents fine.
The main program calls m1 and m1, in turn, calls m2. And the answers are
100 and 400 as expected.

Now (here is the typo) if there is a definition of a function m2
in the module procedure m1, the compilers translates fine, but the linker
protests saying it could not find the symbol _M2 referenced in function _DE_mp_M1.

This looks strange to me: there now are two functions m2, one in the form of
an external function (not resolved) and another as a module procedure.
Should the compiler alarm on this definition doublure mentioned?

In the next step, if we add such a function (see lower part of the source),
and leaving the m2 definition in m1 intact, there is neither an error in compiling
nor an error in linking (no unresolved external reference). The program uses
the stand-alone external function m2 and returns the answers 1 and 4.

The external procedure seems to have preference above the module procedure.

0 Kudos
5 Replies
Steven_L_Intel1
Employee
955 Views
See the section "Up Periscope!" in Doctor Fortran in "Too Much of a Good Thing"
0 Kudos
mecej4
Honored Contributor III
955 Views
There is no compiler error here. Redeclaring m2 in function m1 (line-8) is the problem: the local declaration overrides the current explicit interface. Section 5.15 of Metcalfe, Reid and Cohen's book covers this issue in Section 5.15, "Scope of Names":

"Inner calls another internal procedure that is a function, f; it must not contain a type specification for that function."
0 Kudos
Robert_van_Amerongen
New Contributor III
955 Views
Steve and mecej4,

I am afraid that I am not the first one that made this mistake. Your remarks are clear. My suggestion that the compiler could be wrong is, in retrospect, a little silly as theissueis since Fortran 90 in the compiler. Sorry for that!

Thanks for your help.
Robert
0 Kudos
mecej4
Honored Contributor III
955 Views
Don't worry about it! The language has become so large that there is a lot more that the programmer has to keep track of.

Furthermore, in this instance, good habits (declaring types, possibly to the point of redundancy) did not go unpunished.

Perhaps the compiler could nudge the programmer, saying "redelaration of variable type hides earlier declaration" or something similar.
0 Kudos
Steven_L_Intel1
Employee
955 Views
It's tricky issuing diagnostics for perfectly legal Fortran code, though we do have some history of doing so for what we call "usage" issues. I'll add this to the list of things to think about.
0 Kudos
Reply