pgsql: Fix power() for large inputs yet more.
Fix power() for large inputs yet more.
Buildfarm results for commit e532b1d57 reveal the error in my thinking
about the unexpected-EDOM case. I'd supposed this was no longer really
a live issue, but it seems the fix for glibc's bug #3866 is not all that
old, and we still have at least one buildfarm animal (lapwing) with the
bug. Hence, resurrect essentially the previous logic (but, I hope, less
opaquely presented), and explain what it is we're really doing here.
Also, blindly try to fix fossa's failure by tweaking the logic that
figures out whether y is an odd integer when x is -inf. This smells
a whole lot like a compiler bug, but I lack access to icc to try to
pin it down. Maybe doing division instead of multiplication will
dodge the issue.
Discussion: /messages/by-id/E1jkU7H-00024V-NZ@gemulon.postgresql.org
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/5674eb98762ed41c7f9672a3bc56edf925e9d97d
Modified Files
--------------
src/backend/utils/adt/float.c | 34 +++++++++++++++++++++++-----------
1 file changed, 23 insertions(+), 11 deletions(-)
On Mon, Jun 15, 2020 at 11:10:43PM +0000, Tom Lane wrote:
Fix power() for large inputs yet more.
Buildfarm results for commit e532b1d57 reveal the error in my thinking
about the unexpected-EDOM case. I'd supposed this was no longer really
a live issue, but it seems the fix for glibc's bug #3866 is not all that
old, and we still have at least one buildfarm animal (lapwing) with the
bug. Hence, resurrect essentially the previous logic (but, I hope, less
opaquely presented), and explain what it is we're really doing here.
fossa seems to still be complaining after that:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fossa&dt=2020-06-16%2000%3A23%3A24
SELECT power(float8 '-inf', float8 '-2');
power
-------
- 0
+ -0
(1 row)
Thanks,
--
Michael
Michael Paquier <michael@paquier.xyz> writes:
fossa seems to still be complaining after that:
Yeah. Not sure what to do about that. It seems to be coming to the
wrong conclusion about whether yisoddinteger, but I can't think of
another way to code that that won't introduce other risks.
Worst case answer would be to remove this test case, or dumb it
down so that it can't distinguish +0 and -0 outputs. That
seems pretty annoying though, especially if (as I suspect)
every other buildfarm member gets this right.
regards, tom lane