This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[COMMITTED] [PATCH] Fix typo in comments and debugging dump


Index: gcc/ChangeLog
===================================================================
--- gcc/ChangeLog	(revision 217506)
+++ gcc/ChangeLog	(working copy)
@@ -1,3 +1,9 @@
+2014-11-13  Felix Yang  <felix.yang@huawei.com>
+
+	* ipa-utils.h: Fix typo in comments.
+	* ipa-profile.c: Likewise.
+	* tree-ssa-loop-ivcanon.c: Fix typo in comments and debugging dumps.
+
 2014-11-13  Teresa Johnson  <tejohnson@google.com>
 
 	PR tree-optimization/63841
Index: gcc/ipa-utils.h
===================================================================
--- gcc/ipa-utils.h	(revision 217506)
+++ gcc/ipa-utils.h	(working copy)
@@ -85,7 +85,7 @@ cgraph_node *try_speculative_devirtualization (tre
 					       ipa_polymorphic_call_context);
 
 /* Return vector containing possible targets of polymorphic call E.
-   If COMPLETEP is non-NULL, store true if the list is complette. 
+   If COMPLETEP is non-NULL, store true if the list is complete. 
    CACHE_TOKEN (if non-NULL) will get stored to an unique ID of entry
    in the target cache.  If user needs to visit every target list
    just once, it can memoize them.
Index: gcc/tree-ssa-loop-ivcanon.c
===================================================================
--- gcc/tree-ssa-loop-ivcanon.c	(revision 217506)
+++ gcc/tree-ssa-loop-ivcanon.c	(working copy)
@@ -29,7 +29,7 @@ along with GCC; see the file COPYING3.  If not see
    to pay up.
 
    We also perform
-     - complette unrolling (or peeling) when the loops is rolling few enough
+     - complete unrolling (or peeling) when the loops is rolling few enough
        times
      - simple peeling (i.e. copying few initial iterations prior the loop)
        when number of iteration estimate is known (typically by the profile
@@ -422,7 +422,7 @@ estimated_unrolled_size (struct loop_size *size,
    the same time it does not make any code potentially executed 
    during the last iteration dead.  
 
-   After complette unrolling we still may get rid of the conditional
+   After complete unrolling we still may get rid of the conditional
    on the exit in the last copy even if we have no idea what it does.
    This is quite common case for loops of form
 
@@ -775,7 +775,7 @@ try_unroll_loop_completely (struct loop *loop,
 		     loop->num);
 	  return false;
 	}
-      /* Outer loops tend to be less interesting candidates for complette
+      /* Outer loops tend to be less interesting candidates for complete
 	 unrolling unless we can do a lot of propagation into the inner loop
 	 body.  For now we disable outer loop unrolling when the code would
 	 grow.  */
@@ -986,7 +986,7 @@ try_peel_loop (struct loop *loop,
     {
       if (dump_file)
         fprintf (dump_file, "Not peeling: upper bound is known so can "
-		 "unroll complettely\n");
+		 "unroll completely\n");
       return false;
     }
 
Index: gcc/ipa-profile.c
===================================================================
--- gcc/ipa-profile.c	(revision 217506)
+++ gcc/ipa-profile.c	(working copy)
@@ -22,7 +22,7 @@ along with GCC; see the file COPYING3.  If not see
 
    - Count histogram construction.  This is a histogram analyzing how much
      time is spent executing statements with a given execution count read
-     from profile feedback. This histogram is complette only with LTO,
+     from profile feedback. This histogram is complete only with LTO,
      otherwise it contains information only about the current unit.
 
      Similar histogram is also estimated by coverage runtime.  This histogram

Attachment: fix-typo.diff
Description: fix-typo.diff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]