As we discussed, the manual isn't completely consistent in its
use of @code for const and volatile qualifiers. I made a pass
through extend.texi and added @code wherever it seemed to be
missing. This doesn't mean all uses but only those that
specifically refer to the qualifiers. In terms like "const
function" or "volatile object" the terms "const" and "volatile"
do not specifically refer to the qualifiers and so they don't
get the @code. AFAICS, this is in line with existing usage in
the manual and also in the C and C++ standard (though none is
100% consistent).
While doing this, I also noticed similar inconsistencies in
the quoting of the values true and false, and in references
to the asm statement. There too the manual tends to use @code
more often than not, so I made similar changes there. Here
too I've left unchanged uses of the ordinary English words
true or false.
I made no other changes here so the churn is only the result
of maintaining the 80 characters per line limit.
If we're happy with this as the general rule of thumb to use
in these cases I'll propose an update to the Coding Guidelines
to capture it.
Martin
gcc/ChangeLog:
* doc/extend.texi: Consistemtly use @code for const and volatile
qualifiers and asm statements.
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 267103)
+++ gcc/doc/extend.texi (working copy)
@@ -8483,7 +8483,8 @@ All basic @code{asm} blocks are implicitly volatil
@item inline
If you use the @code{inline} qualifier, then for inlining purposes the size
-of the asm is taken as the smallest size possible (@pxref{Size of an asm}).
+of the @code{asm} statement is taken as the smallest size possible (@pxref{Size
+of an asm}).
@end table
@subsubheading Parameters
@@ -8629,7 +8630,8 @@ qualifier to disable certain optimizations. @xref{
@item inline
If you use the @code{inline} qualifier, then for inlining purposes the size
-of the asm is taken as the smallest size possible (@pxref{Size of an asm}).
+of the @code{asm} statement is taken as the smallest size possible
+(@pxref{Size of an asm}).
@item goto
This qualifier informs the compiler that the @code{asm} statement may
@@ -8741,7 +8743,7 @@ void DoCheck(uint32_t dwSomeValue)
The next example shows a case where the optimizers can recognize that the input
(@code{dwSomeValue}) never changes during the execution of the function and can
therefore move the @code{asm} outside the loop to produce more efficient code.
-Again, using @code{volatile} disables this type of optimization.
+Again, using the @code{volatile} qualifier disables this type of optimization.
@example
void do_print(uint32_t dwSomeValue)
@@ -8797,11 +8799,11 @@ GCC's optimizers do not treat this code like the n
earlier examples. They do not move it out of loops or omit it on the
assumption that the result from a previous call is still valid.
-Note that the compiler can move even volatile @code{asm} instructions relative
+Note that the compiler can move even @code{volatile asm} instructions relative
to other code, including across jump instructions. For example, on many
targets there is a system register that controls the rounding mode of
-floating-point operations. Setting it with a volatile @code{asm}, as in the
-following PowerPC example, does not work reliably.
+floating-point operations. Setting it with a @code{volatile asm} statement,
+as in the following PowerPC example, does not work reliably.
@example
asm volatile("mtfsf 255, %0" : : "f" (fpenv));
@@ -8808,9 +8810,10 @@ asm volatile("mtfsf 255, %0" : : "f" (fpenv));
sum = x + y;
@end example
-The compiler may move the addition back before the volatile @code{asm}. To
-make it work as expected, add an artificial dependency to the @code{asm} by
-referencing a variable in the subsequent code, for example:
+The compiler may move the addition back before the @code{volatile asm}
+statement. To make it work as expected, add an artificial dependency to
+the @code{asm} by referencing a variable in the subsequent code, for
+example:
@example
asm volatile ("mtfsf 255,%1" : "=X" (sum) : "f" (fpenv));
@@ -8819,7 +8822,7 @@ sum = x + y;
Under certain circumstances, GCC may duplicate (or remove duplicates of) your
assembly code when optimizing. This can lead to unexpected duplicate symbol
-errors during compilation if your asm code defines symbols or labels.
+errors during compilation if your @code{asm} code defines symbols or labels.
Using @samp{%=}
(@pxref{AssemblerTemplate}) may help resolve this problem.
@@ -8848,7 +8851,7 @@ that some assembler dialects use semicolons to sta
Do not expect a sequence of @code{asm} statements to remain perfectly
consecutive after compilation, even when you are using the @code{volatile}
qualifier. If certain instructions need to remain consecutive in the output,
-put them in a single multi-instruction asm statement.
+put them in
