From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
cc: Fabien COELHO <coelho@cri.ensmp.fr>
Subject: Re: Overflow hazard in pgbench
In-reply-to: <73927.1624815543@sss.pgh.pa.us>
References: <73927.1624815543@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Sun, 27 Jun 2021 13:39:03 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <82027.1624825306.1@sss.pgh.pa.us>
Date: Sun, 27 Jun 2021 16:21:46 -0400
Message-ID: <82028.1624825306@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/82028.1624825306%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> ... according to the C99
> spec this code is broken, because the compiler is allowed to assume
> that signed integer overflow doesn't happen, whereupon the second
> if-block is provably unreachable.  The failure still represents a gcc
> bug, because we're using -fwrapv which should disable that assumption.
> However, not all compilers have that switch, so it'd be better to code
> this in a spec-compliant way.

BTW, for grins I tried building today's HEAD without -fwrapv, using
	gcc version 11.1.1 20210531 (Red Hat 11.1.1-3) (GCC) 
which is the newest version I have at hand.  Not very surprisingly,
that reproduced the failure shown on moonjelly.  However, after adding
the patch I proposed, "make check-world" passed!  I was not expecting
that result; I supposed we still had lots of lurking assumptions of
traditional C overflow handling.

I'm not in any hurry to remove -fwrapv, because (a) this result doesn't
show that we have no such assumptions, only that they must be lurking
in darker, poorly-tested corners, and (b) I'm not aware of any reason
to think that removing -fwrapv would provide benefits worth taking any
risks for.  But we may be closer to being able to do without that
switch than I thought.

			regards, tom lane