mckenney@acf2.NYU.EDU (Alan Michael McKenney) (04/06/89)
A while back, I posted a question about passing a COMPLEX value
when the subroutine expects a REAL value, saying I would summarize
what I got back. (I can't excerpt the original posting, since I have
lost it) The best answer I got was:
# From: Kurt Hirchert <hirchert@uxe.cso.uiuc.edu>
# Subject: FORTRAN 77 COMPLEX vs. REAL
#
# The short answer:
#
# 1. If you EQUIVALENCE a REAL array to a COMPLEX variable, it is
# required to "work" as you expect. This also applies to other
# forms of storage association (e.g. COMMON).
#
# 2. You are _not_ allowed to associate a COMPLEX argument with a REAL
# dummy argument. Thus, if a vendor can do something useful where
# (1) works but this doesn't, he is free to do so. I consider this
# relatively unlikely, but possible.
#
# Under what circumstances might a processor meet (1) but not (2)?
# Consider vector processors like the Cyber 205 and ETA machines that
# work most efficiently on contiguous arrays. The usual arrangement
# for complex data, with the real and imaginary parts interleaved,
# seriously impacts performance on such machines. To partially
# alleviate this problem, a compiler for such hardware might recognize
# COMPLEX arrays that are not storage associated and allocate them as
# two separate arrays, one for the real part and one for the imaginary
# part. When calling subroutines, it could pass the address of the
# real array and the address of the imaginary array separately. If
# your subroutine were only expecting a real argument, it would be
# prepare for only one of the two addresses passed and argument
# association would be fouled up.
#
# In other words, I recommend that you _not_ depend on being able to
# pass a COMPLEX argument to a REAL dummy, but you should feel free to
# EQUIVALENCE a REAL variable or array to the COMPLEX array and pass
# that instead.
#
# Kurt W. Hirchert hirchert@ncsa.uiuc.edu
# National Center for Supercomputing Applications
#
His caution applies to other type mismatches. The implementations
I know of pass CHARACTER variables as two arguments: a pointer, and
a length. If the length immediately follows the pointer in the
argument list (at machine level), then passing a CHARACTER variable
when the subroutine expects, say, an INTEGER will probably cause a
crash. I have heard mention of machines where pointers have differing
forms depending on the type they are pointing at, that would also
cause trouble.
I had foolishly concentrated on the representation in memory, but
the manner of passing arguments is a more serious problem. I even knew
about how CHARACTER variables are passed! Obviously, my brain wasn't
in gear. If nothing else, I should have noticed the relevant sentance
in the standard (sec. 15.6.2.3, also see 15.5.2.2):
"The actual arguments in a subroutine reference must agree in order,
number, and type with the corresponding dummy arguments in the
dummy argument list of the referenced subroutine."
Alan McKenney E-mail: mckenney@acf8.nyu.edu (INTERNET)
Courant Institute,NYU ...!cmcl2!acf8!mckenney (UUCP)
--
Alan McKenney E-mail: mckenney@acf8.nyu.edu (INTERNET)
Courant Institute,NYU ...!uunet!cmcl2!acf8!mckenney (UUCP)