(j3.2006) (SC22WG5.5062) [ukfortran] WG5 vote on draft TSon further coarray features

[Malcolm Cohen]

Steve Lionel wrote:
<<<
Events ? I?d like to see a note or some wording specifying what happens if more than one image is waiting for an event to be posted.
>>>
Cannot happen because we lobotomised events ? only the image on which the event variable resides is permitted to wait (EVENT WAIT prohibits event-variable from being coindexed).
<<<
7.4.1 (ATOMIC_ADD) ? change ?ATOM becomes defined with the value of ATOM + VALUE.? To ?ATOM becomes defined with the value of ATOM + INT(VALUE,ATOMIC_INT_KIND).?   Or is the intent that the normal mixed-mode arithmetic and assignment rules apply? This seems rather ugly to me, and ?becomes defined with the value? is not intrinsic assignment.
>>>
This is a change with little real effect, since if the mathematical result of adding ATOM and VALUE is not representable the program is not conforming in precisely the same way for ATOM + VALUE as it would be for ATOM + INT(VALUE,KIND(ATOM)) or indeed as it would be for INT(ATOM+VALUE,KIND(ATOM)).  Viz, the mathematical value is not representable.
In fact the only effect of the change is to make the case where VALUE is outside the range of KIND(ATOM) but ATOM+VALUE is not, e.g. ATOM==-HUGE(ATOM) and VALUE==HUGE(ATOM)+1_int64.  Since the corresponding assignment statement is valid this would be an unpleasant surprise to the user at runtime.
Given the usual hardware limitations on atomic ops, I would suggest constaining the kind of VALUE such that RANGE(VALUE)<=RANGE(ATOM).  Or even say that all values representable in the kind of VALUE shall be representable in the kind of ATOM.  Then the user will not get an unpleasant surprise at runtime but will be informed at compile time that he cannot atomically add a 128-bit value to a 32-bit atom.
Cheers,


-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20130806/8f5727eb/attachment-0001.html