Hi,
On 2021-06-27 16:21:46 -0400, Tom Lane wrote:
> 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.
We did fix a lot of them a few years back...
> 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.
Lack of failures after removing frwapv itself doesn't prove that much -
very commonly the compiler won't optimize based on the improved
knowledge about value range. Additionally we probably don't exercise all
effected places in our tests.
ubsan is able to catch all signed overflows. The last time I played
around with that, tests still were hitting quite a few cases of
overflows. But most not in particularly interesting places
(e.g. cash_out, RIGHTMOST_ONE()) but also a few where it might be worth
being careful about it in case a compiler disregards -fwrapv or doesn't
implement it (e.g. _dorand48()).
It might be worth setting up a bf animal with ubsan and enabled overflow
checking...
Greetings,
Andres Freund