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

N.M. Maclaren nmm1
Thu Nov 13 03:19:37 EST 2008

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.

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

More information about the J3 mailing list