VOLATILE and EQUIVALENCE
FX
following source:
logical event
integer i
volatile i
equivalence(event,i)
event = .false.
do
if (event) print *, 'gfhzjf'
end do
Should event be considered as volatile, or not? Or, asked in another way,
can the loop be optimized out?
Note 5.22 of F2003 (in 5.1.2.16) says "Similarly, all members of an
EQUIVALENCE group should have the VOLATILE attribute if one member has
the VOLATILE attribute." To my reading, that means that if you write code
such as the above (where not all members of the EQUIVALENCE group have
the VOLATILE attribute), the result is processor-dependent. This is
consistent with the C rules (for a volatile member of a union).
On the other hand, references like PGF77 Manual
(http://www.tacc.utexas.edu/services/userguides/pgi/pgf77_ref/f77ref04.htm#Heading128)
and Cray Fortran Reference Manual
(http://docs.cray.com/books/S-3692-51/html-S-3692-51/zfixedn3c8sk4c.html)
seem to explicitly say the opposite, that when you only specify one
member of the equivalence group to be volatile, all others are de facto
volatile. But of course, it might just be usage and not supported by the
Standard (checking reveals Intel and Sun compilers also follow this
course).
So, I once again plead for the word of the wise souls of c.l.f: does my
reading of the standard stands, or am I mistaken?
--
FX
Richard Maine
> I'm considering the interaction of VOLATILE and EQUIVALENCE. Consider the
> following source:
>
> logical event
> integer i
> volatile i
> equivalence(event,i)
> event = .false.
> do
> if (event) print *, 'gfhzjf'
> end do
>
> Should event be considered as volatile, or not? Or, asked in another way,
> can the loop be optimized out?
No, event is not volatile. Which is to say, yes, the loop can be
optimized out.
> Note 5.22 of F2003 (in 5.1.2.16) says "Similarly, all members of an
> EQUIVALENCE group should have the VOLATILE attribute if one member has
> the VOLATILE attribute." To my reading, that means that if you write code
> such as the above (where not all members of the EQUIVALENCE group have
> the VOLATILE attribute), the result is processor-dependent. This is
> consistent with the C rules (for a volatile member of a union).
No, I don't see anything about processor dependence. Event does not have
the volatile attribute. Therefore, it may not be changed by means
outside of Fortran. If it is so changed, then the program is
nonstandard. It is true that the result of the program being nonstandard
is essentially that things are processor-dependent, but that's a
secondary conclusion. The first level is just that such a program is
non-standard.
The "should" above is in a note. Also, "should" in standard-speak means
a recommendation - not a requirement. (That's also in accordance with
normal English usage, but it is explicit in standard-speak).
I'd interpret the above "should" somewhat like the following.
It is allowed for i to be volatile without event being volatile, but
that is an odd thing to do. In essence, that largely makes the
volatility of i ineffective in that the value of event is not allowed to
change from things outside of the program. That largely rules out i
changing either, as changing the value of i makes event go undefined. I
suppose that if event were already undefined anyway, it might be ok.
In any case, no event is not volatile. If it were, then there would be
no point at all in the standard's recommendation that you quoted. That
would be recommending a redundant declaration. While such redundancy
might be argued as good style, the standard doesn't make style
recommendations like that.
> On the other hand, references like PGF77 Manual
I can't comment constructively on 3rd party manuals.
But then, volatile is a strange feature in that it has absolutely no use
within the standard anyway. It inherently is about interacting with
things that are outside the scope of the standard. Basically, it just
standardizes part of the syntax of interacting with some nonstandard
features.
There were comments, only partly in jest, that the standard should just
say, in essence. "Here's the syntax of volatile; we aren't going to say
anything about what it means, but this is the syntax. You and your
compiler vendor can debate the meaning. If you don't know what this is
about, don't use it."
Note that a perfectly standard-conforming implementation of volatile
would be to ignore it other than to syntax-check it.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
Steve Lionel
> I'm considering the interaction of VOLATILE and EQUIVALENCE. Consider the
> following source:
> On the other hand, references like PGF77 Manual
> and Cray Fortran Reference Manual
> (http://docs.cray.com/books/S-3692-51/html-S-3692-51/zfixedn3c8sk4c.html)
> seem to explicitly say the opposite, that when you only specify one
> member of the equivalence group to be volatile, all others are de facto
> volatile. But of course, it might just be usage and not supported by the
> Standard (checking reveals Intel and Sun compilers also follow this
> course).
I see Richard has already commented regarding the status of a note in
the standard. I'll add that the texts you refer to are describing a
popular extension to F77 and not what eventually became standard,
though, unusually in this case, the two are very similar. In any
event, nothing written in a manual for a compiler not claiming to
support F2003's VOLATILE should be taken as a reading on the F2003
standard.
As a compiler implementor, I'll note that being part of an EQUIVALENCE
group often confers "volatile-like" status on all overlapping members
of the group, but this is not necessarily the same as an explicit
VOLATILE declaration. I read the note in the standard as a
recommendation of good style, not a requirement.
Steve
glen herrmannsfeldt
(snip)
> logical event
> integer i
> volatile i
> equivalence(event,i)
(snip)
> Should event be considered as volatile, or not?
> Or, asked in another way, can the loop be optimized out?
> Note 5.22 of F2003 (in 5.1.2.16) says "Similarly, all members of an
> EQUIVALENCE group should have the VOLATILE attribute if one member has
> the VOLATILE attribute." To my reading, that means that if you write code
> such as the above (where not all members of the EQUIVALENCE group have
> the VOLATILE attribute), the result is processor-dependent. This is
> consistent with the C rules (for a volatile member of a union).
In the case you give, both variables are the same size. That is not
always true for EQUIVALENCE or union. Consider:
logical event(10)
integer i
volatile i
equivalence(event(3),i)
Now, even if event(3) was considered volatile, other elements
would not be. Or:
double precision d
integer i
real r(2)
volatile i
equivalence (d,r),(i,r(2)
The compiler could (though as others have said the standard
doesn't require) consider r(2) volatile, but only half
of d is volatile, and it doesn't even have the same address.
-- glen