(j3.2006) does move_alloc violate restrictions in 12.5.2.13?

[Jim Xia]

> 
> 3. The technical issue 12.5.2.13 was intended to address was to allow 
> optimizations of operations involving dummy arguments on the assumption 
> that they are independent of each other and of any other entities being 
> used in those operations.  It does this by prohibiting those cases where 

> it would matter whether or not they are independent.  This issue isn't 
> important in the intrinsic functions because the implementor is expected 

> to have as much control over operation order as he/she needs to get the 
> semantics right in the intrinsics.
> 
> 4. I don't see any other technical issues in the points you have made. 
> Yes, one way of implementing MOVE_ALLOC might have an intermediate state 

> in which the allocation associated with the allocatable array associated 

> with FROM is also associated with the allocatable array associated with 
> TO, but since arbitrary user-written code is never given access to this 
> "bad" state, it doesn't really matter.   (This can be seen as analogous 
> to the fact that many implementations of pointer assignment may have 
> "bad" intermediate states in which the pointer's dope vector holds a 
> mixture of information from its new association and its old 
> association.  This doesn't matter because nothing is allowed to work on 
> the pointer while it is in that state.)


OK, seems most people are going for the "intrinsics are special" rule.


> Complaints that MOVE_ALLOC does something that cannot otherwise be 
programmed in 
> Fortran are somewhat missing the point of several of the intrinsic 
functions!


I think you missed my point.  I didn't complain about MOVE_ALLOC not able 
to be written in Fortran -- I know it'll never be.


> Yes, it is absolutely valid.  C specifies the semantics of what happens 
in that 
> case.  If you don't want that to be valid, or don't want those 
semantics, then 
> don't write FOO in C.


Surprising but good to know.  It never came cross my mind that using a C 
function in such a way in a Fortran program is absolutely valid.  Given 
the popularity of developing applications in mixed-languages, it would be 
interesting to know what rules we do have in guarding the integrity of 
applications.


Cheers,

Jim Xia

XL Fortran Compiler Test
IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7
Phone (905) 413-3444  Tie-line 313-3444
email: jimxia at ca.ibm.com
D2/YF7/8200 /MKM

http://www.ibm.com/software/awdtools/fortran/xlfortran
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://j3-fortran.org/pipermail/j3/attachments/20091029/d7f4c352/attachment.htm>