(j3.2006) interesting CONTIGUOUS pointer example

[Bill Long]

On 3/24/13 7:53 PM, Malcolm Cohen wrote:
>>> The program should certainly be invalid.
>>
>> The program is invalid.  Clause 16.5.2.6 states
>>
>>       While two pointers are name associated,
>>       storage associated, or inheritance associated,
>>       if the association status of one pointer
>>       changes, the association status of the other
>>       changes accordingly.
>>
>> The dummy argument pdmy is name associated with
>> ptr1 during the execution of fun1.  When pdmy
>> becomes associated with trg(2:8:2), ptr1 also
>> becomes associated with trg(2:8:2), which is
>> prohibited by paragraph one of Clause 5.3.7.
>
> I agree with Robert.  However, I wonder if we really intended to allow this

I think we agree on what is supposed to happen. At least some have 
implemented this such that the actual and dummy are using the same dope 
vector, so changes to one are automatically made to the other.  My 
comment is that the wording in 16.5.2.6 is confusing.  Para1 says that 
for argument association the effects on association status "are 
specified in 16.5.5".   One might reasonably jump to 16.5.5 for the 
answer.  But that is only part of the answer  -  there is more in para 2 
of 16.5.2.6.  It seems this could be more clearly worded.

At an even more nit-picky level, we really don't say that a change in 
association status  to associated requires that the targets of the two 
pointers be the same.  Having the dummy become associated with a target 
in the subprogram, and the corresponding actual argument become 
associated with an initialization target that was specified for it wold 
seem to meet the letter of the wording.   Association status, by itself, 
is only a designation of one of three states (associated, disassociated, 
or undefined).  Again, I'm sure we all agree what was intended, but a 
more clear statement would be helpful.

> unsafe argument association?  We do not, for example, allow variation in
> polymorphic pointer argument association, so I would have expected us to require
> that if the dummy and actual arguments are both pointers, they either both have
> to have the CONTIGUOUS attribute or both do not have the CONTIGUOUS attribute.
> C1241 achieves the dummy CONTIGUOUS => actual CONTIGUOUS part, but not the
> converse.  I think this is a drafting error...

C1241 is for the direction that is detectable at compile time.  The 
other direction is not.  It is arguable that the current text was 
intentional, even though it is accident prone.  If you choose to declare 
a pointer CONTIGUOUS to benefit from better optimization, then you could 
end up prohibited from calling a substantial number of existing 
subroutines with this pointer as an argument if we change this rule. 
Even if the routine you are calling does nothing to result in a change 
from contiguous target to noncontiguous target for the corresponding 
dummy pointer .  The routine might be written to accommodate either 
case, or was written before CONTIGUOUS existed. Or even was written 
before allocatable dummy argument were allowed, which prompted the use 
of pointer arguments.  The suggested change could have a log of side 
effects.

Cheers,
Bill


>
>>> Would it help to explicitly say that a dummy data pointer that
>>> corresponds to an actual data pointer with the CONTIGUOUS attribute
>>> shall not be associated with a non-contiguous target when the subprogram
>>> completes?
>
> No.  It shall not be associated with a non-contiguous target at any time, and
> this is already required in 5.3.7.
>
> Cheers,
>

-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101