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

ср, 5 авг. 2026 г., 09:41 Andrey Rachitskiy <pl0h0yp1(at)gmail(dot)com>:

> > 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
>>
>
>
>
Dear David,

Circling back on this issue — we paused two weeks ago awaiting your final
confirmation to apply the fix.

--
Regards,
Rachitskiy Andrey