Thread: 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: https://postgr.es/m/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
Attachment
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