semantic: 0.692 graphic: 0.690 assembly: 0.683 other: 0.659 network: 0.626 instruction: 0.621 device: 0.589 vnc: 0.488 socket: 0.486 boot: 0.428 mistranslation: 0.416 KVM: 0.319 QEMU x87 emulation of trig and other complex ops is only at 64-bit precision, not 80-bit When doing the regression tests for Python 3.1.2 with Qemu 0.12.5, (Linux version 2.6.26-2-686 (Debian 2.6.26-25lenny1)), gcc (Debian 4.3.2-1.1) 4.3.2, Python compiled from sources within qemu, 3 math tests fail, apparently because the floating point unit is buggy. Qmeu was compiled from original sources on Debian Lenny with kernel 2.6.34.6 from kernel.org, gcc (Debian 4.3.2-1.1) 4.3. Regression testing errors: test_cmath test test_cmath failed -- Traceback (most recent call last): File "/root/tools/python3/Python-3.1.2/Lib/test/test_cmath.py", line 364, in self.fail(error_message) AssertionError: acos0034: acos(complex(-1.0000000000000002, 0.0)) Expected: complex(3.141592653589793, -2.1073424255447014e-08) Received: complex(3.141592653589793, -2.1073424338879928e-08) Received value insufficiently close to expected value. test_float test test_float failed -- Traceback (most recent call last): File "/root/tools/python3/Python-3.1.2/Lib/test/test_float.py", line 479, in self.assertEqual(s, repr(float(s))) AssertionError: '8.72293771110361e+25' != '8.722937711103609e+25' test_math test test_math failed -- multiple errors occurred; run in verbose mode for deta => runtests.sh -v test_math le01:~/tools/python3/Python-3.1.2# ./runtests.sh -v test_math test_math BAD 1 BAD 0 GOOD 0 SKIPPED 1 total le01:~/tools/python3/Python-3.1.2# Just found time to look a bit deeper into this. The problem is in the (real) asinh() function. I think it is possible that somewhere a calculation was done in float instead of double or a double value was shortened to float. Please note that until this is fixed, qemu i386 is not IEEE754 conform. Minimal test code in c: --- #include #include int main(){ /* compile with gcc -lm test.c */ double x, y; x = -2.1073424255447017e-08; y = asinh(x); printf("y = %20.16e\n",y); printf("should be -2.1073424255447017e-08\n"); } --- Forgot so say: This is still present in 0.13.0. And I unexpectedly had more time to dig. Findings: - asinh() is not in IEEE754, please ignore my comment about non-conformity, sorry. - The calculation for asinh() is pretty badly conditioned, i.e. it blows up errors in the basic calculations. - asinh() is implemented in glibc in assembler on the FPU stack. This would mean 80 bits float representation. Error observations: Calculations for asinh( -2.1073424255447017e-08), derived from the Python 3.1.2 selftest. Formula is asinh(x) = log(x+sqrt(x*x+1)) Reference is a calculation with long double (128 bit) - qemu: 6 correct digits behind the dot - C with double: 7 correct digits behind the dot - i387: 10 correct digits behind the dot Possible root cause: The observed error may be due to qemu using 64 bit double math in the FPU implementation, instead of the 80 bit internal precision a real i387 uses. Comparison with kernel i387 emulation As an additional verification, I tried the calculations using the Linux kernel coprocessor emulation. This basically failed. With kernel 2_6_26 and 2_6_27 and the ''no387'' flag, the kernel locked up without output early during boot. With 2.6.34, I could not do an ssh login. I may try this again later, and especially try to find out what is wrong with qemu and 2.6.34. Consequences: 1) qemu is significantly less accurate for some mathematics than a genuine i387. This may cause problesm with sensitive mathematics developed on a real i387. 2) qemu can be fingerprinted easily using this problem. This may have security implications. Fix Options: 1) - Moving the FPU internal representation to long double. It will still not be the same results as on an i387, but it will be _more_ accurate instead of less, which generally is far less of a problem. Pro: Higher accuracy Cons: Slower - Use code derived from the Linux kernel i387 FPU emulator. The emulator is not bit-exact, but relatively close and it is used at least on some small x86 architectures. Pro: Higher accuracy Cons: Need to integrate foreign code - Leave it as it is but add a clear warning to the "Known qemu Problems" Section in the manual and Wiki (I did not find one, I think it should be added in an easily findable place), that i387 FPU emulation is only 64 bits internally and may be less exact for combined calculations done on the FPU stack, such as asinh() in glibc(), than a real i387. You may recommend to use kernel FPU emulation, but this may not work or be a pain to get working. Pro: Least work Cons: Not really a solution 2) Fixing this is difficult and there are other ways to find out that you are running in qemu anyways. I think the security implications are insiginficant in most cases. Can you still reproduce this problem with the latest version of QEMU? As far as I know, the FPU emulation has been completely switched to softfloat with the latest versions, so I assume your problem might be fixed in recent releases... Hi, I just tried for about 2 hours without success or getting any useful diagnostic to compile and run current qemu 2.8. No console, no window opens, -curses does not work in .configure, despite ncurses-dev being installed, etc. Quite frankly, as I have not used qemu for several years now, I cannot be bothered to fight through an apparently mostly broken build and install process. I did include two diagnostic options in my bug-report, please try them out yourself. Regards, Arno On Thu, Jan 19, 2017 at 09:34:56 CET, Thomas Huth wrote: > Can you still reproduce this problem with the latest version of QEMU? As > far as I know, the FPU emulation has been completely switched to > softfloat with the latest versions, so I assume your problem might be > fixed in recent releases... > > ** Changed in: qemu > Status: New => Incomplete > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/645662 > > Title: > Python 3.1.2 math errors with Qemu 0.12.5 > > Status in QEMU: > Incomplete > > Bug description: > When doing the regression tests for Python 3.1.2 with Qemu 0.12.5, (Linux version 2.6.26-2-686 (Debian 2.6.26-25lenny1)), > gcc (Debian 4.3.2-1.1) 4.3.2, Python compiled from sources within qemu, > 3 math tests fail, apparently because the floating point unit is buggy. Qmeu was compiled from original sources > on Debian Lenny with kernel 2.6.34.6 from kernel.org, gcc (Debian 4.3.2-1.1) 4.3. > > Regression testing errors: > > test_cmath > test test_cmath failed -- Traceback (most recent call last): > File "/root/tools/python3/Python-3.1.2/Lib/test/test_cmath.py", line 364, in > self.fail(error_message) > AssertionError: acos0034: acos(complex(-1.0000000000000002, 0.0)) > Expected: complex(3.141592653589793, -2.1073424255447014e-08) > Received: complex(3.141592653589793, -2.1073424338879928e-08) > Received value insufficiently close to expected value. > > > test_float > test test_float failed -- Traceback (most recent call last): > File "/root/tools/python3/Python-3.1.2/Lib/test/test_float.py", line 479, in > self.assertEqual(s, repr(float(s))) > AssertionError: '8.72293771110361e+25' != '8.722937711103609e+25' > > > test_math > test test_math failed -- multiple errors occurred; run in verbose mode for deta > > => > > runtests.sh -v test_math > > le01:~/tools/python3/Python-3.1.2# ./runtests.sh -v test_math > test_math BAD > 1 BAD > 0 GOOD > 0 SKIPPED > 1 total > le01:~/tools/python3/Python-3.1.2# > > To manage notifications about this bug go to: > https://bugs.launchpad.net/qemu/+bug/645662/+subscriptions -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: