Re: Solaris fails test with float8.
От | Tom Lane |
---|---|
Тема | Re: Solaris fails test with float8. |
Дата | |
Msg-id | 9705.1417188921@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Solaris fails test with float8. (Mats Erik Andersson <bsd@gisladisker.se>) |
Список | pgsql-bugs |
Mats Erik Andersson <bsd@gisladisker.se> writes: > (Please send me a carbon copy when responding.) > A Solaris system like my OpenIndiana oi_151a9 is failing > a single test case, namely float8, when testing either > of PostgreSQL 9.4beta2, 9.4beta3, and 9.4rc1. I do not > know how properly to interpret the output in expressed > in "regression.diffs", so tell whether I could do some > further modification to produce a better diagnosis. It appears that your machine is returning -Infinity, rather than throwing an error, for the case of -1.2345678901234e200 * 1e200 (both inputs being float8 not numeric). That test has been there since forever, so I'm pretty sure any previous Postgres release would also fail this test on such a machine. Looking a bit closer at float8mul leaves me wondering exactly what happened, though. It appears that the result of the multiplication did not satisfy isinf(), else the CHECKFLOATVAL macro would've thrown the expected error ... but then why did float8out print it as "-Infinity"? The most likely theory seems to go like this: the result of the multiplication is initially sitting in a wider-than-double register, which'd be able to represent -1.234e400 without overflow; the compiler applies an isinf operation to that register and decides it ain't infinity; but then when float8mul returns, the value has to be converted to plain double, at which point the hardware changes it to an IEEE infinity since the value is too large. If that's what went down, it's a compiler bug, because the text of the function is very clear that the multiplication result must be stored into a double (not long double) variable before isinf() is applied to it. regards, tom lane
В списке pgsql-bugs по дате отправления: