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

[N.M. Maclaren]

On Nov 13 2008, Aleksandar Donev wrote:
>
>*Unless*, they also have the VOLATILE attribute! Two attributes together 
>mean something different. The contract should be as follows: If the 
>programmer knows that the value of the actual can change during the 
>execution of the program by means outside of the program (which, by the 
>way, are under the control and responsibility of the programmer, not 
>God!), then he/she is obliged to put the VOLATILE attribute on the dummy 
>so as to tell that to the compiler. The constraints ensure that no copy 
>in/out will be performed and thus those changes will be visible in the 
>routine. The INTENT(IN) attribute means that the value should not change 
>because of actions in the routine itself. In particular, external means 
>should not modify the value unless *both* the actual and the dummy are 
>VOLATILE. If it is intent OUT or INOUT or unspecified, then you can only 
>add VOLATILE to the dummy if the volatility only occurs while the 
>routine is executing but not once it finishes: the changes become 
>visible to the caller upon return.

Good God!  That makes C const look clean.  Sorry, but degrading Fortran
INTENT(IN) to be even worse than C const is a horrible idea.

I am not exaggerating when I say that C const is almost universally regarded
as a FAILURE by people who have attempted to use it seriously.  It does have
some use in protecting kiddies against themselves - but, unfortunately, the
benefit is lost because the kiddies sooner or later trip across the 'gotcha'
it introduces, and end up wasting more time than they had saved.

C const was originally introduced to aid optimisation; most compiler writers
tried using it, found that doing so broke conforming (but revolting) code,
and now more-or-less just check its syntax and otherwise ignore it.

Please, please, can we learn from other people's mistakes?

>Correct, which is why those constraints are stupid and should not be 
>there. It is the programmer's responsibility to manage the interaction 
>with the non-Fortran processes, and to add the attribute when necessary. 
>At the same time, he/she should have the freedom to omit it when it is 
>not necessary, to permit optimizations. Adding silly constraints that 
>prevent nothing but restrict the "management" cannot be rationalized by 
>the types of explanations you and Bill have provided.

How ON EARTH can a programmer do that in the absence of a specification? 
And I can assure you that there are NO specifications for 'external 
volatile' that apply to more than one compiler x operating system 
combination. And perhaps none even for any of those - I have never seen 
one, anyway :-(

I have been writing portable Fortran for nigh-on 40 years, and all competent
users at Cambridge do the same.  That allows them to debug on a workstation
and run on an HPC system, switch HPC systems and so on.


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