Re: Defend against -ffast-math in meson builds - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Defend against -ffast-math in meson builds
Date
Msg-id 3583.1773247555@sss.pgh.pa.us
Whole thread Raw
In response to Re: Defend against -ffast-math in meson builds  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
Responses Re: Defend against -ffast-math in meson builds
Re: Defend against -ffast-math in meson builds
List pgsql-hackers
Bertrand Drouvot <bertranddrouvot.pg@gmail.com> writes:
> On Wed, Mar 11, 2026 at 11:19:45AM -0400, Tom Lane wrote:
>> The defenses in those modules are probably obsolete too: aren't they about
>> ensuring exact results with floating-point timestamps?  My gut reaction to
>> this was maybe we could remove *all* of that, so now I'm curious what
>> problem Bertrand ran into.

> I got some regression tests failing: [1].

Yeah.  I quickly tried it here (ie remove the defenses and build with
-ffast-math), and observed failures in a couple dozen core regression
tests.  A bit of study suggests that

(1) both isnan() and isinf() tests are broken and always return false,
at least in some call sites;

(2) the code now seems exceedingly cavalier about near-overflow cases,
such as

regression=# select 1.175494e-38::float4;
ERROR:  "0.00000000000000000000000000000000000001175494" is out of range for type real

which is a case that works fine normally.

So no, I don't wanna support this.  But maybe we should move the
code-level tests out of the datetime files and into utils/float.h
or some such place.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Pang
Date:
Subject: [PATCH] Fix premature timeout in pg_promote() caused by signal interruptions
Next
From: shihao zhong
Date:
Subject: Re: [PATCH] Simplify ExecWithoutOverlapsNotEmpty by removing unused parameter