Re: question about elemental subroutines

[Paul dot Thomas at jet dot uk (Paul Thomas)]

Brooks (and Richard),

Thank you for taking the time to contribute to this thread.  I want to get this right, so that it does not come back to haunt me later.

> ..snip.. I would say that all that is required is to ensure that

> call nonassign (x(2:3), (x(1:2)))

> returns the same as

> call nonassign (x(3:2:-1), (x(2:1:-1)))

> where the actual IN argument is enclosed in parentheses so as to make it an 
> expression, not a variable.
I had thought that to be guaranteed but it isn't and doesn't.

> I should correct myself, however, on one point: This has nothing to do 
> with whether the non-expression argument is OUT or INOUT. Thus, the patch
> itself appears correct, and I retract my disagreement with it. However,
> it does seem odd to me that the patch appears to resolve this by making
> a temporary for the INOUT variable rather than the IN variable, as that
> requires two copies rather than one.

To fix the problem with assignments, I chose to use a temporary
for the OUT parameter in order, to make use of the internal_unpack
to reconstitute the temporary into an array section.  I did not do
it to IN parameters because internal_pack produces its own temporary,
if necessary, thus necessitating code to check whether an allocation
is required outside of internal_pack.  Once I got to thinking about
INOUT parameters, I found that, whilst only one temporary is required
in principle, the original variable had to be packed and then copied
to the temporary that is passed to the subroutine.  Thus, array
sections produce two temporaries.  I intend to deal with this when I
fix the transfer intrinsic by writing a version of pack that allocates
an amount of memory that is given as a parameter and then unconditionally
packs the array to that memory, stopping if there is no more space.

Like Dominique, I missed the reference to 12.4.1.6, in the paragraph
that starts with MVBITS.
  
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 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.

Thanks again

Paul