I have filed a broader ticket, Bug #1888918, reporting a very similar issue that leads to corruption/bad arithmetic when using double- precision & vector instructions.
I will be submitting a patch in the next few days that will also address this ticket. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1611394 Title: qemu-ppc: Scalar Single-Precision Floating-Point instructions should not test MSR[SPV] Status in QEMU: New Bug description: According to "Signal Processing Engine (SPE) Programming Environments Manual" at http://cache.nxp.com/files/32bit/doc/ref_manual/SPEPEM.pdf?fsrch=1&sr=1&pageNum=1 c.f section 4.2.3 and also Figure 2-2. When MSR[SPV] is _NOT_ set, then the embedded scalar single-precision floating-point instructions should _NOT_ generate an Embedded Floating-Point Unavailable Interrupt. Hence, some tests for MSR[SPV] in file target-ppc/translate.c need to be removed. Namely, in the definitions of 1. GEN_SPEFPUOP_ARITH2_32_32 2. gen_efsabs 3. gen_efsnabs 4. gen_efsneg 5. GEN_SPEFPUOP_COMP_32 Note, the macro GEN_SPEFPUOP_CONV_32_32 is already correct. One more thing, afaict the macro GEN_SPEFPUOP_CONV_32_64 is used by both efs- and efd- instructions, and will need to be split in two versions. The efs-use (i.e for efscfd) should be as it is today, but the use by efd-instructions (e.g efdctui) will need to add a test for MSR[SPV]. (I've looked at today's HEAD-revision of target-ppc/translate.c). To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1611394/+subscriptions
