On 19 March 2018 at 02:02, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
>> On 03/18/2018 08:59 PM, PG Bug reporting form wrote:
>>> Building current trunk with -fsanitize=undefined I see following errors with
>>> make check:
>
>>> pg_crc32c_sse42.c:37:18: runtime error: load of misaligned address
>>> 0x7fffffffd484 for type 'const uint64', which requires 8 byte alignment
>>> 0x7fffffffd484: note: pointer points here
>
>> This comes from this call in pg_comp_crc32c_sse42
>> crc = (uint32) _mm_crc32_u64(crc, *((const uint64 *) p));
>> ...
>> So, not a bug.
>
> Agreed. That's Intel-only code so it doesn't need to be strict
> about alignment.
>
>>> arrayfuncs.c:3740:17: runtime error: member access within misaligned address
>>> 0x0000028b937c for type 'struct ExpandedObjectHeader', which requires 8 byte
>>> alignment
>
>> Again, the line numbers don't really match the code I have, but I guess
>> it's the same issue as for pg_comp_crc32c_sse42. This is apparently
>> related to array serialization, and I guess we have a compact structure
>> (intentionally, to make it smaller), and we accept the unaligned access.
>
> No, there's no intentional misalignment in the array stuff; if there
> were, it'd fail on alignment-picky hardware.
>
> What I think might be happening is that the compiler is taking the
> fact that the pointer is declared as AnyArrayType *, where
>
> typedef union AnyArrayType
> {
> ArrayType flt;
> ExpandedArrayHeader xpn;
> } AnyArrayType;
Hi.
>
> to assume that the pointer must be aligned on an 8-byte boundary because
> ExpandedArrayHeader would require that, even if we're only accessing the
> "flt" member. Maybe that's a live problem, though we've seen no related
> trouble reports. It'd require the compiler to generate 8-byte-aligned
> instructions for accessing the ArrayType header, which doesn't seem all
> that probable.
Yes, it's this:
https://stackoverflow.com/questions/891471/union-element-alignment/891473#891473
Thanks,
Martin
>
> regards, tom lane