Re: Program Fails When Parameter Fixed Constants are Changed (F77) ??

1) Richard wrote:
In the code that calls ZBRENT, what does the compiler know about the
actual argument. You have declared it to be external, but that's all. You
have not done anything to specify that it is a function instead of a
subroutine, so the implicit typing doesn't kick in. Looking at the
function ZBRENT itself is *NOT* the question here. The question is what
the compiler knows solely within the calling procedure. I don't see
anything there (admittedly, I might have overlooked it) to say that
ZBRENT is a function as opposed to a subroutine.

Based on my little knowledge of Fortran, External identifies the name
as subroutine OR function. Correct ??
I don't know how to tell the compiler DCPVAL is a fun and not a sub.
I thought how the name is referenced in the code tells the compiler.
Apparently this no longer the case and one has to specify which
external procedure is a sub and which is a fun. But how ?
(I thought also that most compilers assume undefined names (typos for
example) in a program unit to be defined externally, and display the
error message "external ref. not defined" or something to that
effect.)

2) Richard wrote:
Just because your f77 compiler did not bitch about the code, and
perhaps ran it as intended, that most definitely does not mean it
was valid f77. It just means that the compiler did not notice the error
and that the error didn't happen to cause the program to fail with
that particular compiler. That is not the same thing as being valid f77.

OK. My F77 program in question (a research tool, which I'm trying to
upgrade some aspects of it to F90 using the dynamic arrays feature you
and others have recommended earlier) compiles successfully (earlier
with MS Fortran v5.1 then with IBM Fortran, and recently with g95).
The F77 program runs as desired producing the correct results for all
the input scenarios I've tested for the last few years.
I'm not claiming it to be either elegant or efficient by your
standard, or even bug-free, but it works perfectly as intended and on
different m/cs.
What else should I be concerned with to designate it as *reliable* and
*valid f77* ??

3) Ken wrote:
Just to clarify for monir...it is DCPVAL which is
declared EXTERNAL but not given a type in the caller.
DCPVAL in the caller corresponds to func in ZBRENT,
and it is DCPVAL that needs to be declared (presumably
REAL) in the caller.

I take it to mean in sub DCpZeros. Correct ?? Isn't that implicit ?
Anyway just to make sure I interpreted your suggestion correctly, I
declared the name of the External as real throughout, one declaration
at a time.

4) First:
Declared DCPVAL as real in Sub DCpZeros. Same g95 compiler error
message:
cpyzero(2,1) = ZBRENT(DCPVAL,theta(i,j+1,k), theta(i,j+1,k
+1),tol)
*Error: Type/rank of actual function at (DCPVAL) does not match the
dummy function*
with ref to the 1st arg (i.e.; DCPVAL) in the 1st use of ZBRENT.

5) Second:
Declared also func as real in Fun ZBRENT.
The above compiler error DISAPPEARED!!!!
A bit surprising, since according to Richard and others: "Valid F77
code is also valid F90 code."

In any event, now I'm getting:
C:\...\EULER-2D-mesh3-F90>g95 -o PRSCAV8d-F90-c PRSCAV8d-F90-c.for
C:\...\LOCALS~1\Temp/cce8baaa.o:PRSCAV8d-F90-c.for:(.text+0x8239):
undefined reference to `dcpval_'
C:\...\LOCALS~1\Temp/cce8baaa.o:PRSCAV8d-F90-c.for:(.text+0x8431):
more undefined references to `dcpval_' follow

Perhaps I should re-visit Richard's suggestion (Item 1 above).
Does the above refer somehow to where "dcpval" is undefined ??
Are +0x8239, +0x8431, etc. references to the list file ??

6) Here's the latest attempt (F90):

c *************************************
Subroutine DCpZeros()
c *************************************
use DIM
use ABSCISAE
use VVALUES
use DCP
use LST2
use PARM
use maxDIMEN
use CRT
.......................
External DCPVAL
real DCPVAL
.......................
cpyzero(2,1) = ZBRENT(DCPVAL,theta(i,j+1,k),theta(i,j+1,k+1),tol)
.......................
Return
End Subroutine DCpZeros

c *************************************
FUNCTION ZBRENT(func, x1, x2, tol)
c *************************************
External func
real func
........myCode21.....
fa = func(a)
fb = func(b)
.........myCode22.....
ZBRENT = b
Return
End Function Zbrent

! ****************************
real FUNCTION dcpval(X)
! ****************************
use maxDIMEN
use CRT
use Y2AA
real :: x, y, d1, dn
.........................
CALL DERIVPOL(Xcrt, Ycrt, 3, Xcrt(1), d1)
.........................
dcpval = y
Return
End Function dcpval


Kind regards.
Monir
.

Relevant Pages

  • Re: Program Fails When Parameter Fixed Constants are Changed (F77) ??
    ... I don't know how to tell the compiler DCPVAL is a fun and not a sub. ... references, except as l-values, look like functions references. ... That is not the same thing as being valid f77. ... declared the name of the External as real throughout, one declaration ...
    (comp.lang.fortran)
  • Re: Question about multiple files
    ... No. extern just means: The actual definition is somewhere else. ... the compiler can differentiate between declaration and definition just ... > declaration it finds and in this way can I write code expecting it to be ... When the compiler reaches the line foo(); ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Question about multiple files
    ... but say I declare with extern. ... > the compiler can differentiate between declaration and definition just ... >> declaration it finds and in this way can I write code expecting it to be ... > When the compiler reaches the line foo(); ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Cpp Considered Harmful
    ... >> programming language, the compiler, the IDE, the libraries, etc. ... source file, the implementation shall locate the declaration, (and ... to name one of the defining source files on the command line that initiates ... The counterpart to this in Java is accomplished using the following: ...
    (comp.lang.cpp)
  • Re: Internal compiler error C1001 after SP6 installation
    ... Declaring variables like ... fixed it is not particularly productive to worry about why the compiler is choking. ... >The stdafx.h contains a class declaration at line 30. ... the optimizations should caused these error. ...
    (microsoft.public.vc.mfc)