PR 17884

[Dale Johannesen <dalej at apple dot com>]

This changes the doc for 'asm volatile' to reflect my current 
understanding,
as described in the PR.  An example that contradicts rth's explanation 
is
also removed.  Ran 'make info' and verified the output looked OK.

Index: extend.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/extend.texi,v
retrieving revision 1.223
diff -u -d -b -w -p -r1.223 extend.texi
--- extend.texi 5 Oct 2004 07:15:01 -0000       1.223
+++ extend.texi 12 Oct 2004 22:16:57 -0000
@@ -3724,8 +3724,8 @@ if your instruction does have a side eff
 appears not to change, the old value of the variable may be reused 
later
 if it happens to be found in a register.

-You can prevent an @code{asm} instruction from being deleted, moved
-significantly, or combined, by writing the keyword @code{volatile} 
after
+You can prevent an @code{asm} instruction from being deleted
+by writing the keyword @code{volatile} after
 the @code{asm}.  For example:

 @smallexample
@@ -3737,36 +3737,22 @@ the @code{asm}.  For example:
 @end smallexample

 @noindent
-If you write an @code{asm} instruction with no outputs, GCC will know
-the instruction has side-effects and will not delete the instruction or
-move it outside of loops.

 The @code{volatile} keyword indicates that the instruction has
 important side-effects.  GCC will not delete a volatile @code{asm} if
 it is reachable.  (The instruction can still be deleted if GCC can
 prove that control-flow will never reach the location of the
-instruction.)  In addition, GCC will not reschedule instructions
-across a volatile @code{asm} instruction.  For example:
-
-@smallexample
-*(volatile int *)addr = foo;
-asm volatile ("eieio" : : );
-@end smallexample
-
-@noindent
-Assume @code{addr} contains the address of a memory mapped device
-register.  The PowerPC @code{eieio} instruction (Enforce In-order
-Execution of I/O) tells the CPU to make sure that the store to that
-device register happens before it issues any other I/O@.
-
-Note that even a volatile @code{asm} instruction can be moved in ways
-that appear insignificant to the compiler, such as across jump
-instructions.  You can't expect a sequence of volatile @code{asm}
-instructions to remain perfectly consecutive.  If you want consecutive
-output, use a single @code{asm}.  Also, GCC will perform some
-optimizations across a volatile @code{asm} instruction; GCC does not
-``forget everything'' when it encounters a volatile @code{asm}
-instruction the way some other compilers do.
+instruction.)  Note that even a volatile @code{asm} instruction
+can be moved relative to other code, including across jump
+instructions.  For example, you can't use a volatile @code{asm}
+instruction to set the bits of a floating point control register
+and expect that floating point instructions will not be moved
+across the @code{asm}; they can be.  Similarly, you can't expect a
+sequence of volatile @code{asm} instructions to remain perfectly
+consecutive.  If you want consecutive output, use a single @code{asm}.
+Also, GCC will perform some optimizations across a volatile @code{asm}
+instruction; GCC does not ``forget everything'' when it encounters
+a volatile @code{asm} instruction the way some other compilers do.

 An @code{asm} instruction without any operands or clobbers (an ``old
 style'' @code{asm}) will be treated identically to a volatile