(j3.2006) (SC22WG5.4094) [ukfortran] Standard intrinsics and coarrays

[N.M. Maclaren]

This is a redraft, hopefully fixing all of the mistakes and ambiguities
pointed out by Bill.


We seem to have forgotten to specify how the intrinsic procedures may
be used as far as their use in unordered images is concerned - or, at
least, I can't find anything.  However, I don't think that there is much
of a problem.  13.5 paragraph 2 and Table 13.1 is the starting point,
and a lot of my proposal is already implied for those of classes E, ES
and PS by other wording.  Those of class A are already covered.

I have drafted the hard line on random numbers; it would be possible to
make the 'shall be' conditional on the processor dependence, but that is
messy.

Proposal:

In 13.5, Standard generic intrinsic procedures, after Table 13.1, add
the new paragraphs:

    It is processor dependent whether EXECUTE_COMMAND_LINE may be called
    on any image other than image 1.

    If RANDOM_SEED is called in a segment A, and either RANDOM_SEED or
    RANDOM_NUMBER is called in segment B, then segments A and B shall be
    ordered.  It is processor dependent whether all images use a common
    generator or whether each image uses a separate one.

    It is processor dependent whether the results returned from CPU_TIME,
    DATE_AND_TIME, GET_COMMAND, GET_COMMAND_ARGUMENT,
    GET_ENVIRONMENT_VARIABLE and SYSTEM_CLOCK are dependent on which
    image calls them.

    NOTE 13.x
    It is unspecified whether images use synchronized clocks, whether
    CPU_TIME returns a per-image or per-program value, whether all
    images run in the same time zone, whether the count rate and
    maximum in SYSTEM_CLOCK are the same for all images, and whether all
    images run in the same command environment.  It is likely that they
    will behave differently on shared memory systems and some
    distributed memory ones.

    The use of all other standard intrinsic procedures in unordered
    segments is subject only to their argument use following the rules
    in 8.5.2.


Regards,
Nick Maclaren.