aliased intent(in out) arguments

Is the program below standard-conforming Fortran 95? A subroutine with
two intent(in out) arguments is called with both arguments being the
same variable. None of the Windows Fortran 95 compilers I tried
complain and simply print i=3 at the end.

This test program is motivated by a Usenet posting of Alex Martelli
with subject "Re: By value or by reference" in comp.lang.python at
http://groups.google.com/groups?q=f...ahoo.com&rnum=5
.

module foo
implicit none
contains
subroutine incboth(i,j)
integer, intent(in out) :: i,j
i = i + 1
j = j + 2
end subroutine incboth
end module foo

program xinc
use foo, only: incboth
implicit none
integer :: i
i = 0
call incboth(i,i) ! same variable for 2 intent(in out) arguments
print*,i
end program xinc

beliavsky@aol.com wrote:
> Is the program below standard-conforming Fortran 95? A subroutine with
> two intent(in out) arguments is called with both arguments being the
> same variable. None of the Windows Fortran 95 compilers I tried
> complain and simply print i=3 at the end.
...
> module foo
> implicit none
> contains
> subroutine incboth(i,j)
> integer, intent(in out) :: i,j
> i = i + 1
> j = j + 2
> end subroutine incboth
> end module foo
>
> program xinc
> use foo, only: incboth
> implicit none
> integer :: i
> i = 0
> call incboth(i,i) ! same variable for 2 intent(in out) arguments
> print*,i
> end program xinc

Certainly not conforming.  It's not something that conforming
implementations are required to detect or report.  But it can
be the source of mysterious and inconsistent behavior.  If your
program were more complicated and the compiler chose, say,
to keep one or other argument in a register for the duration of
the procedure call, the answer would not be predictable.
I've seen examples very much of this style where the answer
printed would be 1 or 2.

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

beliavsky@aol.com wrote:
> Is the program below standard-conforming Fortran 95? A subroutine with
> two intent(in out) arguments is called with both arguments being the
> same variable. None of the Windows Fortran 95 compilers I tried
> complain and simply print i=3 at the end.

No, it's not conforming!  The Fortran rule is simple:

"aliased dummy arguments cannot be changed, period".

Like all simple rules, there's some funny exceptions
involving pointers, but those are actually cases where
the compiler can see enough of the aliasing to always
be able to do the right thing.

Given the possibility of separate compilation, and nested
subroutine calls, etc., the rule isn't one that compilers
are forced to detect.  In general, it's not detectable
until run-time.

Dick Hendrickson

>
> This test program is motivated by a Usenet posting of Alex Martelli
> with subject "Re: By value or by reference" in comp.lang.python at
> http://groups.google.com/groups?q=f...ahoo.com&rnum=5
> .
>
> module foo
> implicit none
> contains
> subroutine incboth(i,j)
> integer, intent(in out) :: i,j
> i = i + 1
> j = j + 2
> end subroutine incboth
> end module foo
>
> program xinc
> use foo, only: incboth
> implicit none
> integer :: i
> i = 0
> call incboth(i,i) ! same variable for 2 intent(in out) arguments
> print*,i
> end program xinc

beliavsky@aol.com writes:

> Is the program below standard-conforming Fortran 95? A subroutine with
> two intent(in out) arguments is called with both arguments being the
> same variable.

No, the code is not standard-conforming.  But your description above
does not capture the reason. There is nothing inherently wrong with
having a subroutine with two intent(inout) dummy arguments both
having the same actual argument.

What is non-conforming is for the subroutine in question to then modify
the values of either of the dummy arguments.  Yes, the distinction
matters.  Just because an argument is declared intent(inout) doesn't
necessarily mean that it will get modified in any particular call.
For example, if the body of your subroutine were replaced by (for
a silly, but trivial example)

if (i /= j) then
i = i + 1
j = j + 2
end if

then the code would be standard-conforming.  And the subroutine
could even be called in some other place where i and j corresponded
to different actual arguments and thus got modified.

> None of the Windows Fortran 95 compilers I tried
> complain and simply print i=3 at the end.

As Giles noted, this isn't the kind of error that the standard requires
compilers to detect.  And many of them won't.  After all, there is
nothing wrong with the subroutine itself; that could be a valid
subroutine.  And there is nothing wrong with the main program itself;
it could be a valid main program.  The compiler has to look at both
of them together to deduce that there is an error.  And it actually
has to look at the body of the function to makek this deduction - the
interface isn't enough.

The INTENT attribute alone doesn't require an explicit interface,
so one could even write similar code without using a module, in such
a way that the compilation of the main program and subroutine could
be independent.

One could also easily write a case where array elements were being
passed and it depended on run-time input data whether the two array
elements were the same or not.  A compiler sure isn't going to be
able to diagnose that at compile time.  (Well, it might be able
to give you a warning about a potential problem... maybe).

Compilers *MAY* catch errors like this. Perhaps some do in some
cases. But it would be... optimistic... to expect compilers to be
able to catch all of them.  Exactly where the border is drawn
between those cases that the compiler will catch versus those
that it won't... I wouldn't have ventured to guess without
testing.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain