From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57359) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RmrO4-0005zs-RE for qemu-devel@nongnu.org; Mon, 16 Jan 2012 13:34:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RmrO0-0005KI-OK for qemu-devel@nongnu.org; Mon, 16 Jan 2012 13:34:32 -0500 Received: from mnementh.archaic.org.uk ([81.2.115.146]:39838) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RmrO0-0005JZ-EB for qemu-devel@nongnu.org; Mon, 16 Jan 2012 13:34:28 -0500 From: Peter Maydell Date: Mon, 16 Jan 2012 18:34:15 +0000 Message-Id: <1326738858-19992-1-git-send-email-peter.maydell@linaro.org> Subject: [Qemu-devel] [PATCH 0/3] softfloat/arm: fix 'int32 is 32 bits' assumptions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: =?UTF-8?q?Andreas=20F=C3=A4rber?= , patches@linaro.org These patches fix some assumptions that are made by various bits of code that the softfloat 'int32' and 'uint32' types are exactly 32 bits rather than at least 32 bits. I found these issues as part of testing Andreas' recent softfloat type fixes patchset. What I did was to take the first four patches from Andreas' set (the fixes for type mixups) and then do a test run of my ARM VFP/Neon tests with the following two sets of typedefs: /* maximum-width versions */ typedef uint64_t flag; typedef uint64_t uint8; typedef int64_t int8; typedef uint64_t uint16; typedef int64_t int16; typedef uint64_t uint32; typedef int64_t int32; typedef uint64_t uint64; typedef int64_t int64; /* minimum-width versions */ typedef uint8_t flag; typedef uint8_t uint8; typedef int8_t int8; typedef uint16_t uint16; typedef int16_t int16; typedef uint32_t uint32; typedef int32_t int32; typedef uint64_t uint64; typedef int64_t int64; to flush out the two obvious possible problems: code which assumes the type is larger than it might be, and code which assumes the type is not as large as it might be. These test runs revealed a few bugs, which this patchseries fixes. These are basically all assumptions about the size of int32 in float-to-int or int-to-float code, and represent real rather than theoretical problems with the switch to int_fast*_t since on 64 bit hosts int_fast32_t is typically 64 bits. NB: I think I've fairly solidly exercised the bits of softfloat that ARM uses, but can't guarantee coverage of anything that's only used by other targets or target-specific non-ARM code. Andreas: these sit after your patches 1-4, so it might be easiest if you just stick them in your patch series; like your 1-4 they can be applied now as they make sense even without the type conversion patches. Peter Maydell (3): target-arm/helper.c: Don't assume softfloat int32 is 32 bits only softfloat: float*_to_int32_round_to_zero: don't assume int32 is 32 bits softfloat: roundAndPackInt{32,64}: Don't assume int32 is 32 bits fpu/softfloat.c | 12 ++++++------ target-arm/helper.c | 2 +- 2 files changed, 7 insertions(+), 7 deletions(-)