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

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 263ec60b431a88610ee8dbb0834ef14c98a316bb..8629ce799f4e5f3746160eb4ccd8dde6beadf620 100644 (file)
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+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)).

diff --git a/gcc/gcc.texi b/gcc/gcc.texi
index bf454e178384090c1f8965801b24a66d1447e3b4..06551cd036c9651f3afac878b7cc7559b914755c 100644 (file)
--- a/gcc/gcc.texi
+++ b/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.