Am 19.12.2010 um 12:28 schrieb Blue Swirl:
On Sat, Dec 18, 2010 at 4:25 PM, Andreas Färber <andreas.faer...@web.de
> wrote:
The original SoftFloat 2.0b library avoided the use of custom
integer types
in its public headers. This requires the definitions of
int{8,16,32,64} to
match the assumptions in the declarations. This breaks on BeOS R5
and Haiku/x86,
where int32 is defined in {be,os}/support/SupportDefs.h in terms of
a long
rather than an int. Spotted by Michael Lotz.
Since QEMU already breaks this distinction by defining those types
just above,
do use them for consistency and to allow #ifndef'ing them out as
done for
[u]int16 on AIX.
Note that the BeOS/Haiku types are exact-width types though.
v3:
* Split off as intermediate step.
v2:
* Rebased.
Cc: Michael Lotz <m...@mlotz.ch>
Cc: Peter Maydell <peter.mayd...@linaro.org>
Signed-off-by: Andreas Färber <andreas.faer...@web.de>
---
fpu/softfloat.h | 68 ++++++++++++++++++++++++++
+---------------------------
1 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/fpu/softfloat.h b/fpu/softfloat.h
index 1c1004d..c62e769 100644
--- a/fpu/softfloat.h
+++ b/fpu/softfloat.h
@@ -221,25 +221,25 @@ void float_raise( int8 flags STATUS_PARAM);
/
*----------------------------------------------------------------------------
| Software IEC/IEEE integer-to-floating-point conversion routines.
*----------------------------------------------------------------------------*/
-float32 int32_to_float32( int STATUS_PARAM );
-float64 int32_to_float64( int STATUS_PARAM );
+float32 int32_to_float32( int32 STATUS_PARAM );
+float64 int32_to_float64( int32 STATUS_PARAM );
float32 uint32_to_float32( unsigned int STATUS_PARAM );
float64 uint32_to_float64( unsigned int STATUS_PARAM );
Shouldn't these use uint32 as well?
As requested by Peter, I took this intermediate step to really just
align declarations and implementations.
I manually compared the functions and some, including the recently
added int16 stuff, do use unsigned int in the implementation as well.
I have not converted uint32 yet, awaiting feedback on this series, so
that would go into a patch such as v3 7/7, doing the semantic change
separately for bisection.
Andreas