Fortran - Aliased arguments (was: Very Basic question from Newbie)

Author

Aliased arguments (was: Very Basic question from Newbie)

James Giles

2005-05-14, 4:05 pm

David Flower wrote:
....
> Ignoring the (deliberate) mixed equivalencing, the same effect
> could be achieved by:
> REAL Y
> CALL SUB ( Y, Y )
> .
> .
> .
> SUBROUTINE SUB ( X, I )
> REAL X
> INTEGER I

Well, as you mentioned yourself, the type coersion implicit
in the argument association is illegal. But, suppose the
subroutine were written:

SUBROUTINE SUB (A, B)
REAL A, B

Now your call is legal, but *only* if neither A nor B is
defined within SUB or any of the procedures SUB calls.
Fortran's rules for argument association are carefully
designed to allow compilers with the choice of either
call-by-reference or call-by-value/result (the latter is
sometimes called copy-in/copy-out because that's what
happens). A given modern compiler often does *both*
with the same procedure, even though the implementation
may ostensively be call-by-reference.

Suppose, in the above SUB, that A is very heavily used
within the procedure and B is seldom used. The compiler
may decide to make a local copy of A and keep it in a
register for the duration. Variable A now behaves exactly
as if it was passed as value/result. On the other hand, if
the compiler just uses B from memory all the time, it may
behave throughout with call-by-reference semantics. This
is a permitted optimization strategy in the code.

In the above, any reference to B within SUB will *not*
reflect any changes made to A. And any assignments to
B will *not* alter the value of A. That, presumably, is
not what you intend.

On the other hand, the compiler may *sometimes* spill A
to memory (when it needs the register space) and reload it
later - now A and B behave neither independently, as I
described before, nor as consistently associated as you
might expect in a pure call-by-reference implementation.

Given the difficulties, the standard prohibits the actual
arguments associated with A and B from being aliased
whenever the procedure alters either's value. Note that
this is essentially the same rule that the new C standard
has when the dummy arguments have the restrict attribute.
It really is an important rule for optimization.

(This ignores the original question, which is why I changed
the subject line. Given that the semantics of EQUIVALENCE
would have to be limited in special ways to provide for
what you request, and the fact that EQUIVALENCE is mostly
considered undesirable by many on the committee, it's not
really likely that new capabilities will be added in that way.
Too much committee work for what many would consider
as waste of time.)

--
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

David Frank

2005-05-14, 4:05 pm

James G,
below hidden arg aliasing might be useful, e.g. decoding database records
where different data
is offset differently and with different data types from input record
provided to using subroutine?

! ---------------
module test_1
type :: txn
logical :: iflag
union
map ; real(8) :: x(2) ; end map
map ; integer :: n(4) ; end map
end union
end type txn
end module test_1
! -----------
program test
use test_1
type (txn) :: xn

xn%iflag = .false. ; xn%x = [1.0,2.0] ! provide one type of record data
call sub1(xn)
xn%iflag = .true. ; xn%n = [1,2,3,4] ! provide 2nd type of record data
call sub1(xn)
end program
! -----------------
subroutine sub1(a)
use test_1
type (txn) :: a

if (a%iflag) then
write (*,*) a%n ! outputs 1.0000000000000 2. 0000000000000000
else
write (*,*) a%x ! outputs 1 2 3 4
end if
end subroutine

James Giles

2005-05-14, 4:05 pm

David Frank wrote:
> James G,
> below hidden arg aliasing might be useful, e.g. decoding database
> records where different data
> is offset differently and with different data types from input
> record provided to using subroutine?

I guess I don't see your point since your example contains no
hidden aliasing. Hidden aliasing is where two different
names in the same context refer to the same data, but the
compiler can't see that the aliasing is present. Your procedure
doesn't even take two arguments - how could there be hidden
aliasing?

What you've got there is an extension that (rather clumsily) permits
variant derived types. That's a different animal altogether. The
type safety of your variant types is perhaps questionable. But the
fact that some names are aliased to others is explicitly visible to
both the user and the compiler by viewing the type definition.

--
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

Sponsored Links