From: Tom Lane <tgl@sss.pgh.pa.us>
To: Fabien COELHO <coelho@cri.ensmp.fr>
cc: Michael Banck <michael.banck@credativ.de>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: pg_verify_checksums and -fno-strict-aliasing
In-reply-to: <alpine.DEB.2.21.1808301325070.32764@lancre>
References: <1535618100.1286.3.camel@credativ.de>
 <alpine.DEB.2.21.1808301325070.32764@lancre>
Comments: In-reply-to Fabien COELHO <coelho@cri.ensmp.fr>
	message dated "Thu, 30 Aug 2018 13:25:14 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7320.1535639966.1@sss.pgh.pa.us>
Date: Thu, 30 Aug 2018 10:39:26 -0400
Message-ID: <7321.1535639966@sss.pgh.pa.us>
Precedence: bulk

Fabien COELHO <coelho@cri.ensmp.fr> writes:
>> If I add -fno-strict-aliasing to $CFLAGS, the problem goes away.
>> Is this something to worry about, or just pilot error cause I am not
>> using the same $CFLAGS as for the rest of the build? I originally
>> noticed this problem with my external fork of pg_verify_checksums.

> It looks like the code is using aliasing where the standard says it should 
> not, which breaks compiler optimization, and the added options tells the 
> compiler to not assume that the code conforms to the standard...

Actually, this code is just plain broken:

	char		buf[BLCKSZ];
	PageHeader	header = (PageHeader) buf;

There is no guarantee that a local char[] array is aligned on anything
stronger than a byte boundary, and if it isn't, word-sized accesses to
*header are going to fail on machines with strict alignment rules.
I suppose that that is really what Michael's compiler is moaning about.

I rather suspect that this hasn't been tested on anything but Intel
hardware, which is famously misalignment-tolerant.  The lack of any
apparent regression test infrastructure for it isn't leaving a warm
feeling about how much the buildfarm is testing it.

(The right fix, of course, is to malloc the work buffer rather than
put it on the stack.)

			regards, tom lane