Re: question about elemental subroutines

[Brooks Moses <bmoses at stanford dot edu>]

Paul Thomas wrote:
> I must say that, upon reflexion, I am now worried that the patch is not
> at all correct as it stands. Indeed:
>
> "Specifically, as per 12.4.1.6 of the F95 standard, if two dummy arguments
> are associated with the same actual argument, then neither one of the
> dummy arguments can legally be modified within the subroutine. And, as per
> 12.7.2, this restriction applies to calls to elemental subroutines just as
> it would to any other subroutine."
>
> I took it that, in the case of an INTENT(IN) and INTENT(OUT), only the
> one is associated with the actual argument variable and that to modify it
> is therefore legal. If this is incorrect, then I will have to find a
> mechanism for dealing with the specific case of an assignment.

I believe that's incorrect, yes.

However, note that this is not a situation that the compiler is required 
to diagnose.  So, if your current code doesn't distinguish between 
noassign(x,x) and noassign(x,(x)) as far as creating temporaries, it at 
least does the right thing in the case of legal code, and doesn't do 
anything wrong with the illegal code.  That's about all one can really 
ask of it!

> I now think that the case of an INTENT(INOUT) and an INTENT(IN) should not
> produce a temporary and that, at very least, a warning should be issued if
> a dependency is found.

There's another complication here, though: the following is perfectly 
legal code, despite the argument dependency in the last call, and should 
(in my opinion) not cause a warning:

  elemental subroutine evil(x, y, q)
    integer, intent(inout) :: x
    integer, intent(in) :: y
    if (x > 0) x = -abs(y)
  end subroutine
  ...
  call evil(x(1:2), y(1:2))   ! this guarantees any(x(1:2)>0) is false
  call evil(x(1:2), x(2:3))   ! thus, this never modifies x

This is because what's illegal is not the subroutine call, but the code 
in the subroutine that modifies the doubly-associated variable -- and, 
here, it never gets called when the variable is doubly-associated.

My guess is that trying to distinguish the legal code from the illegal 
code in the general case is going to be essentially impossible, and so 
the "right" solution is simply to make sure that this works correctly in 
the legal cases (that is, where all but one of the associated dummy 
variables are associated with an expression rather than the actual 
variable), and let the illegal cases fall out however they fall.

If there are obvious warnings that can be supplied, supply them, but I 
suspect there won't be any, for reasons like this.

- Brooks