(j3.2006) [MPI3 Fortran] Feedback from Fortran J3 meeting

[Dan Nagle]

Hello,

On May 27, 2008, at 5:48 PM, Aleksandar Donev wrote:

> Just apply the same rules as we apply to Fortran async I/O. The ASYNC
> attribute must be given to the actual and the dummy in both the  
> routine that
> starts the transfer and the scoping unit where that routine is  
> called, and
> the same for ending the transfer, *and* also for anything that gets  
> executed
> in-between the start and end of the transfer (the way I read it,  
> even if the
> code does not touch the variable in question, the ASYNC attribute  
> must be
> there, explicitly or implicitly).

The volatile attribute doesn't do that.  It tells the compiler
that the address is magic, and to always refer to the address
rather than caching anything.  And volatile has nothing to do
with the initiate-the-transfer call nor the wait call.  That is,
volatile doesn't identify the _calls_ as magic, only the address.
And block does not help because the two calls are likely
in different scopes.

> We cannot expect magic to happen and
> suddenly all compilers to perform human-grade interprocedural  
> analysis. The
> duty falls on the programmer.

Yes.  My point exactly.  So what tools can we reasonable make
that will help the programmer do a better job?

>>
> But the MPI specification is an onus on the programmer not to  
> interfere with
> the data transfer while it is in progress.

See my point above.

> All we (J3) need is to make sure
> the compiler does not do things behind the back of the programmer  
> (like move
> code, do copying, store things in temporary storage, etc.) that the
> programmer cannot control or know of, so as to at least give the  
> careful
> programmer a chance to do it right.

These are things that volatile doesn't guarantee to do.
What is needed is a way to say "between here and there,
don't touch this".

> If you want to help the bad programmer by adding some extra compile  
> time
> checks that is also good, but the first thing is to just give *a*  
> way to do
> it in a portable and safe manner.

If volatile were *a* way of supporting MPI, you'd have a point.
The requirement is for a way to say "don't touch this"
rather than saying "always touch this", which is what volatile does.

>> This is for the C TR, not f08.
> Either way----the goal is not to bloat the TR to become a new F2012  
> standard,
> but remain focused and small, IMO.

Well, the "bloat" goes somewhere.  Do we want to usefully address MPI
and any similar specification?  I think we decided to do so.

-- 
Cheers!

Dan Nagle