This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Loop unrolling




On Wed, 3 Jun 1998, Joe Buck wrote:

> 
> > No.  The "volatile" requires the compiler to keep the implied
> > loads and stores, dispite the as-if rule, and thus the loop is
> > not empty, and thus not deleted.
> 
> I don't believe the standard ever makes an exception to the as-if rule.
> 'volatile' for a static or global variable matters because you can
> write a program where the effect is visible (make it multithreaded,

Volatile matters for auto variables too, if their address is taken.
However poor the practice may be, the address of such a variable may
be communicated to another thread.

> use a signal handler, map the variable to a hardware register).
> Thus 'volatile' is *not* an exception to as-if.

Actually, the standard doesn't define support for threading or hardware
register mapping, and the only thing that a maximally portable signal
handler may do is access a static object of type volatile sig_atomic_t. 

Thus to adhere with the as-if rule, a compiler can ignore the
the recommendations with respect to volatile. If a strictly conforming
program can't tell the difference, it's conforming. A strictly conforming
program can't be multi-threaded, nor can it access hardware registers.
There is no way for it to detect the changes in the state of the
execution environment brought about by accesses to volatile objects.

Of course, the compiler in question is GCC, which must meet additional
requirements because it is intended to support access to hardware
and threading. For that reason it must honor the volatile attribute
for static objects, objects referred to through pointers and auto
objects whose address is taken, to be safe.

A strict interpretation of the standard motivated by the desire to
determine what an implementation can get away with and still be
conforming is not appropriate to GCC.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]