From: Tom Lane <tgl@sss.pgh.pa.us>
To: Noah Misch <noah@leadboat.com>
cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>, marxin.liska@gmail.com,
        pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15121: Multiple UBSAN errors
In-reply-to: <20190629210334.GA1244217@rfd.leadboat.com>
References: <152140318583.11955.7731957058248462341@wrigleys.postgresql.org>
 <7df78014-c931-6c75-6f92-ec48f390b2b9@2ndquadrant.com>
 <20078.1521421379@sss.pgh.pa.us> <20190629210334.GA1244217@rfd.leadboat.com>
Comments: In-reply-to Noah Misch <noah@leadboat.com>
	message dated "Sat, 29 Jun 2019 14:03:34 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <15736.1561920764.1@sss.pgh.pa.us>
Date: Sun, 30 Jun 2019 14:52:44 -0400
Message-ID: <15737.1561920764@sss.pgh.pa.us>
Precedence: bulk

Noah Misch <noah@leadboat.com> writes:
> On Sun, Mar 18, 2018 at 09:02:59PM -0400, Tom Lane wrote:
>> What I think might be happening is that the compiler is taking the
>> fact that the pointer is declared as AnyArrayType *, where ...
>> 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.

> Using different casts, as attached, silences these complaints without much
> change in code cosmetics.

I'd intentionally avoided using casts this way as an attempt to ensure
that these macros weren't accidentally applied to the wrong kind of
pointer.  However, avoiding UBSAN complaints (and perhaps wrong code
generation) seems like a more important goal.  This patch looks OK to me.

			regards, tom lane