From: Zdenek Dvorak Date: Wed, 20 Jul 2005 08:29:44 +0000 (+0200) Subject: * doc/trouble.texi: Update section on handling of empty loops. X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=67135ef48c6a53e06305d1038c4855e887568989;p=gcc.git * doc/trouble.texi: Update section on handling of empty loops. From-SVN: r102190 --- diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 61dbaef78e9..fd08ae3b154 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,7 @@ +2005-07-20 Zdenek Dvorak + + * doc/trouble.texi: Update section on handling of empty loops. + 2005-07-20 Kazu Hirata * config.gcc: Remove support for sparc-*-openbsd*, diff --git a/gcc/doc/trouble.texi b/gcc/doc/trouble.texi index 01c0c192d59..c65ad70bebe 100644 --- a/gcc/doc/trouble.texi +++ b/gcc/doc/trouble.texi @@ -1220,14 +1220,10 @@ However, the rationale here is that optimization of a nonempty loop cannot produce an empty one. This held for carefully written C compiled with less powerful optimizers but is not always the case for carefully written C++ or with more powerful optimizers. - -@opindex funroll-loops Thus GCC will remove operations from loops whenever it can determine those operations are not externally visible (apart from the time taken -to execute them, of course). As GCC improves, it will remove the loop -itself. Indeed, with @option{-funroll-loops} small loops can already be -removed, so leaving an empty non-unrolled loop is both sub-optimal and -inconsistent. +to execute them, of course). In case the loop can be proved to be finite, +GCC will also remove the loop itself. Be aware of this when performing timing tests, for instance the following loop can be completely removed, provided