what's wrong with this program,or with gfortran?
lin...@sohu.com
test it with gfortran please.
thanks.
=====================
program test_callee_caller
implicit none
print *, test_c_c(4.0,y)
print *, test_c_c(3.1415926/2.0,z)
contains
real function z(x)
implicit none
real ::x
z=sin(x)
end function
real function y(x)
implicit none
real :: x
y=sqrt(x)
end function
real function test_c_c(a,func)
implicit none
interface
real function func(x)
implicit none
real x
end function func
end interface
real :: a
test_c_c=func(a)
end function
end program test_callee_caller
lin...@sohu.com
why?????
Richard Maine
> Internal procedure 'y'and 'z' are not allowed as an actual argument.
>
> why?????
Because the standard says they aren't. As to why the standard says that,
I suggest goggling for previous discussions of the question. There are
complications - ones that are probably solvable, but in any case the
matter is not as entirely trivial as a first glance might make it seem.
It has been asked often enough. There have been formal proposals to
change that in the standard. None of them have yet made it into the
actual standard. I've lost track of whether or not that is in the latest
f2008 draft or not.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
Dan Nagle
Richard Maine wrote:
> I've lost track of whether or not that is in the latest
> f2008 draft or not.
Yes, please see work item J3-013, completed by paper 05-202r1.
--
Dan Nagle
Purple Sage Computing Solutions, Inc.
Steve Lionel
> <linu...@sohu.com> wrote:
> > Internal procedure 'y'and 'z' are not allowed as an actual argument.
>
> > why?????
>
> Because the standard says they aren't.
Right. This is, however, an extension supported by Intel Fortran.
The implementation is indeed not trivial and has to be different on
each of the three operating systems we support, but it can be done.
Note that the standard does say:
NOTE 12.16
This standard does not allow internal procedures to be used as actual
arguments, in part to simplify
the problem of ensuring that internal procedures with recursive hosts
access entities from the
correct instance (12.5.2.3) of the host. If, as an extension, a
processor allows internal procedures to
be used as actual arguments, the correct instance in this case is the
instance in which the procedure
is supplied as an actual argument, even if the corresponding dummy
argument is eventually invoked
from a different instance.
It is a very handy extension to have at times...
Steve
Carlie J. Coats
Indeed, as I was asking for help about, a week ago ("OpenMP
thread-safety programming problem"). I wound up doing over
a thousand lines of in-lining *by hand* for the multiple calls
to two rather messy subroutines in order to get around this
restriction, while creating a thead-safe implementation of
an aerosol-thermodynamics solver.
FWIW.
-- Carlie J. Coats, Jr.
Baron Advanced Meteorological Systems, LLC.
glen herrmannsfeldt
(snip regarding internal procedures as actual arguments)
> Right. This is, however, an extension supported by Intel Fortran.
> The implementation is indeed not trivial and has to be different on
> each of the three operating systems we support, but it can be done.
> Note that the standard does say:
> NOTE 12.16
> This standard does not allow internal procedures to be used as
> actual arguments, in part to simplify the problem of ensuring
> that internal procedures with recursive hosts access entities
> from the correct instance (12.5.2.3) of the host.
> If, as an extension, a processor allows internal procedures to
> be used as actual arguments, the correct instance in this case
> is the instance in which the procedure is supplied as an actual
> argument, even if the corresponding dummy argument is eventually
> invoked from a different instance.
Does it have to be invoked from some instance of the containing
procedure? Traditionally, procedure names as actual arguments
were represented by the address of the procedure. In this case,
they have to also include a reference to the instance, mostly
the local variables, of the procedure.
In the OP's case, the routine the actual argument was passed
into was also an internal procedure of the same external
procedure. Even without recursion, it gets more complicated
if you pass such to another external procedure.
From the OP:
Can test_c_c be an external procedure?
In this case, x and y don't reference any variables
from the containing procedure, but they are allowed to do that.
That requires the appropriate reference to the instance of
the containing procedure.
-- glen
James Giles
...
> Note that the standard does say:
>
> NOTE 12.16
> This standard does not allow internal procedures to be used as
> actual arguments, in part to simplify the problem of ensuring that
> internal procedures with recursive hosts access entities from the
> correct instance (12.5.2.3) of the host. If, as an extension, a
> processor allows internal procedures to be used as actual
> arguments, the correct instance in this case is the instance in
> which the procedure is supplied as an actual argument, even
> if the corresponding dummy argument is eventually invoked
> from a different instance.
The above requirement is in a note and not normative - but any other
rule would be a real mess.
It is this note (or the problem it addresses) that has always
convinced me that Fortran has the right rule in place already.
You shouldn't be allowed to pass an internal procedure
as an actual argument.
OK, you can relax the rule for the most common cases. In fact,
if you want the rule to be really arcane you can say that if an
internal procedure is passed as an actual argument, all host
associated variables used by that internal procedure must have
the SAVE attribute OR the host procedure must not be recursive
or reentrant. This makes meeting the above requirement in the
standard fairly easy for implementations. Given that most
host procedures in Fortran are not recursive and not (presently)
reentrant, this should allow most of the useful cases.
(I realize that Fortran doesn't yet have reentrancy, but this
is in anticipation of that possibility.)
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
Steve Lionel
>
> Does it have to be invoked from some instance of the containing
> procedure? Traditionally, procedure names as actual arguments
> were represented by the address of the procedure. In this case,
> they have to also include a reference to the instance, mostly
> the local variables, of the procedure.
It has to be invoked while the containing procedure is active. You
can't store it away somewhere and use it later. Once the containing
procedure exits, the passed procedure "thing" becomes undefined (as of
course do the local variables of the containing procedure.)
A common implementation in the past was to write onto the stack a mini-
routine that loads a register with the context (address of a frame
pointer, etc.) and then calls the actual procedure. Now that
operating systems (and processors) block execution of code from the
stack, due to viruses taking advantage of this, other places are
needed to store the code, but the concept is usually similar.
Steve
robert....@sun.com
> Steve Lionel wrote:
>
> ...
>
> > Note that the standard does say:
>
> > NOTE 12.16
> > This standard does not allow internal procedures to be used as
> > actual arguments, in part to simplify the problem of ensuring that
> > internal procedures with recursive hosts access entities from the
> > correct instance (12.5.2.3) of the host. If, as an extension, a
> > processor allows internal procedures to be used as actual
> > arguments, the correct instance in this case is the instance in
> > which the procedure is supplied as an actual argument, even
> > if the corresponding dummy argument is eventually invoked
> > from a different instance.
>
> The above requirement is in a note and not normative - but any other
> rule would be a real mess.
The normative part is the constraint that precedes
Note 12.16.
> It is this note (or the problem it addresses) that has always
> convinced me that Fortran has the right rule in place already.
> You shouldn't be allowed to pass an internal procedure
> as an actual argument.
>
> OK, you can relax the rule for the most common cases. In fact,
> if you want the rule to be really arcane you can say that if an
> internal procedure is passed as an actual argument, all host
> associated variables used by that internal procedure must have
> the SAVE attribute OR the host procedure must not be recursive
> or reentrant. This makes meeting the above requirement in the
> standard fairly easy for implementations. Given that most
> host procedures in Fortran are not recursive and not (presently)
> reentrant, this should allow most of the useful cases.
>
> (I realize that Fortran doesn't yet have reentrancy, but this
> is in anticipation of that possibility.)
J3 added pointers to internal procedures to the
Fortran 2008 draft. Sun and Cray's representatives
objected, but they were out-voted. Worse, the proposal
that was approved effectively requires an implementation
based on GCC trampolines. The security risks were
pointed out to the committee, but the committee
considered the risks unimportant.
One of the members of the committee proposed including a
million or so preallocated trampolines in static memory in
every program that might use pointers to internal
procedures as a way of avoiding the security risks.
Of course, in a multiprocessing environment, setting up
a trampoline will require locking.
Bob Corbett
James Giles
...
> J3 added pointers to internal procedures to the
Yikes! That is bad news. You worry from the point of view
of an implementor. But even if the implementation were
actually trivial, what of the poor ordinary user who has to
figure out what such things mean in order to use them
reliably? Does the committee ever even think of that?
robert....@sun.com
wrote:
> robert.corb...@sun.com wrote:
>
> ...
>
> > J3 added pointers to internal procedures to the
> > Fortran 2008 draft. [...]
>
> Yikes! That is bad news. You worry from the point of view
> of an implementor.
No. I am worried about the problems that users might
have. GCC trampolines are not hard to implement. Of
course, under Apple's OS, the users might have to go to
some trouble to make their executables run.
> But even if the implementation were
> actually trivial, what of the poor ordinary user who has to
> figure out what such things mean in order to use them
> reliably? Does the committee ever even think of that?
I believe the request for the feature came from one of
the non-vendor representatives, i.e., a user.
Bob Corbett
Steve Lionel
> No. I am worried about the problems that users might
> have. GCC trampolines are not hard to implement. Of
> course, under Apple's OS, the users might have to go to
> some trouble to make their executables run.
Intel Fortran supports passing internal procedures on Windows, Linux
and Mac OS. I don't know the specific implementation details but I do
know that different solutions had to be found on each OS. We don't
use GCC for anything in this regard, as far as I know.
Steve
lin...@sohu.com
this characteristic is definitely useful when calling some routines
such as some of IMSL.
robert....@sun.com
My understanding is that ifort uses the GCC-style of
trampolines, at least under Linux. That does not mean
that it uses GCC.
Bob Corbett