Re: BUG #19593: area(circle) silently returns Infinity instead of raising "value out of range: overflow"

> The outstanding question I have is, out of all the isinf(x) &&
> !isinf(y) checks, is float8_mul() the only one that suffers from this?
> Is it worth writing a set of regression tests that verify that's the
> case, so we can have some confidence that we've not missed something
> here?

Hi David,

On the outstanding question: it is not unique to float8_mul() as a
function. The miscompile needs an inlined
isinf(result) && !isinf(a) && !isinf(b) check after both operands are
proven finite. float8_mul() is where we have the clear SQL case
(circle_ar).

A small C harness on gcc 15 -O2 also broke for the same nested shape on
float8_pl, float8_mi, and float8_div (e.g. pl(mul,mul),
mi(mul(r,r), -1e308), div(mul(r,r), 1e-10)). Lone mi/div were fine.
Nested float4 mul did not miscompile in that probe.

I looked for other SQL cases on unpatched REL_18 with gcc 15. Only
area(circle) with radius 1e154 returned Infinity. Similar-looking
calls (point_div, point_mul, diameter, box area) already raised
overflow without a patch. So extra regress tests would not show the
compiler bug: those call sites do not hit the bad CFG. The only solid
SQL canary remains area(circle).

That is why v3 applies the same return-through-non-noreturn treatment to
all float8_{pl,mi,mul,div} on REL_14 through REL_18, based on the C
repro of the class, while leaving float4_* alone. The geometry canary
for area(circle) 1e154 remains the SQL check for the known bug.

ср, 5 авг. 2026 г. в 07:30, David Rowley <dgrowleyml(at)gmail(dot)com>:

> On Wed, 5 Aug 2026 at 05:11, Andrey Rachitskiy <pl0h0yp1(at)gmail(dot)com> wrote:
> > v2 drops escontext. The helpers are plain float8-returning wrappers
> > around the existing noreturn float_*_error() calls. The return 0.0 is
> > never reached. It is only there so the compiler treats the call as an
> > ordinary returning call. That CFG change is what keeps gcc 13+ jump
> > threading from deleting the outer isinf() check in float8_mul().
>
> IMO, this seems like a reasonably clean way to resolve the issue. I
> think it's quite good that we don't need to consider when to remove
> this once the GCC fix is patched out of existence. Since master has a
> good reason for using this pattern, that's going to stay, and we can
> let this fix die as the back branches age out.
>
> The outstanding question I have is, out of all the isinf(x) &&
> !isinf(y) checks, is float8_mul() the only one that suffers from this?
> Is it worth writing a set of regression tests that verify that's the
> case, so we can have some confidence that we've not missed something
> here?
>
> David
>

--
Regards,
Rachitskiy Andrey
Postgres Professional