Re: mingw32 floating point diff

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: mingw32 floating point diff
Дата
Msg-id 1456.1566764614@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: mingw32 floating point diff  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Ответы Re: mingw32 floating point diff  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: mingw32 floating point diff  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Список pgsql-hackers
Andrew Dunstan <andrew.dunstan@2ndquadrant.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: Statement timeout in pg_rewind
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Building infrastructure for B-Tree deduplication that recognizes whenopclass equality is also equivalence