Page MenuHomeFreeBSD

Allow lib/msun/logarithm_test to pass on ld128 platforms
ClosedPublic

Authored by arichardson on Mar 3 2021, 4:28 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 5 2024, 1:47 PM
Unknown Object (File)
Feb 2 2024, 2:26 AM
Unknown Object (File)
Dec 25 2023, 3:39 AM
Unknown Object (File)
Dec 20 2023, 5:23 AM
Unknown Object (File)
Dec 12 2023, 2:35 AM
Unknown Object (File)
Nov 20 2023, 3:23 PM
Unknown Object (File)
Nov 20 2023, 3:23 PM
Unknown Object (File)
Nov 20 2023, 3:17 PM
Subscribers

Details

Summary

The log1pl() implementation is less accurate than logl(), but does at least
guarantee precision >= the ld80 implementation. Increase the tolerance
to the ld80 equivalent for now.

Depends on D28798

PR: 253984

Test Plan

test passes now

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

ngie accepted this revision.EditedApr 16 2021, 8:11 PM
ngie added subscribers: dim, ngie.

Not my domain of expertise. Maybe someone like @dim or Steve Kargl would have better input 🤷...

Macro surewhynot:

This revision is now accepted and ready to land.Apr 16 2021, 8:11 PM

It's not very likely Steve Kargl can be convinced to create a Phabricator account. :)

That said, while I'm fine with the approach of "fix the test so it works", does anybody have an idea as to why lib/msun/ld128/s_logl.c has worse accuracy than the 80 bit version? AFAIK the whole point of log1p() is better accuracy...

In D29039#668715, @dim wrote:

It's not very likely Steve Kargl can be convinced to create a Phabricator account. :)

That said, while I'm fine with the approach of "fix the test so it works", does anybody have an idea as to why lib/msun/ld128/s_logl.c has worse accuracy than the 80 bit version? AFAIK the whole point of log1p() is better accuracy...

I'm afraid I also don't understand the implementation enough to figure out why this is the case.

This should really be an XFAIL, which I'll do for log1p_accuracy_tests. However, for accuracy_tests that would mean losing coverage for the other function so I'll keep this approach.