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

	the future; indeed that already happens in some cases.


git-svn-id: https://gcc.gnu.org/svn/gcc/trunk@24442 138bc75d-0d04-0410-961f-82ee72b054a4

2 files changed, 17 insertions, 6 deletions

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 263ec60b431..8629ce799f4 100644
--- 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 bf454e17838..06551cd036c 100644
--- 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.