+2008-02-17 Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
+
+ * doc/c-tree.texi: Use @dots{} and @enddots{} where appropriate.
+ * doc/cfg.texi: Likewise.
+ * doc/extend.texi: Likewise.
+ * doc/gty.texi: Likewise.
+ * doc/invoke.texi: Likewise.
+ * doc/loop.texi: Likewise.
+ * doc/md.texi: Likewise.
+ * doc/passes.texi: Likewise.
+ * doc/rtl.texi: Likewise.
+ * doc/sourcebuild.texi: Likewise.
+ * doc/tm.texi: Likewise.
+ * doc/tree-ssa.texi: Likewise.
+
2008-02-17 Richard Guenther <rguenther@suse.de>
PR middle-end/35227
call_expr_arg_iterator iter;
FOR_EACH_CALL_EXPR_ARG (arg, iter, call)
/* arg is bound to successive arguments of call. */
- ...;
+ @dots{};
@end smallexample
For non-static
@item OMP_PARALLEL
-Represents @code{#pragma omp parallel [clause1 ... clauseN]}. It
+Represents @code{#pragma omp parallel [clause1 @dots{} clauseN]}. It
has four operands:
Operand @code{OMP_PARALLEL_BODY} is valid while in GENERIC and
@item OMP_FOR
-Represents @code{#pragma omp for [clause1 ... clauseN]}. It
+Represents @code{#pragma omp for [clause1 @dots{} clauseN]}. It
has 5 operands:
Operand @code{OMP_FOR_BODY} contains the loop body.
@item OMP_SECTIONS
-Represents @code{#pragma omp sections [clause1 ... clauseN]}.
+Represents @code{#pragma omp sections [clause1 @dots{} clauseN]}.
Operand @code{OMP_SECTIONS_BODY} contains the sections body,
which in turn contains a set of @code{OMP_SECTION} nodes for
@smallexample
goto *x;
- [ ... ]
+ [ @dots{} ]
goto *x;
- [ ... ]
+ [ @dots{} ]
goto *x;
- [ ... ]
+ [ @dots{} ]
@end smallexample
@noindent
@smallexample
goto y;
- [ ... ]
+ [ @dots{} ]
goto y;
- [ ... ]
+ [ @dots{} ]
goto y;
- [ ... ]
+ [ @dots{} ]
y:
goto *x;
Modifies the disposition of a diagnostic. Note that not all
diagnostics are modifiable; at the moment only warnings (normally
-controlled by @samp{-W...}) can be controlled, and not all of them.
+controlled by @samp{-W@dots{}}) can be controlled, and not all of them.
Use @option{-fdiagnostics-show-option} to determine which diagnostics
are controllable and which option controls them.
@item %0
The outermost structure that contains the current structure.
@item %a
-A partial expression of the form @code{[i1][i2]...} that indexes
+A partial expression of the form @code{[i1][i2]@dots{}} that indexes
the array item currently being marked.
@end table
For instance, suppose that you have a structure of the form
@smallexample
struct A @{
- ...
+ @dots{}
@};
struct B @{
struct A foo[12];
(if the debugging information format supports this information).
It is enabled by default when compiling with optimization (@option{-Os},
-@option{-O}, @option{-O2}, ...), debugging information (@option{-g}) and
+@option{-O}, @option{-O2}, @dots{}), debugging information (@option{-g}) and
the debug info format supports it.
@item -print-file-name=@var{library}
loop) equivalent to @code{x_1} in the following example
@smallexample
-while (...)
+while (@dots{})
@{
x_1 = phi (base, x_2);
x_2 = x_1 + step;
The syntax for defining a mode iterator is:
@smallexample
-(define_mode_iterator @var{name} [(@var{mode1} "@var{cond1}") ... (@var{moden} "@var{condn}")])
+(define_mode_iterator @var{name} [(@var{mode1} "@var{cond1}") @dots{} (@var{moden} "@var{condn}")])
@end smallexample
This allows subsequent @file{.md} file constructs to use the mode suffix
upper case. You can define other attributes using:
@smallexample
-(define_mode_attr @var{name} [(@var{mode1} "@var{value1}") ... (@var{moden} "@var{valuen}")])
+(define_mode_attr @var{name} [(@var{mode1} "@var{value1}") @dots{} (@var{moden} "@var{valuen}")])
@end smallexample
where @var{name} is the name of the attribute and @var{valuei}
each string and mode in the pattern for sequences of the form
@code{<@var{iterator}:@var{attr}>}, where @var{attr} is the name of a
mode attribute. If the attribute is defined for @var{mode}, the whole
-@code{<...>} sequence will be replaced by the appropriate attribute
+@code{<@dots{}>} sequence will be replaced by the appropriate attribute
value.
For example, suppose an @file{.md} file has:
@smallexample
(define_mode_iterator LONG [SI DI])
(define_mode_attr SHORT [(SI "HI") (DI "SI")])
-(define_insn ...
- (sign_extend:LONG (match_operand:<LONG:SHORT> ...)) ...)
+(define_insn @dots{}
+ (sign_extend:LONG (match_operand:<LONG:SHORT> @dots{})) @dots{})
@end smallexample
The @code{@var{iterator}:} prefix may be omitted, in which case the
The construct:
@smallexample
-(define_code_iterator @var{name} [(@var{code1} "@var{cond1}") ... (@var{coden} "@var{condn}")])
+(define_code_iterator @var{name} [(@var{code1} "@var{cond1}") @dots{} (@var{coden} "@var{condn}")])
@end smallexample
defines a pseudo rtx code @var{name} that can be instantiated as
Other attributes are defined using:
@smallexample
-(define_code_attr @var{name} [(@var{code1} "@var{value1}") ... (@var{coden} "@var{valuen}")])
+(define_code_attr @var{name} [(@var{code1} "@var{value1}") @dots{} (@var{coden} "@var{valuen}")])
@end smallexample
Here's an example of code iterators in action, taken from the MIPS port:
DONE;
@})
-...
+@dots{}
@end smallexample
@end ifset
TODO: describe the global variables set up by the pass manager,
and a brief description of how a new pass should use it.
-I need to look at what info rtl passes use first...
+I need to look at what info rtl passes use first@enddots{}
@node Tree-SSA passes
@section Tree-SSA passes
ordinary insn chain.
@findex concatn
-@item (concatn@var{m} [@var{rtx} ...])
+@item (concatn@var{m} [@var{rtx} @dots{}])
This RTX represents the concatenation of all the @var{rtx} to make a
single value. Like @code{concat}, this should only appear in
declarations, and not in the insn chain.
if the target system matches @var{selector}, that replace the default
options used for this set of tests.
-@item @{ dg-add-options @var{feature} ... @}
+@item @{ dg-add-options @var{feature} @dots{} @}
Add any compiler options that are needed to access certain features.
This directive does nothing on targets that enable the features by
default, or that don't provide them at all. It must come after
@smallexample
COMPAT_OPTIONS="[list [list @{@var{tst1}@} @{@var{alt1}@}]
- ...[list @{@var{tstn}@} @{@var{altn}@}]]"
+ @dots{}[list @{@var{tstn}@} @{@var{altn}@}]]"
@end smallexample
where @var{tsti} and @var{alti} are lists of options, with @var{tsti}
contain UNSPECs or UNSPEC_VOLATILEs. The DWARF 2 call frame debugging
info engine will invoke it on insns of the form
@smallexample
-(set (reg) (unspec [...] UNSPEC_INDEX))
+(set (reg) (unspec [@dots{}] UNSPEC_INDEX))
@end smallexample
and
@smallexample
-(set (reg) (unspec_volatile [...] UNSPECV_INDEX)).
+(set (reg) (unspec_volatile [@dots{}] UNSPECV_INDEX)).
@end smallexample
to let the backend emit the call frame instructions. @var{label} is
the CFI label attached to the insn, @var{pattern} is the pattern of
@{
int a, b, *p;
- if (...)
+ if (@dots{})
p = &a;
else
p = &b;
@{
int a, b, *p;
- if (...)
+ if (@dots{})
p = &a;
else
p = &b;
for it. For instance,
@smallexample
-if (...)
+if (@dots{})
a_1 = 5;
-else if (...)
+else if (@dots{})
a_2 = 2;
else
a_3 = 13;
1 L0:
2 x_1 = PHI (0, x_5)
3 if (x_1 < 10)
- 4 x_10 = ...
+ 4 x_10 = @dots{}
5 if (x_1 > 7)
6 y_2 = 0
7 else
- 8 x_11 = ...
+ 8 x_11 = @dots{}
9 y_3 = x_1 + x_7
10 endif
11 x_5 = x_1 + 1
munge_stmt (tree stmt)
@{
push_stmt_changes (&stmt);
- ... rewrite STMT ...
+ @dots{} rewrite STMT @dots{}
pop_stmt_changes (&stmt);
@}
@end smallexample
after alias analysis, we will have:
@smallexample
-may-aliases(T) = @{ V1, V2, V3, ..., Vn @}
+may-aliases(T) = @{ V1, V2, V3, @dots{}, Vn @}
@end smallexample
This means that every statement that references T, will get
@smallexample
may-aliases(V1) = @{ T @}
may-aliases(V2) = @{ T @}
-...
+@dots{}
may-aliases(Vn) = @{ T @}
@end smallexample