(j3.2006) (SC22WG5.3675) [ukfortran] N1755: Request for new features from MPI Forum
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.
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