Fine by me. I suggest to keep tracking this though, if necessary
in another bug item.
Regards,
Arno
On Fri, Aug 16, 2019 at 16:06:29 CEST, Peter Maydell wrote:
> Looking at our code we're still implementing the x87 insns FSIN, FCOS,
> FSINCOS, FPTAN, FPATAN, F2XM1, FYL2X, FYL2XP1 by "convert
Looking at our code we're still implementing the x87 insns FSIN, FCOS,
FSINCOS, FPTAN, FPATAN, F2XM1, FYL2X, FYL2XP1 by "convert the floatx80
to a host double and use the host C library functions", so I think this
bug is still unfixed. If the C program in comment 1 and/or the Python
code has
To be sure, you can also run my original C test code from
2010. If that produces a bit-identtical result, then this
has indeed been fixed. If there are deviations in the last
digits, then the fingerprinting issues is still there, but
at least Python has stopped complaining.
Regards,
Arno
On Fri,
The test code from comment #1 now prints out the correct value with QEMU
v4.1, so I think this has been fixed with the softfloat work that has
been done within the last year.
** Changed in: qemu
Status: Confirmed => Fix Released
--
You received this bug notification because you are a
That explains it. For most operations that approach works well as
basically nobody uses the 80 bit formats directly anyways. Unfortunately
asinh() is very badly conditioned in the region tested and it is not
enough.
A possible approach to fix this would be to use long double (128 bit)
were
Laurent Vivier recently started to adapt some of function from the
"Previous" NeXT emulator for m68k, see e.g. this patch series here:
https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg04454.html
Not sure, but I think that could help to fix at least some of the
missing functions.
--