[llvm-commits] [dragonegg] r130127 - in /dragonegg/trunk: README src/Types.cpp

[Duncan Sands]

Author: baldrick
Date: Mon Apr 25 07:13:51 2011
New Revision: 130127

URL: http://llvm.org/viewvc/llvm-project?rev=130127&view=rev
Log:
Fix a few spelling errors.

Modified:
    dragonegg/trunk/README
    dragonegg/trunk/src/Types.cpp

Modified: dragonegg/trunk/README
URL: http://llvm.org/viewvc/llvm-project/dragonegg/trunk/README?rev=130127&r1=130126&r2=130127&view=diff
==============================================================================
--- dragonegg/trunk/README (original)
+++ dragonegg/trunk/README Mon Apr 25 07:13:51 2011
@@ -31,7 +31,7 @@
 that LTO requires libelf, though in fact it does not when using dragonegg.  See
   http://gcc.gnu.org/wiki/LinkTimeOptimization#Building_the_branch
 In theory the gcc you build can be a cross-compiler, and the plugin should work
-and build code for the targetted platform.  I don't think anyone has ever tried
+and build code for the targeted platform.  I don't think anyone has ever tried
 this though.
 
 Darwin special: the gcc configure script thinks darwin doesn't support dynamic

Modified: dragonegg/trunk/src/Types.cpp
URL: http://llvm.org/viewvc/llvm-project/dragonegg/trunk/src/Types.cpp?rev=130127&r1=130126&r2=130127&view=diff
==============================================================================
--- dragonegg/trunk/src/Types.cpp (original)
+++ dragonegg/trunk/src/Types.cpp Mon Apr 25 07:13:51 2011
@@ -316,7 +316,7 @@
 //
 // This code is built to make sure that the TYPE_LLVM field on tree types are
 // updated when LLVM types are refined.  This prevents dangling pointers from
-// occuring due to type coallescing.
+// occurring due to type coallescing.
 //
 namespace {
   class TypeRefinementDatabase : public AbstractTypeUser {
@@ -1779,7 +1779,7 @@
     }
   }
 
-  // Otherwise, this bitfield lives (potentially) partially in the preceeding
+  // Otherwise, this bitfield lives (potentially) partially in the preceding
   // field and in fields that exist after it.  Add integer-typed fields to the
   // LLVM struct such that there are no holes in the struct where the bitfield
   // is: these holes would make it impossible to statically initialize a global
@@ -1822,7 +1822,7 @@
     uint64_t AvailableBits = FirstUnallocatedByte * 8 - StartOffsetInBits;
     // This field's starting point is already allocated.
     if (StartOffsetFromByteBoundry == 0) {
-      // This field starts at byte boundry. Need to allocate space
+      // This field starts at byte boundary. Need to allocate space
       // for additional bytes not yet allocated.
       unsigned NumBitsToAdd = FieldSizeInBits - AvailableBits;
       Info.addNewBitField(NumBitsToAdd, ExtraSizeInBits, FirstUnallocatedByte);
@@ -1861,7 +1861,7 @@
     unsigned PadBytes = 0;
     unsigned PadBits = 0;
     if (StartOffsetFromByteBoundry != 0) {
-      // New field does not start at byte boundry.
+      // New field does not start at byte boundary.
       PadBits = StartOffsetInBits - (FirstUnallocatedByte*8);
       PadBytes = PadBits/8;
       PadBits = PadBits - PadBytes*8;
@@ -1877,7 +1877,7 @@
 
     FirstUnallocatedByte = StartOffsetInBits/8;
     // This field will use some of the bits from this PadBytes, if
-    // starting offset is not at byte boundry.
+    // starting offset is not at byte boundary.
     if (StartOffsetFromByteBoundry != 0)
       FieldSizeInBits += PadBits;
   }