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