On 2005-11-23 09:55-0600 Geoffrey Furnish wrote:
> If this:
> > > subroutine chkargs
> > > integer i
> > > integer iargc
> > > external iargc, getarg
> > > character*20 arg
> > >
> > > write(*,*) 'Number arguments:', iargc()
> > > do i = 0,iargc()
> > > call getarg(i,arg)
> > > write(*,*) i, arg
> > > enddo
> > > return
> > > end
> were to coredump, now that would be more of a mystery.
The point of the first form (with a fixed limit of 5 rather than iargc()) is
to isolate the use of the two functions from each other (so you can comment
one out and vice versa to find which is giving the trouble). It turns out
(see below) that the g77 form of getarg returns blanks if you ask for an
argument outside the range. However, the question about such implementation
details is a distraction which I should have avoided in my original post by
using an example which always does the test with 5 arguments, and I think
that would be a good idea for Arjen to do that from now on as well.
> > Did you try dropping the external statement? It is not needed on Linux, and
> external declarations are required in Fortran.
> > in fact I don't see the point of it at all. Would you use external for any
> > other library function such as cos? It might cause an error on Cygwin
> No. cos and friends are "intrinsic" functions. Callling COS is /not/ like
> calling myfunc(). In fortran, the external keyword is here for this
> > (which is only visible for shared linking). I would also drop the type
> > statement for iargc since that is an intrinsic function. The Cygwin fortran
> > library may have the wrong intrinsic type for iargc implemented by mistake
> > so I suggest your best bet is to let it figure out the intrinsic type for
> > iargc itself rather than forcing a type that may not agree with the
> There is no "intrnsic type of iargc" in Fortran. It's not a part of Fortran,
> per se, just an external provision in the overall operating environment.
> > implementation. Again, I am going by the way an invocation
> > of the cos function should be handled.
> COS is intrinsic, Fortran "knows" about it because its specified in the
> Fortran standard.
> > What happens if you only have the iargc call and comment out the getchar
> > call and vice versa? I would like to know which fails or whether they
> > both fail.
> Me too. I bet iargc() by itself will be fine, and that the problem is the
> getarg call which is inducing a coredump through specification of out of
> range parameters.
Geoffrey, it turns out your external/intrinsic comments were not correct at
least for g77, but they were still useful because they lead me to dig deeper
in the g77 documentation to get the definitive answer. It turns out that
"info g77" says both iargc and getarg are intrinsic library routines
associated with g77. I quote the relevant sections of documentation later,
but there is a lot of general intrinsic information supplied by "info g77"
which I want to quote first to develop this response to your remarks in a
"Note that a name is not treated as that of an intrinsic if it is
specified in an `EXTERNAL' statement in the same program unit; if a
command-line option is used to disable the groups to which the
intrinsic belongs; or if the intrinsic is not named in an `INTRINSIC'
statement and a command-line option is used to hide the groups to which
the intrinsic belongs.
"So, it is recommended that any reference in a program unit to an
intrinsic procedure that is not a standard FORTRAN 77 intrinsic be
accompanied by an appropriate `INTRINSIC' statement in that program
unit. This sort of defensive programming makes it more likely that an
implementation will issue a diagnostic rather than generate incorrect
code for such a reference."
So, Arjen, you definitely should not use external. Furthermore, to force
the issue so that the compiler/linker will issue a diagnostic if there
is an implementation problem on Cygwin for these intrinsics you
should be using the
intrinsic iargc, getarc
statement for your test case. I just tested that statement for g77 on my
Linux system without problems. If the g77 compiler or associated linker on
Cygwin issues a diagnostic for that, then that would help us pin down what
"A given specific intrinsic belongs in one or more groups. Each group
is deleted, disabled, hidden, or enabled by default or a command-line
" The groups are:
[skipped the irrelevant ones to this discussion]
UNIX intrinsics (`IARGC', `EXIT', `ERF', and so on)."
Note, there is no mention on this list of a "standard Fortran 77" intrinsic
group (see cos documentation below). I think those standard intrinsics are
just on by default so that is why they are not mentioned in the above list
(and probably why it is not necessary to ever use intrinsic statements
with standard fortran intrinsics such as cos).
Finally here is the documentation for iargc, getarg, and cos (for comparison).
IArgC: `INTEGER(KIND=1)' function.
Intrinsic groups: `unix'.
Returns the number of command-line arguments.
This count does not include the specification of the program name
CALL GetArg(POS, VALUE)
POS: `INTEGER' not wider than the default kind; scalar; INTENT(IN).
VALUE: `CHARACTER'; scalar; INTENT(OUT).
Intrinsic groups: `unix'.
Sets VALUE to the POS-th command-line argument (or to all blanks if
there are fewer than VALUE command-line arguments); `CALL GETARG(0,
VALUE)' sets VALUE to the name of the program (on systems that support
*Note IArgC Intrinsic::, for information on how to get the number of
Cos: `REAL' or `COMPLEX' function, the exact type being that of
X: `REAL' or `COMPLEX'; scalar; INTENT(IN).
Intrinsic groups: (standard FORTRAN 77).
Returns the cosine of X, an angle measured in radians.
So these routines are all intrinsic functions for g77 with the important
distinction that iargc and getarg are in the unix intrinsic group while cos
is in the (standard FORTRAN 77) intrinsic group. It is because of this
distinction that the above
intrinsic iargc, getarg
line should always be in Arjen's test code. Furthermore, "info g77" also
says to enable the unix intrinsics use the -funix-intrinsics-enable g77
option, but it also says that option is the default. Nevertheless, Arjen, I
would always use -funix-intrinsics-enable to see if it makes any difference
on Cygwin. (You might get a special message about that intrinsic group not
being implemented on that platform which would be extremely helpful in its
I am looking forward to the results of your further experimentation, Arjen.
It is important when reporting your tests here to give your final source
code version in its entirety (including the above intrinsic statement) and
also give every exact command-line step that you used to compile the library
code with the -funix-intrinsics-enable option, link the shared library,
compile and link the main programme and execute the main programme (with 5
arguments so as not to distract discussion into getarg implementation
details on g77). Also, do exactly the same thing for your static case.
Finally, give full diagnostic messages. In short, give *all* the details
rather than just summarizing.
My prediction is you will get consistent results out of the shared and
static cases when you make the intrinsic and -funix-intrinsics-enable
changes. What I cannot predict, of course, is whether those consistent
results will be bad (perhaps with some specific useful diagnostics) or good
so I am very much looking forward to your next report to find out.
I also think it is important to try variations of your full source code with
either the iargc and getarg calls commented out to see whether both fail or
just one fails, and also replace iargc with cos(1.) to show what happens in
that case as a benchmark comparison for the standard fortran 77 intrinsic
group. Exact and comprehensive reporting of these variations as well as your
"full" test for both the shared and static cases will substantially improve
our chances of getting a quick fix out of the Cygwin group for this problem.
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project