(j3.2006) Question I forgot to bring up at the meeting

Malcolm Cohen malcolm
Thu Jul 11 00:21:08 EDT 2013

Steve Lionel quotes:

F08, p94 (Explicit shape arrays), paragraph 2 says:

"The bounds, and hence shape, are determined on entry to a procedure defined by 
the subprogram, or on execution of the BLOCK statement, by evaluating the 
bounds' expressions. The bounds of each array are unaffected by the redefinition 
or undefinition of any variable during execution of the procedure or BLOCK 

And then goes on with:
>A literal reading of this would imply, to me, that the compiler should take a 
>single snapshot of any volatile variable, used in specification expressions, on 
>entry to the procedure or block, and then reference that copy.

No, it says that the bounds are not the specification expressions that define 
the bounds.  One evaluates the specification expressions once, then the bounds 
are fixed.

Seeing as how it is physically impossible to snapshot every VOLATILE variable in 
existence in a single indivisible instant (i.e. without taking time), and 
likewise it is physically impossible to evaluate every specification expression 
in the same indivisible instant (especially the ones that depend on other ones!) 
I don't think it is reasonable or even terribly plausible to read this as 
requiring the impossible.

>  I could see this as possibly conflicting with the description of VOLATILE 
> which says, in a note, that the processor "should use the most recent 
> definition".

I am not seeing any real conflict here.

Bill Long opined:
>If we want to allow VOLATILE variables in specification expressions,

We already did, a decade ago.  (And it was in compilers for several years prior 

>either we should warn the users about curious effects, or
>say that for the purposes of its use in a specification expression,
>treat the variable as if it did not have the VOLATILE attribute.

There is nothing in the standard that says that the variable does not have the 
VOLATILE attribute during specification expression evaluation.

There is absolutely no licence for the compiler to ignore the VOLATILE attribute 

(Well, apart from the fact that the description of the VOLATILE semantics is so 
weak that it has hardly any actual guarantees anyway.)

Steve Lionel suggested:
>"If a variable in a specification expression has the VOLATILE attribute, it is 
>processor-dependent how many times the variable's value is accessed during 
>evaluation of array bounds and length type parameters."

Apart from this being an unnecessary change of spec, this makes no sense as it 
is already processor-dependent how many times a variable is accessed...

Van Snyder conjectured:
>Either way, we need words in the standard.

The existing words seem ok.  Perhaps the second sentence quoted by Steve Lionel 
could be wordsmithed to make it less likely to be misread as demanding the 
impossible (or even the merely ridiculous).  Perhaps a judicious inclusion of 
the word "subsequent" would be sufficient, though we'd want to be sure we didn't 
create a possibility for a different misunderstanding.

>Can we handle this via an interp, such as the following?

Not like that.  At the very least if we're going to have an interp we should 
have the status quo (which is, incidentally, what I understood I was voting for 
in 2003!) as one of the options.

In the absence of an interp the standard is pretty clear.  On entry to a 
subprogram, the specification expressions are evaluated in some partial order --  
not "instantly and simultaneously" -- and after each expression is evaluated the 
bounds/lengths are fixed despite what happens to any variables in the 
expression.  In the case of a variable with the VOLATILE attribute, the 
processor "should use the most recent definition" while evaluating the 
specification expression... but...

the "guarantees" being rather limited...

...which means that the proposed note would apply to every VOLATILE variable. 
Worse than pointless.

There being no difference *in the evaluation part* of specification expression 
evaluation and executable expression evaluation, I see no reason that compilers 
can't just treat them as VOLATILE during specification expression evaluation. 
And since there is no guarantee about how many times a VOLATILE variable is 
accessed anyway, whatever happens is going to be standard-conforming.

To go back Van's original example:
>If the dummy argument is, say D, and the specification expression
>consists of D, then one could determine what the value of D was at the
>instant the specification expression was used for, say, an array bound
>by using, say, UBOUND(A,1).

Why, just like any ordinary variable then!

and Bill Long's:
>subroutine wobbly(N)
>   integer,volatile :: N
>   real :: A(N + N)
>   real :: B(2 *N)
>Are you sure that A and B are the same size?

Of course not.  In fact
  REAL A(N+N),B(N+N)
has the same comment.

OTOH, if the user *WANTS* them to be the same size even though N is volatilely 
changing, he can ensure that with
(only one expression => only one value)

>  Assuming the compiler does
>not optimize the bound expressions,  is it allowed that the computations
>of N + N and 2*N give different answers if N is volatile?

This does not appear to have anything to do with specification expressions...

...and since the compiler is free to evaluate any mathematically-equivalent 
expression, it can turn N+N into 2*N if it feels like it anyway.  Or vice versa.

And since it is VOLATILE, the simple expression "N" is permitted to have 
different values in successive appearances.

Not to mention that VOLATILE does not provide any guarantees about the number of 
times a variable is accessed while evaluating any expression in the first place. 
Unlike C, which *tries* to nail down what "volatile" means, pseudo-rigorously, 
Fortran does not attempt to do that - the furthest we go is a vague 

Frankly, I think all this worry about a hypothetical user thinking
  "This variable is VOLATILE, that means its value can change at *any time*, and 
that's ok, but Oh My God it might change at *this particular time* too!!!  I 
didn't expect *any time* to include *this time*...??!!!"
is rather overblown.  If he's gone to the trouble to tell the compiler that 
"hey, this can change at any time so be careful to always fetch the latest 
value", why would he be surprised if the compiler did precisely that.

................................Malcolm Cohen, Nihon NAG, Tokyo. 

More information about the J3 mailing list