The standard doesn't need to say anything more about this, but
processors might wish to remark that FROM has the TARGET attribute and
TO doesn't, thereby leading to potential problems.
Malcolm Cohen wrote:
> No, this is not safe, in fact the program is not even valid.
>
> The situation is clearly and explicitly described in MOVE_ALLOC:
> “If TO does not have the TARGET attribute, the pointer association
> status of any pointer associated with FROM on entry becomes undefined.”
> this means that your pointer “k” is undefined, and therefore you are
> not permitted to reference it.
>
> In practice, this may appear to “work” today but might not work
> tomorrow (even without recompilation). More chance of going wrong
> with higher levels of optimisation, but some things will almost
> certainly produce obvious garbage regardless, such as overlapping
> assignments between j and k (especially skewed overlapping assignments).
>
> Cheers,
>
> *From:* Tom Clune <mailto:[log in to unmask]>
> *Sent:* Tuesday, February 18, 2014 6:45 AM
> *To:* [log in to unmask]
> <mailto:[log in to unmask]>
> *Subject:* [COMP-FORTRAN-90] TARGET and move_alloc() ?
>
> Consider the short program shown below. After assigning the pointer
> "k" to the allocated integer array "i", move_alloc is used to transfer
> the data to "j". It is clear that "i" must have the TARGET attribute,
> but I'm less certain whether the same is true of "j". The code
> below "works" with all the compilers I have access to, but I cannot
> help but feel that I've created the possibility that the compiler is
> unaware of the aliasing between "j" and "k". Is this safe?
>
> integer, target, allocatable :: i(:)
> integer, allocatable :: j(:)
> integer, pointer :: k(:)
>
> i = [1,2,3,4]
> k => i
> print*,'before: ', k
> call move_alloc(from=i, to=j)
> print*,'after: ', k
>
> end
>
>
>
>
>
|