| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
| Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: mingw32 floating point diff |
| Date: | 2019-08-25 20:49:38 |
| Message-ID: | 2578.1566766178@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I wrote:
> 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.
Hmmm ... I find that dromedary's compiler predefines __FLT_EVAL_METHOD__
as 2 not 0 when -mfpmath=387 is given. This seems to be something
that was standardized in C99 (without the double underscores), so
maybe we could do something like
#if __FLT_EVAL_METHOD__ > 0 || FLT_EVAL_METHOD > 0
to conditionalize whether we try to force the evaluation width in
check_float8_val and check_float4_val.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2019-08-25 20:56:13 | Re: Building infrastructure for B-Tree deduplication that recognizes when opclass equality is also equivalence |
| Previous Message | David Fetter | 2019-08-25 20:34:29 | Re: Statement timeout in pg_rewind |