[MPI3 Fortran] Results from the Fortran plenary session yesterday

[N.M. Maclaren]

Thank you for posting this.  Here are some comments on the substantive
issues, referring to the tickets as needed.  Please note that they are
my personal ones, and I am not speaking for WG5 or anyone else.


Page 4.  As you know, some of us are working on this in WG5 and J3.


#232.  This is a mistake.  Some compilers do not have such hacks, and
it isn't desirable to forbid them to support a MPI module, especially if
they do at present.  The words "if possible" should be added.


Page 14.  A Technical Report is, indeed, 'official', but it is also
optional on vendors.  Most have stated that they will support at least
the parts that MPI needs.  The current TR is definitely unstable, though
TYPE(*) and DIMENSION(..) are among the stable parts.


#236.  The Fortran term is 'array sections'.

There is no realistic change of vector subscripts being permitted for
use as buffers in non-blocking calls, so it's a permanent restriction.


#237.  Please be careful.  It would be terribly easy to specify more
than is guaranteed or reliable.


#238.  The word 'register' should be removed, effectively throughout
16.2, as the majority of problems have nothing to do with registers.
It is misleading.

I can find no reference to TARGET in ticket #238.  As I believe that you
may intend to say, the advice on using one-sided communication should
be that the TARGET attribute on the window is adequate for active
one-sided communication, but VOLATILE is needed for passive.

Actually, I believe that ASYNCHRONOUS would do as well, but should
prefer to run that one past WG5.

The proposed solution is incorrect.  Even if the variables are stored
in modules or COMMON blocks, the VOLATILE or TARGET attribute is still
needed.  The data may not go away, but a compiler is allowed to make
several assumptions that are incompatible with one-sided communication.
VOLATILE or TARGET is both necessary and sufficient.

On this topic, it is NOT possible for MPI implementations to avoid this
for conforming C programs, with a strict interpretation of the C
standard, but the C standard is such a mess that there is no point in
trying to say anything else.  And, yes, it really does cause trouble.
If anyone is interested, I can describe some of the issues, but I
suggest just ignoring the matter.

I suggest playing down that DD() trick, as it is VERY deceptive.  In
particular, as soon as a user enables significant optimisation, it is
likely to trigger global optimisation and inlining, which will stop
the trick from working!  The ways of preventing that are so repulsive
that you don't want to describe them - and are unreliable anyway.

MPI_F_SYNC_REG/MPI_SYNC_REG/MPI_FLUSH_REG is a really bad idea.  It has
been tried many times in many interfaces, and has never worked reliably.
That is both because flushing registers is a compiler and not a library
issue and because the problems often occur in a calling procedure.  For
a specification that attempts to take this approach and get it right,
look at the IA64 architecture, especially with regard to unwind
sections.  My executive summary is "Don't go there".


#242.  Unless I have missed something more than usually subtle, this
ticket misunderstands the meaning of INTENT(IN).  There is no problem in
specifying it for ALL input-only arguments, as it would not stop MPI
'constants' from being passed.  It constrains the use of the argument
and not the actual argument.

Not specifying INTENT(IN) has a lot of harmful effects, including
degraded optimisation.

Why do people believe that there is a problem?


#246.  This is a really good idea because, inter alia, 'Cray pointers'
are seriously non-portable even to compilers that claim to support them.
However, it's more than a description - it's a change of specification.

Do you need help with the specification of the new interface?



Regards,
Nick Maclaren.