RE: volatile semantics

["Dave Korn" <dave dot korn at artimi dot com>]

----Original Message----
>From: Mike Stump
>Sent: 03 May 2005 09:42

> int avail;
> int main() {
>    while (*(volatile int *)&avail == 0)
>      continue;
>    return 0;
> }
> 
> 
> Ok, so, the question is, should gcc produce code that infinitely
> loops, or should it be obligated to actually fetch from memory?
> Hint, 3.3 fetched.
> 
> 
> I get:
> 
> L6:
>          b L6
> 
> on mainline and 4.0.

  Any difference if you change the function name from 'main' to something
else?

  And what happens if you precede the while line with

extern void foo (int *);

    foo (&avail);

or indeed what happens if you replace the definition of avail with an extern
declaration?

extern int avail;

(you'd need to link with another module that actually instantiates it of
course).

  Theoretically gcc could know that even though avail is volatile, its
address has never been taken (since here we are right at the beginning of
main), and since it's a compiler-allocated variable rather than referencing
some external location, there is no other way that it could be written into
or read from except through a pointer, and thus it really really really
isn't going to change.  In terms of language-lawyerlyness, you could argue
that the fact that the address is never taken means that any volatile
changes would not come  under the "externally visible" criterion...

  I agree that it should probably be prevented from losing the load, even if
it is a deliberate optimisation rather than a bug, but as far as I can see,
the only time this would crop up would be when you were dealing with flag
variables of the sort that are only meant to be set by running the
application under a debugger and manually storing values into them.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....