On Sun, Mar 18, 2018 at 09:02:59PM -0400, Tom Lane wrote:
> Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> > On 03/18/2018 08:59 PM, PG Bug reporting form wrote:
> >> arrayfuncs.c:3740:17: runtime error: member access within misaligned address
> >> 0x0000028b937c for type 'struct ExpandedObjectHeader', which requires 8 byte
> >> alignment
> 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;
>
> 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.
Yep.
> 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.
Using different casts, as attached, silences these complaints without much
change in code cosmetics. DatumGetAnyArrayP() already assumes one can cast
between AnyArrayType and ArrayType, so this doesn't introduce new assumptions.
This is enough to make my infrequent "gcc -fsanitize=undefined
-fno-sanitize=nonnull-attribute" runs complaint-free under gcc 8.3.0 on
sparc64. (I use -fno-sanitize=nonnull-attribute to avoid the complaints about
memcpy(NULL, NULL, 0) and such. While formally undefined, fixes for those
would be uglier, and I expect we'll learn quickly enough if some
implementation treats them as other than a no-op.)