Re: [Qemu-devel] [PATCH v5 07/10] softfloat: Drop [u]int32 types in favor of [u]int_fast32_t

[Aurelien Jarno <aurelien@aurel32.net>]

On Tue, Mar 08, 2011 at 12:16:49AM +0100, Andreas Färber wrote:
> Am 07.03.2011 um 10:56 schrieb Aurelien Jarno:
> 
> >On Mon, Mar 07, 2011 at 01:34:10AM +0100, Andreas Färber wrote:
> >>v5:
> >>* Initial.
> >>
> >>Cc: Peter Maydell <peter.maydell@linaro.org>
> >>Signed-off-by: Andreas Färber <andreas.faerber@web.de>
> >>---
> >>fpu/softfloat.c |  132 ++++++++++++++++++++++++++
> >>+---------------------------
> >>fpu/softfloat.h |   34 +++++++--------
> >>2 files changed, 82 insertions(+), 84 deletions(-)
> 
> >>diff --git a/fpu/softfloat.h b/fpu/softfloat.h
> >>index c599cc2..4c64d77 100644
> >>--- a/fpu/softfloat.h
> >>+++ b/fpu/softfloat.h
> 
> >>@@ -394,10 +392,10 @@ INLINE float32 float32_set_sign(float32 a,
> >>int sign)
> >>*----------------------------------------------------------------------------*/
> >>int_fast16_t float64_to_int16_round_to_zero( float64 STATUS_PARAM );
> >>uint_fast16_t float64_to_uint16_round_to_zero( float64
> >>STATUS_PARAM );
> >>-int32 float64_to_int32( float64 STATUS_PARAM );
> >>-int32 float64_to_int32_round_to_zero( float64 STATUS_PARAM );
> >>-uint32 float64_to_uint32( float64 STATUS_PARAM );
> >>-uint32 float64_to_uint32_round_to_zero( float64 STATUS_PARAM );
> >>+int_fast32_t float64_to_int32( float64 STATUS_PARAM );
> >>+int_fast32_t float64_to_int32_round_to_zero( float64 STATUS_PARAM );
> >>+uint_fast32_t float64_to_uint32( float64 STATUS_PARAM );
> >>+uint_fast32_t float64_to_uint32_round_to_zero( float64
> >>STATUS_PARAM );
> >
> >If you do such a change in the declaration, you should do the same in
> >the code, otherwise it doesn't compile...
> 
> Hrm, are you saying this is missing in 08/10, or would you like to
> see that squashed into this one?
> It did compile at some point, at least before I reordered patches.
> 

You should not break bisect, so if you change the declaration in a
patch, you should also change the corresponding code in the same patch.

My guess is that you are using a 32-bit system, so int_fast32_t is the
same size as a int. On my system int_fast32_t is equivalent to int64_t
so it doesn't compile. That's why I don't think it's a good idea to use
fast types.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net