(j3.2006) (SC22WG5.3676) [ukfortran] N1755: Request for new features from MPI Forum

[N.M. Maclaren]

On Nov 13 2008, Aleksandar Donev wrote:
>
>I am confused as to whether this should go to WG5 or J3. I thought we 
>were not to have long technical arguments on WG5?

One might hope that, at this stage of the process, it wouldn't be necessary
to have long technical arguments.  But, as always, reality strikes .... :-(

>> Eh? What about NOTE 12.22?
>
>Do you get WG5 e-mails? Did you get my response to your message and take 
>a look at paper 08-165 and also 08-165r1.txt from meeting 184? That 
>paper of mine changed that Note! I don't have the exact new text (the 
>paper gives diff edits), but the intention is:
>"That is, the aversion to copy-in/out is only necessary, and therefore
>should only apply, if there is any chance that the volatility and/or
>asynchronicity is active either before or after the procedure call; 
>there is no problem if it is limited to only being within the called 
>procedure itself."

Malcolm has addressed the WG5 versus J3 issues.  I am associated with the
BSI not J3 and don't track J3 Emails.  I don't have time - Fortran is only
one of a dozen areas that I need to keep up with.

I get the WG5 Emails, yes, but I don't remember anything that referred to
those.  As I mentioned, I currently have only a ghastly Email interface.
Anyway, I have looked at it now.  My conclusion is different from yours.

I had misunderstood that dropping the VOLATILE and ASYNCHRONOUS attributes 
was allowed; several vendors did, too. If that remains, I shall have to add 
yet more statements to my courses "Do not touch this facility with a 
bargepole and, if you have a program with it in, seek expert help 
immediately."

In particular, allowing VOLATILE and ASYNCHRONOUS to be dropped should be
regarded as an error in the standard, as it FORCES copy-in/copy-out in a
way that even passing an assumed-shape array to an assumed-side one does
not :-(  The reason for that is that, once you have dropped them, none of
the constraints on argument passing apply at the next level down.  Even C
volatile and const get THAT one right (modulo the various loopholes).

It is also totally foul to implement for ASYNCHRONOUS :-( Consider a 
variable Wurzel with the ASYNCHRONOUS attribute that MAY have pending I/O 
on it, and is passed as an argument to a procedure without ASYNCHRONOUS. As 
I read the wording, that is permitted even if there IS pending I/O unless 
that procedure actually references, defines, undefines or changes Wurzel. 
Obviously, the processor is not allowed to copy it back in that case, so it 
has to perform a run-time check on whether there is pending I/O on Wurzel - 
without necessarily having any relevant ID to hand!

I regard that as a BUG in the standard.

>>> 2. "C559 An entity with the VOLATILE attribute shall be a variable that 
>>> is not an INTENT (IN) dummy argument." Please explain this one to me. 
>> Bill has explained this one.
>
>Except that, in my response, and Van's, we specifically disagreed with 
>the "explanation" and essentially called it an obfuscation. Did you read 
>those?

You did.  I refrained from responding, as my response would to have been
similar to yours, but the other way round.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679