[llvm-commits] [llvm] r150890 - in /llvm/trunk: include/llvm/ADT/Hashing.h lib/Support/CMakeLists.txt lib/Support/Hashing.cpp unittests/ADT/HashingTest.cpp unittests/CMakeLists.txt

Jay Foad jay.foad at gmail.com
Tue Feb 21 05:51:49 PST 2012


On 21 February 2012 11:37, Jay Foad <jay.foad at gmail.com> wrote:
> After committing Meador's patch to use this for uniquing struct and
> function types, I get this GCC warning about strict aliasing:
>
> In file included from
> /home/baldrick/osuosl/slave/clang-x86_64-debian-fnt/llvm.src/lib/VMCore/ConstantsContext.h:18,
>                 from
> /home/baldrick/osuosl/slave/clang-x86_64-debian-fnt/llvm.src/lib/VMCore/LLVMContextImpl.h:19,
>                 from
> /home/baldrick/osuosl/slave/clang-x86_64-debian-fnt/llvm.src/lib/VMCore/Type.cpp:14:
> /home/baldrick/osuosl/slave/clang-x86_64-debian-fnt/llvm.src/include/llvm/ADT/Hashing.h:
> In member function 'void llvm::DenseMap<KeyT, ValueT, KeyInfoT,
> ValueInfoT>::grow(unsigned int) [with KeyT = llvm::FunctionType*,
> ValueT = bool, KeyInfoT = llvm::FunctionTypeKeyInfo, ValueInfoT =
> llvm::DenseMapInfo<bool>]':
> /home/baldrick/osuosl/slave/clang-x86_64-debian-fnt/llvm.src/include/llvm/ADT/Hashing.h:170:
> warning: dereferencing pointer 'I' does break strict-aliasing rules
> /home/baldrick/osuosl/slave/clang-x86_64-debian-fnt/llvm.src/include/llvm/ADT/Hashing.h:155:
> note: initialized from here

... and I'm pretty sure that this is the reason for the "make check"
failures I see in a Release+Asserts build built with GCC 4.4.

I tried this workaround:

Index: include/llvm/ADT/Hashing.h
===================================================================
--- include/llvm/ADT/Hashing.h	(revision 151050)
+++ include/llvm/ADT/Hashing.h	(working copy)
@@ -167,7 +167,9 @@
   // Add a range of uint32s
   void addAligned(const uint32_t *I, const uint32_t *E) {
     while (I < E) {
-      mix(*I++);
+      uint32_t u;
+      memcpy(&u, I++, sizeof u);
+      mix(u);
     }
   }

and it fixes all the failures. But I have no idea what it does to the
generated code, or whether it's really a good way to work around the
aliasing problems.

Jay.




More information about the llvm-commits mailing list