Обсуждение: Opossum vs. float4 NaN

I see that opossum's owner just resurrected it after a period of being
MIA ... and it's failing a few regression tests with symptoms like
this:

 SELECT 'NaN'::float4;
- float4 
---------
-    NaN
+  float4  
+----------
+ Infinity
 (1 row)

I have no doubt that this is caused by the same platform bug that
I worked around in commit cb3e9e40b:

    However, it emerges that this tickles a compiler or hardware bug on
    buildfarm member opossum.  Test results from commit 55e0e4581 show
    conclusively that widening a float4 NaN to float8 produces Inf, not NaN,
    on that machine; which accounts perfectly for the window RANGE test
    failures it's been showing.  We can dodge this problem by making
    in_range_float4_float8 be an independent function, so that it checks
    for NaN inputs before widening them.

The reason that it's reappeared is the refactoring we've done recently
around snprintf: float4out is now taking its float4 argument and widening
it to double to pass to strtod, which is where the checks for Inf/NaN
happen.

We could imagine band-aiding around this by adding something like

#if defined(__netbsd) && defined(__mips)
    if (isnan(num))
        // return "NaN"
#endif

to float4out, but ick.  I was willing to do cb3e9e40b because it didn't
really make the code any uglier, but this would.  And I bet the issue
is going to cause problems somewhere for Andrew's Ryu patch, too.

I'm thinking we should regretfully retire opossum, unless there's
a software update available for it that fixes this bug.

            regards, tom lane

>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:

 Tom> The reason that it's reappeared is the refactoring we've done
 Tom> recently around snprintf: float4out is now taking its float4
 Tom> argument and widening it to double to pass to strtod, which is
 Tom> where the checks for Inf/NaN happen.
 [...]
 Tom> to float4out, but ick. I was willing to do cb3e9e40b because it
 Tom> didn't really make the code any uglier, but this would. And I bet
 Tom> the issue is going to cause problems somewhere for Andrew's Ryu
 Tom> patch, too.

Actually I'd expect the reverse - Ryu never widens a float4 to float8,
it does everything in integers after extracting the bits from the value;
so it should be immune to this issue.

-- 
Andrew (irc:RhodiumToad)

Glyn Astill <glynastill@yahoo.co.uk> writes:
> I guess the main question is; does anybody care about builds on a 20 year old netbsd/mipsel dinosaur?  I noticed
thereare now mips64el and mips64eb build-farm members. 

I tend to think that variety in the buildfarm is intrinsically a good
thing.  I'd rather see you continue to run the thing, perhaps with a
newer netbsd version if that will resolve the problem.

            regards, tom lane