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?
