Re: mingw32 floating point diff

Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> writes:
> On 8/20/19 8:59 AM, Peter Eisentraut wrote:
>> Running the regression tests on mingw32, I get the following diff in
>> circle.out:
>> - | <(3,5),0> | <(1,2),3> | 0.60555127546399
>> + | <(3,5),0> | <(1,2),3> | 0.605551275463989

> I complained about this a year ago:
> <https://postgr.es/m/9f4f22be-f9f1-b350-bc06-521226b87f7a@dunslane.net>
> +1 for fixing it by any reasonable means.

Now that that fix is in, could we get a buildfarm member running on
such a platform? It seems to behave differently from anything else.

I tracked down the residual regression failures on dromedary with
-mfpmath=387, and found that they occur because check_float8_val
gets inlined and then its tests for "isinf(val)" and "val == 0.0"
are applied to the 80-bit intermediate results not the 64-bit form.
I find it odd that we apparently don't have the same issues on
mingw32.

I'm very hesitant to apply a volatile-qualification approach to
eliminate those issues, for fear of pessimizing performance-critical
code on more modern platforms. I wonder whether there is a reasonable
way to tell at compile time if we have a platform with 80-bit math.

regards, tom lane