(j3.2006) (SC22WG5.5221) [ukfortran] Ballot on draft DTS

[Malcolm Cohen]

>Please answer the following question "Is N2007 ready for forwarding to
>SC22 as the DTS?" in one of these ways.
>
>1) Yes.
>2) Yes, but I recommend the following changes.
>3) No, for the following reasons.

No, the technical content is not yet agreed (see many comments by Nick Maclaren 
and Reinhold Bader), and I think it is not correct.

In particular,
(1) the collectives CO MAX, CO MIN, CO REDUCE, CO SUM, should be split into two 
forms, one with RESULT, one without.  The one with RESULT should have SOURCE as 
INTENT(IN), the one without should have SOURCE as INTENT(INOUT).  RESULT must 
not be optional.  The SOURCE INTENT(IN) form should have no coarray restrictions 
on SOURCE.

(2) the semantics of EVENT are still unclear.  6.3p3 says
  "If the segment that precedes an EVENT POST statement is unordered with 
respect to the segment that precedes another EVENT POST statement for the same 
event variable, the order of execution of the EVENT POST statements is processor 
dependent."
but if they are in unordered segments, there is no order: processor-dependent or 
otherwise.

(3) I agree that EVENT WAIT UNTIL_COUNT=-127 makes no sense, but it seems far 
more likely to be a progamming error than a deliberate intention to specify 
UNTIL_COUNT=1.  There should be a requirement that the <scalar-int-expr> in the 
UNTIL_COUNT shall be positive so that processors can be encouraged to report 
such mistakes.

(4) Note 6.2 should be normative text.  Assuming that those are the semantics we 
want.

(5) Perhaps Note 6.1 should be normative and state something like "The segment 
following execution of an EVENT POST statement is not ordered with respect to 
the segment following the corresponding EVENT WAIT statement.".  Mind you that 
would require us properly describing the concept of "the corresponding EVENT 
WAIT" (which we seem to half-way have, but not clearly described).

(6) Use of EVENT_QUERY + SYNC MEMORY looks very scary.  It would be possible to 
use this to write remote-event-waiting, I am not entirely convinced that this is 
the right thing to do.  Perhaps an EVENT POLL statement would be safer (or an 
option to EVENT WAIT e.g. BLOCK=.FALSE.).

(7) And why doesn't EVENT QUERY simply say it returns the event count?  If the 
event count can ever not be equal to "the number of successful posts minus the 
number of successful waits" there is a problem.  If it is by definition equal to 
"the number of successful posts minus the number of successful waits", the 
wording is the problem.

(8) Is the processor supposed to support the following:
        INTEGER,PARAMETER :: i4 = SELECTED_INT_KIND(18)
        EVENT WAIT(UNTIL_COUNT = HUGE(0_i4))
    ???  That looks pretty gross so maybe not, but what about
        EVENT WAIT(UNTIL_COUNT = 100*1000*1000)
    ???  (And if that is still gross, EVENT_COUNT=1000 ...)
    For that matter, what about many EVENT POSTs before an EVENT WAIT.  Is there 
a limit?  Presumably yes, then let's (a) say there is a limit (b) require (or at 
least recommend) the processor to raise an error condition if the limit is 
exceeded (c) specify a minimum limit that the processor must implement; HUGE(0) 
springs to mind.

>4) Abstain.

I was going to abstain since I don't have the time to really go over the 
document properly, and indeed I have not, but I think the above is sufficient 
for No.

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