aboutsummaryrefslogtreecommitdiff
path: root/tests/tcg
AgeCommit message (Collapse)AuthorFilesLines
2020-10-14tests/tcg/linux-test: Adjust getsockname for muslRichard Henderson1-1/+1
Unlike glibc, musl does not use transparent unions to hide the different structures that overlap struct sockaddr. Add an explicit cast to work around this. Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2020-10-13Remove superfluous .gitignore filesThomas Huth1-5/+0
Since we are now always doing out-of-tree builds, these gitignore files should not be necessary anymore. Message-Id: <20200919133637.72744-1-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-09-30tests/tcg: reinstate or replace desired parts of rules.makPaolo Bonzini2-3/+14
Commit 660f79309303d696531ffb394719dfab3e0c42c0 was a bit overzealous with respect to tests/tcg, which needed quiet-command and $(BUILD_DIR). Reinstate quiet-command, and replace $(BUILD_DIR) with just the current directory. Reported-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-10plugins: move the more involved plugins to contribAlex Bennée1-2/+1
We have an exploding complexity problem in the testing so lets just move the more involved plugins into contrib. tests/plugins still exist for the basic plugins that exercise the API. We restore the old pre-meson style Makefile for contrib as it also doubles as a guide for out-of-tree plugin builds. While we are at it add some examples to the documentation and a specific plugins build target. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20200909112742.25730-11-alex.bennee@linaro.org>
2020-09-08Makefile: inline the relevant parts of rules.makPaolo Bonzini1-2/+0
Most of rules.mak is not used anymore, just inline what's needed. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-01tests/tcg: Do not require FE_* exception bitsRichard Henderson1-0/+17
Define anything that is missing as 0, so that flags & FE_FOO is false for any missing FOO. Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2020-09-01tests/tcg: Do not require FE_TOWARDZERORichard Henderson2-0/+4
This is optional in ISO C, and not all cpus provide it. Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2020-09-01tests/tcg: Add microblaze to arches filterRichard Henderson1-1/+1
Not attempting to use a single cross-compiler for both big-endian and little-endian at this time. Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2020-08-21tests/tcg/xtensa: add DFP0 arithmetic testsMax Filippov1-0/+162
Add test for basic double precision opcode properties. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2020-08-21tests/tcg/xtensa: test double precision load/storeMax Filippov1-0/+123
Add ldi[p]/sdi[p]/ldx[p]/sdx[p] opcode tests to test_lsc. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2020-08-21tests/tcg/xtensa: add fp0 div and sqrt testsMax Filippov2-0/+158
Test exact division/sqrt DFPU sequences. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2020-08-21tests/tcg/xtensa: update test_lsc for DFPUMax Filippov1-13/+34
DFPU doesn't have pre-increment FP load/store opcodes, it has post-increment opcodes instead. Test increment opcodes present in the current config. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2020-08-21tests/tcg/xtensa: update test_fp1 for DFPUMax Filippov1-28/+34
DFPU sets Invalid flag in FSR when at least one argument of FP comparison opcodes is NaN, SNaN for most opcodes, any NaN for olt/ole. Add checks for FSR and expected FSR values. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2020-08-21tests/tcg/xtensa: update test_fp0_conv for DFPUMax Filippov1-144/+155
DFPU conversion opcodes update FSR flags. Add FSR parameters and expected FSR register values for the conversion tests. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2020-08-21tests/tcg/xtensa: expand madd testsMax Filippov1-0/+104
Test that madd doesn't do rounding after multiplication. Test NaN propagation rules for FPU2000 and DFPU madd opcode. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2020-08-21tests/tcg/xtensa: update test_fp0_arith for DFPUMax Filippov2-97/+223
DFPU arithmetic opcodes update FSR flags. Add FSR parameters and expected FSR register values for the arithmetic tests. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2020-08-21tests/tcg/xtensa: fix test execution on ISSMax Filippov1-5/+5
Space for test results may be allocated in IRAM which is only word-accessible. Use full 32-bit words to access test results. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2020-08-21meson: link emulators without Makefile.targetPaolo Bonzini1-2/+2
The binaries move to the root directory, e.g. qemu-system-i386 or qemu-arm. This requires changes to qtests, CI, etc. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-08-03target/arm: Fix AddPAC error indicationRichard Henderson2-1/+34
The definition of top_bit used in this function is one higher than that used in the Arm ARM psuedo-code, which put the error indication at top_bit - 1 at the wrong place, which meant that it wasn't visible to Auth. Fixing the definition of top_bit requires more changes, because its most common use is for the count of bits in top_bit:bot_bit, which would then need to be computed as top_bit - bot_bit + 1. For now, prefer the minimal fix to the error indication alone. Fixes: 63ff0ca94cb Reported-by: Derrick McKee <derrick.mckee@gmail.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200728195706.11087-1-richard.henderson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: added comment about the divergence from the pseudocode] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-07-12Merge remote-tracking branch ↵Peter Maydell2-8/+17
'remotes/stsquad/tags/pull-testing-and-misc-110720-2' into staging Testing and misc build updates: - tests/vm support for aarch64 VMs - tests/tcg better cross-compiler detection - update docker tooling to support registries - update docker support for xtensa - gitlab build docker images and store in registry - gitlab use docker images for builds - a number of skipIf updates to support move - linux-user MAP_FIXED_NOREPLACE fix - qht-bench compiler tweaks - configure fix for secret keyring - tsan fiber annotation clean-up - doc updates for mttcg/icount/gdbstub - fix cirrus to use brew bash for iotests - revert virtio-gpu breakage - fix LC_ALL to avoid sorting changes in iotests # gpg: Signature made Sat 11 Jul 2020 15:56:42 BST # gpg: using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44 # gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.org>" [full] # Primary key fingerprint: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44 * remotes/stsquad/tags/pull-testing-and-misc-110720-2: (50 commits) iotests: Set LC_ALL=C for sort Revert "vga: build virtio-gpu as module" tests: fix "make check-qtest" for modular builds .cirrus.yml: add bash to the brew packages tests/docker: update toolchain set in debian-xtensa-cross tests/docker: fall back more gracefully when pull fails docs: Add to gdbstub documentation the PhyMemMode docs/devel: add some notes on tcg-icount for developers docs/devel: convert and update MTTCG design document tests/qht-bench: Adjust threshold computation tests/qht-bench: Adjust testing rate by -1 travis.yml: Test also the other targets on s390x shippable: pull images from registry instead of building testing: add check-build target containers.yml: build with docker.py tooling gitlab: limit re-builds of the containers tests: improve performance of device-introspect-test gitlab: add avocado asset caching gitlab: enable check-tcg for linux-user tests linux-user/elfload: use MAP_FIXED_NOREPLACE in pgb_reserved_va ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-07-11tests/docker: update toolchain set in debian-xtensa-crossMax Filippov1-1/+1
Switch to the prebuilt xtensa toolchains release 2020.07. Drop csp toolchain as the csp core is not a part of QEMU. Add de233_fpu and dsp3400 toolchains to enable DFPU and FPU2000 tests. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> [AJB: fix path in configure.sh] Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20200708082347.27318-1-jcmvbkbc@gmail.com> Message-Id: <20200709141327.14631-13-alex.bennee@linaro.org>
2020-07-11tests/tcg: add more default compilers to configure.shAlex Bennée1-5/+14
We were missing a bunch of compilers which we could use if they were locally installed. The defaults are based on Debian as they seem to be the best distro for well distributed cross-build compilers. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20200701135652.1366-32-alex.bennee@linaro.org>
2020-07-11tests/docker: change tag naming scheme of our imagesAlex Bennée1-2/+2
We've been misusing the tag naming scheme for some time by overloading the post : section with the image type. Really it should be saved for the revision of that particular build. Move the details to the other side so we have: qemu/image-name with the implied :latest version added by the tooling. Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200701135652.1366-18-alex.bennee@linaro.org>
2020-07-10target/i386: fix IEEE SSE floating-point exception raisingJoseph Myers2-0/+817
The SSE instruction implementations all fail to raise the expected IEEE floating-point exceptions because they do nothing to convert the exception state from the softfloat machinery into the exception flags in MXCSR. Fix this by adding such conversions. Unlike for x87, emulated SSE floating-point operations might be optimized using hardware floating point on the host, and so a different approach is taken that is compatible with such optimizations. The required invariant is that all exceptions set in env->sse_status (other than "denormal operand", for which the SSE semantics are different from those in the softfloat code) are ones that are set in the MXCSR; the emulated MXCSR is updated lazily when code reads MXCSR, while when code sets MXCSR, the exceptions in env->sse_status are set accordingly. A few instructions do not raise all the exceptions that would be raised by the softfloat code, and those instructions are made to save and restore the softfloat exception state accordingly. Nothing is done about "denormal operand"; setting that (only for the case when input denormals are *not* flushed to zero, the opposite of the logic in the softfloat code for such an exception) will require custom code for relevant instructions, or else architecture-specific conditionals in the softfloat code for when to set such an exception together with custom code for various SSE conversion and rounding instructions that do not set that exception. Nothing is done about trapping exceptions (for which there is minimal and largely broken support in QEMU's emulation in the x87 case and no support at all in the SSE case). Signed-off-by: Joseph Myers <joseph@codesourcery.com> Message-Id: <alpine.DEB.2.21.2006252358000.3832@digraph.polyomino.org.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-26target/i386: reimplement fpatan using floatx80 operationsJoseph Myers1-0/+1071
The x87 fpatan emulation is currently based around conversion to double. This is inherently unsuitable for a good emulation of any floatx80 operation. Reimplement using the soft-float operations, as for other such instructions. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Message-Id: <alpine.DEB.2.21.2006230000340.24721@digraph.polyomino.org.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-26target/i386: reimplement fyl2x using floatx80 operationsJoseph Myers1-0/+1161
The x87 fyl2x emulation is currently based around conversion to double. This is inherently unsuitable for a good emulation of any floatx80 operation. Reimplement using the soft-float operations, building on top of the reimplementation of fyl2xp1 and factoring out code to be shared between the two instructions. The included test assumes that the result in round-to-nearest mode should always be one of the two closest floating-point numbers to the mathematically exact result (including that it should be exact, in the exact cases which cover more cases than for fyl2xp1). Signed-off-by: Joseph Myers <joseph@codesourcery.com> Message-Id: <alpine.DEB.2.21.2006172321530.20587@digraph.polyomino.org.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-26target/i386: reimplement fyl2xp1 using floatx80 operationsJoseph Myers1-0/+1156
The x87 fyl2xp1 emulation is currently based around conversion to double. This is inherently unsuitable for a good emulation of any floatx80 operation, even before considering that it is a particularly naive implementation using double (adding 1 then using log rather than attempting a better emulation using log1p). Reimplement using the soft-float operations, as was done for f2xm1; as in that case, m68k has related operations but not exactly this one and it seemed safest to implement directly rather than reusing the m68k code to avoid accumulation of errors. A test is included with many randomly generated inputs. The assumption of the test is that the result in round-to-nearest mode should always be one of the two closest floating-point numbers to the mathematical value of y * log2(x + 1); the implementation aims to do somewhat better than that (about 70 correct bits before rounding). I haven't investigated how accurate hardware is. Intel manuals describe a narrower range of valid arguments to this instruction than AMD manuals. The implementation accepts the wider range (it's needed anyway for the core code to be reusable in a subsequent patch reimplementing fyl2x), but the test only has inputs in the narrower range so that it's valid on hardware that may reject or produce poor results for inputs outside that range. Code in the previous implementation that sets C2 for some out-of-range arguments is not carried forward to the new implementation; C2 is undefined for this instruction and I suspect that code was just cut-and-pasted from the trigonometric instructions (fcos, fptan, fsin, fsincos) where C2 *is* defined to be set for out-of-range arguments. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Message-Id: <alpine.DEB.2.21.2006172320190.20587@digraph.polyomino.org.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-26target/i386: reimplement f2xm1 using floatx80 operationsJoseph Myers1-0/+1140
The x87 f2xm1 emulation is currently based around conversion to double. This is inherently unsuitable for a good emulation of any floatx80 operation, even before considering that it is a particularly naive implementation using double (computing with pow and then subtracting 1 rather than attempting a better emulation using expm1). Reimplement using the soft-float operations, including additions and multiplications with higher precision where appropriate to limit accumulation of errors. I considered reusing some of the m68k code for transcendental operations, but the instructions don't generally correspond exactly to x87 operations (for example, m68k has 2^x and e^x - 1, but not 2^x - 1); to avoid possible accumulation of errors from applying multiple such operations each rounding to floatx80 precision, I wrote a direct implementation of 2^x - 1 instead. It would be possible in principle to make the implementation more efficient by doing the intermediate operations directly with significands, signs and exponents and not packing / unpacking floatx80 format for each operation, but that would make it significantly more complicated and it's not clear that's worthwhile; the m68k emulation doesn't try to do that. A test is included with many randomly generated inputs. The assumption of the test is that the result in round-to-nearest mode should always be one of the two closest floating-point numbers to the mathematical value of 2^x - 1; the implementation aims to do somewhat better than that (about 70 correct bits before rounding). I haven't investigated how accurate hardware is. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Message-Id: <alpine.DEB.2.21.2006112341010.18393@digraph.polyomino.org.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-16plugins: new lockstep plugin for debugging TCG changesAlex Bennée1-1/+2
When we make changes to the TCG we sometimes cause regressions that are deep into the execution cycle of the guest. Debugging this often requires comparing large volumes of trace information to figure out where behaviour has diverged. The lockstep plugin utilises a shared socket so two QEMU's running with the plugin will write their current execution position and wait to receive the position of their partner process. When execution diverges the plugins output where they were and the previous few blocks before unloading themselves and letting execution continue. Originally I planned for this to be most useful with -icount but it turns out you can get divergence pretty quickly due to asynchronous qemu_cpu_kick_rr_cpus() events causing one side to eventually run into a short block a few cycles before the other side. For this reason I've added a bit of tracking and I think the divergence reporting could be finessed to report only if we really start to diverge in execution. An example run would be: qemu-system-sparc -monitor none -parallel none -net none \ -M SS-20 -m 256 -kernel day11/zImage.elf \ -plugin ./tests/plugin/liblockstep.so,arg=lockstep-sparc.sock \ -d plugin,nochain with an identical command in another window in the same working directory. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Robert Foley <robert.foley@linaro.org> Tested-by: Robert Foley <robert.foley@linaro.org> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-Id: <20200610155509.12850-3-alex.bennee@linaro.org>
2020-06-16tests/tcg: ensure -cpu max also used for plugin runAlex Bennée2-1/+3
The check-tcg plugins build was failing because some special case tests that needed -cpu max failed because the plugin variant hadn't carried across the QEMU_OPTS tweak. Guests which globally set QEMU_OPTS=-cpu FOO where unaffected. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20200615141922.18829-3-alex.bennee@linaro.org>
2020-06-16tests/tcg: build plugin list from contents of src directoryAlex Bennée3-7/+8
If you jump back and forth between branches while developing plugins you end up debugging failures caused by plugins left in the build directory. Fix this by basing plugins on the source tree instead. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20200615141922.18829-2-alex.bennee@linaro.org>
2020-06-12Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into stagingPeter Maydell9-0/+1677
* Miscellaneous fixes and feature enablement (many) * SEV refactoring (David) * Hyper-V initial support (Jon) * i386 TCG fixes (x87 and SSE, Joseph) * vmport cleanup and improvements (Philippe, Liran) * Use-after-free with vCPU hot-unplug (Nengyuan) * run-coverity-scan improvements (myself) * Record/replay fixes (Pavel) * -machine kernel_irqchip=split improvements for INTx (Peter) * Code cleanups (Philippe) * Crash and security fixes (PJP) * HVF cleanups (Roman) # gpg: Signature made Fri 12 Jun 2020 16:57:04 BST # gpg: using RSA key F13338574B662389866C7682BFFBD25F78C7AE83 # gpg: issuer "pbonzini@redhat.com" # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full] # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full] # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini/tags/for-upstream: (116 commits) target/i386: Remove obsolete TODO file stubs: move Xen stubs to accel/ replay: fix replay shutdown for console mode exec/cpu-common: Move MUSB specific typedefs to 'hw/usb/hcd-musb.h' hw/usb: Move device-specific declarations to new 'hcd-musb.h' header exec/memory: Remove unused MemoryRegionMmio type checkpatch: reversed logic with acpi test checks target/i386: sev: Unify SEVState and SevGuestState target/i386: sev: Remove redundant handle field target/i386: sev: Remove redundant policy field target/i386: sev: Remove redundant cbitpos and reduced_phys_bits fields target/i386: sev: Partial cleanup to sev_state global target/i386: sev: Embed SEVState in SevGuestState target/i386: sev: Rename QSevGuestInfo target/i386: sev: Move local structure definitions into .c file target/i386: sev: Remove unused QSevGuestInfoClass xen: fix build without pci passthrough i386: hvf: Drop HVFX86EmulatorState i386: hvf: Move mmio_buf into CPUX86State i386: hvf: Move lazy_flags into CPUX86State ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org> # Conflicts: # hw/i386/acpi-build.c
2020-06-12target/i386: correct fix for pcmpxstrx substring searchJoseph Myers2-0/+36
This corrects a bug introduced in my previous fix for SSE4.2 pcmpestri / pcmpestrm / pcmpistri / pcmpistrm substring search, commit ae35eea7e4a9f21dd147406dfbcd0c4c6aaf2a60. That commit fixed a bug that showed up in four GCC tests with one libc implementation. The tests in question generate random inputs to the intrinsics and compare results to a C implementation, but they only test 1024 possible random inputs, and when the tests use the cases of those instructions that work with word rather than byte inputs, it's easy to have problematic cases that show up much less frequently than that. Thus, testing with a different libc implementation, and so a different random number generator, showed up a problem with the previous patch. When investigating the previous test failures, I found the description of these instructions in the Intel manuals (starting from computing a 16x16 or 8x8 set of comparison results) confusing and hard to match up with the more optimized implementation in QEMU, and referred to AMD manuals which described the instructions in a different way. Those AMD descriptions are very explicit that the whole of the string being searched for must be found in the other operand, not running off the end of that operand; they say "If the prototype and the SUT are equal in length, the two strings must be identical for the comparison to be TRUE.". However, that statement is incorrect. In my previous commit message, I noted: The operation in this case is a search for a string (argument d to the helper) in another string (argument s to the helper); if a copy of d at a particular position would run off the end of s, the resulting output bit should be 0 whether or not the strings match in the region where they overlap, but the QEMU implementation was wrongly comparing only up to the point where s ends and counting it as a match if an initial segment of d matched a terminal segment of s. Here, "run off the end of s" means that some byte of d would overlap some byte outside of s; thus, if d has zero length, it is considered to match everywhere, including after the end of s. The description "some byte of d would overlap some byte outside of s" is accurate only when understood to refer to overlapping some byte *within the 16-byte operand* but at or after the zero terminator; it is valid to run over the end of s if the end of s is the end of the 16-byte operand. So the fix in the previous patch for the case of d being empty was correct, but the other part of that patch was not correct (as it never allowed partial matches even at the end of the 16-byte operand). Nor was the code before the previous patch correct for the case of d nonempty, as it would always have allowed partial matches at the end of s. Fix with a partial revert of my previous change, combined with inserting a check for the special case of s having maximum length to determine where it is necessary to check for matches. In the added test, test 1 is for the case of empty strings, which failed before my 2017 patch, test 2 is for the bug introduced by my 2017 patch and test 3 deals with the case where a match of an initial segment at the end of the string is not valid when the string ends before the end of the 16-byte operand (that is, the case that would be broken by a simple revert of the non-empty-string part of my 2017 patch). Signed-off-by: Joseph Myers <joseph@codesourcery.com> Message-Id: <alpine.DEB.2.21.2006121344290.9881@digraph.polyomino.org.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-10target/i386: fix IEEE x87 floating-point exception raisingJoseph Myers1-0/+831
Most x87 instruction implementations fail to raise the expected IEEE floating-point exceptions because they do nothing to convert the exception state from the softfloat machinery into the exception flags in the x87 status word. There is special-case handling of division to raise the divide-by-zero exception, but that handling is itself buggy: it raises the exception in inappropriate cases (inf / 0 and nan / 0, which should not raise any exceptions, and 0 / 0, which should raise "invalid" instead). Fix this by converting the floating-point exceptions raised during an operation by the softfloat machinery into exceptions in the x87 status word (passing through the existing fpu_set_exception function for handling related to trapping exceptions). There are special cases where some functions convert to integer internally but exceptions from that conversion are not always correct exceptions for the instruction to raise. There might be scope for some simplification if the softfloat exception state either could always be assumed to be in sync with the state in the status word, or could always be ignored at the start of each instruction and just set to 0 then; I haven't looked into that in detail, and it might run into interactions with the various ways the emulation does not yet handle trapping exceptions properly. I think the approach taken here, of saving the softfloat state, setting exceptions there to 0 and then merging the old exceptions back in after carrying out the operation, is conservatively safe. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Message-Id: <alpine.DEB.2.21.2005152120280.3469@digraph.polyomino.org.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-10target/i386: fix fisttpl, fisttpll handling of out-of-range valuesJoseph Myers1-0/+100
The fist / fistt family of instructions should all store the most negative integer in the destination format when the rounded / truncated integer result is out of range or the input is an invalid encoding, infinity or NaN. The fisttpl and fisttpll implementations (32-bit and 64-bit results, truncate towards zero) failed to do this, producing the most positive integer in some cases instead. Fix this by copying the code used to handle this issue for fistpl and fistpll, adjusted to use the _round_to_zero functions for the actual conversion (but without any other changes to that code). Signed-off-by: Joseph Myers <joseph@codesourcery.com> Message-Id: <alpine.DEB.2.21.2005152119160.3469@digraph.polyomino.org.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-10target/i386: fix fbstp handling of out-of-range valuesJoseph Myers1-0/+115
The fbstp implementation fails to check for out-of-range and invalid values, instead just taking the result of conversion to int64_t and storing its sign and low 18 decimal digits. Fix this by checking for an out-of-range result (invalid conversions always result in INT64_MAX or INT64_MIN from the softfloat code, which are large enough to be considered as out-of-range by this code) and storing the packed BCD indefinite encoding in that case. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Message-Id: <alpine.DEB.2.21.2005132351110.11687@digraph.polyomino.org.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-10target/i386: fix fbstp handling of negative zeroJoseph Myers1-0/+25
The fbstp implementation stores +0 when the rounded result should be -0 because it compares an integer value with 0 to determine the sign. Fix this by checking the sign bit of the operand instead. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Message-Id: <alpine.DEB.2.21.2005132350230.11687@digraph.polyomino.org.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-10target/i386: fix fxam handling of invalid encodingsJoseph Myers1-0/+143
The fxam implementation does not check for invalid encodings, instead treating them like NaN or normal numbers depending on the exponent. Fix it to check that the high bit of the significand is set before treating an encoding as NaN or normal, thus resulting in correct handling (all of C0, C2 and C3 cleared) for invalid encodings. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Message-Id: <alpine.DEB.2.21.2005132349311.11687@digraph.polyomino.org.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-10target/i386: fix floating-point load-constant roundingJoseph Myers1-0/+199
The implementations of the fldl2t, fldl2e, fldpi, fldlg2 and fldln2 instructions load fixed constants independent of the rounding mode. Fix them to load a value correctly rounded for the current rounding mode (but always rounded to 64-bit precision independent of the precision control, and without setting "inexact") as specified. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <alpine.DEB.2.21.2005132348310.11687@digraph.polyomino.org.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-10target/i386: fix fscale handling of rounding precisionJoseph Myers1-0/+13
The fscale implementation uses floatx80_scalbn for the final scaling operation. floatx80_scalbn ends up rounding the result using the dynamic rounding precision configured for the FPU. But only a limited set of x87 floating-point instructions are supposed to respect the dynamic rounding precision, and fscale is not in that set. Fix the implementation to save and restore the rounding precision around the call to floatx80_scalbn. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Message-Id: <alpine.DEB.2.21.2005070045430.18350@digraph.polyomino.org.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-10target/i386: fix fscale handling of infinite exponentsJoseph Myers1-0/+29
The fscale implementation passes infinite exponents through to generic code that rounds the exponent to a 32-bit integer before using floatx80_scalbn. In round-to-nearest mode, and ignoring exceptions, this works in many cases. But it fails to handle the special cases of scaling 0 by a +Inf exponent or an infinity by a -Inf exponent, which should produce a NaN, and because it produces an inexact result for finite nonzero numbers being scaled, the result is sometimes incorrect in other rounding modes. Add appropriate handling of infinite exponents to produce a NaN or an appropriately signed exact zero or infinity as a result. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Message-Id: <alpine.DEB.2.21.2005070045010.18350@digraph.polyomino.org.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-10target/i386: fix fscale handling of invalid exponent encodingsJoseph Myers1-0/+29
The fscale implementation does not check for invalid encodings in the exponent operand, thus treating them like INT_MIN (the value returned for invalid encodings by floatx80_to_int32_round_to_zero). Fix it to treat them similarly to signaling NaN exponents, thus generating a quiet NaN result. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Message-Id: <alpine.DEB.2.21.2005070044190.18350@digraph.polyomino.org.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-10target/i386: fix fscale handling of signaling NaNJoseph Myers1-0/+37
The implementation of the fscale instruction returns a NaN exponent unchanged. Fix it to return a quiet NaN when the provided exponent is a signaling NaN. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Message-Id: <alpine.DEB.2.21.2005070043330.18350@digraph.polyomino.org.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-10target/i386: implement special cases for fxtractJoseph Myers1-0/+120
The implementation of the fxtract instruction treats all nonzero operands as normal numbers, so yielding incorrect results for invalid formats, infinities, NaNs and subnormal and pseudo-denormal operands. Implement appropriate handling of all those cases. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Acked-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <alpine.DEB.2.21.2005070042360.18350@digraph.polyomino.org.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-08tests/tcg: add simple commpage test caseAlex Bennée2-0/+63
The COMMPAGE are a number of kernel provided user-space routines for 32 bit ARM systems. Add a basic series of smoke tests to ensure it is working as it should. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200605154929.26910-14-alex.bennee@linaro.org>
2020-05-27tests/tcg: add new threadcount testAlex Bennée2-0/+66
Based on the original testcase by Nikolay Igotti. Message-ID: <CAEme+7GLKg_dNsHizzTKDymX9HyD+Ph2iZ=WKhOw2XG+zhViXg@mail.gmail.com> Signed-off-by: Nikolay Igotti <igotti@gmail.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20200520140541.30256-15-alex.bennee@linaro.org>
2020-05-27tests/docker: use a gcc-10 based image for arm64 testsAlex Bennée1-2/+2
As we enable newer features that we want to test on arm64 targets we need newer compilers. Split off a new debian-arm64-test-cross image which we can use to build these new tests. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200520140541.30256-11-alex.bennee@linaro.org>
2020-05-27tests/tcg: better detect confused gdb which can't connectAlex Bennée1-0/+4
While we may gamely give the right information it can still confuse the wide range of GDBs out there. For example ppc64abi32-linux-user reports: warning: Selected architecture powerpc:common is not compatible with reported target architecture powerpc:common64 warning: Architecture rejected target-supplied description but still connects. Add a test for a 0 pc and exit early if that is the case. This may actually be a bug we need to fix? Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200520140541.30256-8-alex.bennee@linaro.org>
2020-05-27tests/tcg: fix invocation of the memory record/replay testsAlex Bennée1-1/+1
I'm not sure when this broke but we should use EXTRA_RUNS for "virtual" tests which are not generated from the binary names. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200520140541.30256-5-alex.bennee@linaro.org>
2020-05-15softfloat: fix floatx80 pseudo-denormal round to integerJoseph Myers1-0/+10
The softfloat function floatx80_round_to_int incorrectly handles the case of a pseudo-denormal where only the high bit of the significand is set, ignoring that bit (treating the number as an exact zero) rather than treating the number as an alternative representation of +/- 2^-16382 (which may round to +/- 1 depending on the rounding mode) as hardware does. Fix this check (simplifying the code in the process). Signed-off-by: Joseph Myers <joseph@codesourcery.com> Message-Id: <alpine.DEB.2.21.2005042339420.22972@digraph.polyomino.org.uk> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
generated by cgit v1.1 at 2024-08-22 13:26:58 +0000