[DarkShikari]

    #define UNALIGNED_LOAD64(p) (*(const uint64*)(p))

    #define UNALIGNED_LOAD32(p) (*(const uint32*)(p))

Any function that uses both of these violates strict aliasing rules and might miscompile on recent gcc versions. Only one of them isn't enough, because char* is allowed to alias anything in C/C++. But if you use both, then you have a uint32_t* and a uint64_t* pointing to the same memory, violating the language spec.

ffmpeg has a header of macros to avoid this problem. They have names like AV_RN32A (aligned, native-endian 32-bit read), AV_RL32 (unaligned, little-endian 32-bit read) and so forth.

[haberman]

> Any function that uses both of these violates strict aliasing rules

More specifically, any function that uses both of these to access the same data violates strict aliasing rules. But this would imply that the data is being loaded redundantly, which seems unlikely in an implementation where speed is a top priority.

For example, I do not believe the following function violates strict aliasing rules:

    void foo(char *p) {
      bar(UNALIAGNED_LOAD64(p), UNALIGNED_LOAD32(p+8));
    }