brain thinking memcpy, fingers thinking memset :)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65701 91177308-0d34-0410-b5e6-96231b3b80d8

diff --git a/lib/CodeGen/CGExprAgg.cpp b/lib/CodeGen/CGExprAgg.cpp
index b0596e2feebd0f68ee0de8e71e40ec8e649e25ec..b3d9cb68432f1a9199b2b08ba1f25307b8190e56 100644 (file)
--- a/lib/CodeGen/CGExprAgg.cpp
+++ b/lib/CodeGen/CGExprAgg.cpp
@@ -518,13 +518,13 @@ void CodeGenFunction::EmitAggregateCopy(llvm::Value *DestPtr,
                                         llvm::Value *SrcPtr, QualType Ty) {
   assert(!Ty->isAnyComplexType() && "Shouldn't happen for complex");
   
-  // Aggregate assignment turns into llvm.memset.  This is almost valid per
+  // Aggregate assignment turns into llvm.memcpy.  This is almost valid per
   // C99 6.5.16.1p3, which states "If the value being stored in an object is
   // read from another object that overlaps in anyway the storage of the first
   // object, then the overlap shall be exact and the two objects shall have
   // qualified or unqualified versions of a compatible type."
   //
-  // memset is not defined if the source and destination pointers are exactly
+  // memcpy is not defined if the source and destination pointers are exactly
   // equal, but other compilers do this optimization, and almost every memcpy
   // implementation handles this case safely.  If there is a libc that does not
   // safely handle this, we can add a target hook.