gcc.texi (Non-bugs): ``Empty'' loops will be optimized away in the future...

	* gcc.texi (Non-bugs): ``Empty'' loops will be optimized away in
	the future; indeed that already happens in some cases.

From-SVN: r24442

gcc/ChangeLog

+Mon Dec 28 19:26:32 1998  Gerald Pfeifer  <pfeifer@dbai.tuwien.ac.at>
+
+	* gcc.texi (Non-bugs): ``Empty'' loops will be optimized away in
+	the future; indeed that already happens in some cases.
+
 Tue Dec 29 11:58:53 1998  Richard Henderson  <rth@cygnus.com>
 
 	* sparc.c (input_operand): Recognize (const (constant_p_rtx)).

gcc/gcc.texi

@@ -2005,12 +2005,18 @@ test explicitly for C++ as well.
 @item
 Deleting ``empty'' loops.
 
-GNU CC does not delete ``empty'' loops because the most likely reason
-you would put one in a program is to have a delay.  Deleting them will
-not make real programs run any faster, so it would be pointless.
-
-It would be different if optimization of a nonempty loop could produce
-an empty one.  But this generally can't happen.
+Historically, GNU CC has not deleted ``empty'' loops under the
+assumption that the most likely reason you would put one in a program is
+to have a delay, so deleting them will not make real programs run any
+faster.
+
+However, the rationale here is that optimization of a nonempty loop
+cannot produce an empty one, which holds for C but is not always the
+case for C++.
+
+Moreover, with @samp{-funroll-loops} small ``empty'' loops are already
+removed, so the current behavior is both sub-optimal and inconsistent
+and will change in the future.
 
 @item
 Making side effects happen in the same order as in some other compiler.