Patchwork [V2] softfloat: Rename float*_is_nan() functions to float*_is_quiet_nan()

login
register
mail settings
Submitter Peter Maydell
Date Dec. 17, 2010, 3:56 p.m.
Message ID <1292601366-990-1-git-send-email-peter.maydell@linaro.org>
Download mbox | patch
Permalink /patch/75917/
State New
Headers show

Comments

Peter Maydell - Dec. 17, 2010, 3:56 p.m.
The softfloat functions float*_is_nan() were badly misnamed,
because they return true only for quiet NaNs, not for all NaNs.
Rename them to float*_is_quiet_nan() to more accurately reflect
what they do.

This change was produced by:
 perl -p -i -e 's/_is_nan/_is_quiet_nan/g' $(git grep -l is_nan)
(with the results manually checked.)

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Nathan Froyd <froydnj@codesourcery.com>
Acked-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
---
This is just a refresh of the first patch against current master;
the only difference is that the addition of float32_maybe_silence_nan()
meant that the context for the hunk in softfloat.h changing the
prototypes is slightly different. I've therefore retained the
reviewed-by/acked-by lines from the first time around.

Can this patch be applied? (There are more ARM/softfloat patches
in my queue which will break it again otherwise...)

 fpu/softfloat-native.c            |    6 ++--
 fpu/softfloat-native.h            |    6 ++--
 fpu/softfloat-specialize.h        |   24 +++++++-------
 fpu/softfloat.h                   |    8 ++--
 linux-user/arm/nwfpe/fpa11_cprt.c |   14 ++++----
 target-alpha/op_helper.c          |    2 +-
 target-m68k/helper.c              |    6 ++--
 target-microblaze/op_helper.c     |    2 +-
 target-mips/op_helper.c           |    8 ++--
 target-ppc/op_helper.c            |   58 ++++++++++++++++++------------------
 10 files changed, 67 insertions(+), 67 deletions(-)
Andreas Färber - Dec. 17, 2010, 4:19 p.m.
Hello Peter,

Am 17.12.2010 um 16:56 schrieb Peter Maydell:

> The softfloat functions float*_is_nan() were badly misnamed,
> because they return true only for quiet NaNs, not for all NaNs.
> Rename them to float*_is_quiet_nan() to more accurately reflect
> what they do.
>
> This change was produced by:
> perl -p -i -e 's/_is_nan/_is_quiet_nan/g' $(git grep -l is_nan)
> (with the results manually checked.)
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> Reviewed-by: Nathan Froyd <froydnj@codesourcery.com>
> Acked-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
> ---
> This is just a refresh of the first patch against current master;
> the only difference is that the addition of  
> float32_maybe_silence_nan()
> meant that the context for the hunk in softfloat.h changing the
> prototypes is slightly different. I've therefore retained the
> reviewed-by/acked-by lines from the first time around.
>
> Can this patch be applied? (There are more ARM/softfloat patches
> in my queue which will break it again otherwise...)

If we're engaging into refactoring the softfloat library, I still have  
a large'ish patch lying around to fix signature mismatches between  
header and sources wrt to integer arguments and migrating to POSIX  
integer types (BeOS/Haiku system headers define int32 etc.  
differently). Browsing through your patch it shouldn't conflict, but I  
guess it'll be best to have it go through your queue to avoid troubles.

Regards,
Andreas
Peter Maydell - Dec. 17, 2010, 4:48 p.m.
On 17 December 2010 16:19, Andreas Färber <andreas.faerber@web.de> wrote:
>> Can this patch be applied? (There are more ARM/softfloat patches
>> in my queue which will break it again otherwise...)
>
> If we're engaging into refactoring the softfloat library, I still have a
> large'ish patch lying around to fix signature mismatches between header and
> sources wrt to integer arguments and migrating to POSIX integer types
> (BeOS/Haiku system headers define int32 etc. differently). Browsing through
> your patch it shouldn't conflict, but I guess it'll be best to have it go
> through your queue to avoid troubles.

I wasn't planning to put this patch into my "ARM fixes" queue to be
pulled directly, because it's a bit wider in scope than fixing things
for ARM targets. (Hence the "can this be applied?" request :-))

On the types issue, at the moment softfloat uses "int32" etc for
"a handy type holding at least 32 bits", and "bits32" for "exactly
32 bits". So I guess changing the 'bits' types to the POSIX int32_t
and friends would be straightforward enough, but what does your
patch do with the int32 types?

-- PMM
Andreas Färber - Dec. 17, 2010, 5:54 p.m.
Am 17.12.2010 um 17:48 schrieb Peter Maydell:

> On 17 December 2010 16:19, Andreas Färber <andreas.faerber@web.de>  
> wrote:
>>> Can this patch be applied? (There are more ARM/softfloat patches
>>> in my queue which will break it again otherwise...)
>>
>> If we're engaging into refactoring the softfloat library, I still  
>> have a
>> large'ish patch lying around to fix signature mismatches between  
>> header and
>> sources wrt to integer arguments and migrating to POSIX integer types
>> (BeOS/Haiku system headers define int32 etc. differently). Browsing  
>> through
>> your patch it shouldn't conflict, but I guess it'll be best to have  
>> it go
>> through your queue to avoid troubles.
>
> I wasn't planning to put this patch into my "ARM fixes" queue to be
> pulled directly, because it's a bit wider in scope than fixing things
> for ARM targets. (Hence the "can this be applied?" request :-))
>
> On the types issue, at the moment softfloat uses "int32" etc for
> "a handy type holding at least 32 bits", and "bits32" for "exactly
> 32 bits". So I guess changing the 'bits' types to the POSIX int32_t
> and friends would be straightforward enough, but what does your
> patch do with the int32 types?

My patch does not touch the bits* types. I didn't notice any problem  
there.

I replaced int32 by int32_t, int64 by int64_t etc. No sane code puts  
more than 32 bits into an "int32" variable, and my guests on OSX/ppc64  
host still appeared to work. I don't have arm guests though so please  
check on your side.

There's int_least*_t in case we really need it:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdint.h.html

Andreas
Peter Maydell - Dec. 17, 2010, 11:32 p.m.
On 17 December 2010 17:54, Andreas Färber <andreas.faerber@web.de> wrote:
> Am 17.12.2010 um 17:48 schrieb Peter Maydell:
>> On the types issue, at the moment softfloat uses "int32" etc for
>> "a handy type holding at least 32 bits", and "bits32" for "exactly
>> 32 bits". So I guess changing the 'bits' types to the POSIX int32_t
>> and friends would be straightforward enough, but what does your
>> patch do with the int32 types?
>
> My patch does not touch the bits* types. I didn't notice any problem there.
>
> I replaced int32 by int32_t, int64 by int64_t etc. No sane code puts more
> than 32 bits into an "int32" variable, and my guests on OSX/ppc64 host still
> appeared to work. I don't have arm guests though so please check on your
> side.

Hrm. That introduces potential semantic changes, so I'm a bit wary
of it (and my test suite is not currently comprehensive enough to be
sure of covering all of softfloat)... I'd be happier if we just renamed
the int32 & friends to some other non-clashing name, if all we're
trying to solve is a name clash issue.

-- PMM
Nathan Froyd - Dec. 18, 2010, 2:30 a.m.
On Fri, Dec 17, 2010 at 11:32:03PM +0000, Peter Maydell wrote:
> On 17 December 2010 17:54, Andreas Färber <andreas.faerber@web.de> wrote:
> > My patch does not touch the bits* types. I didn't notice any problem there.
> >
> > I replaced int32 by int32_t, int64 by int64_t etc. No sane code puts more
> > than 32 bits into an "int32" variable, and my guests on OSX/ppc64 host still
> > appeared to work. I don't have arm guests though so please check on your
> > side.
> 
> Hrm. That introduces potential semantic changes, so I'm a bit wary
> of it (and my test suite is not currently comprehensive enough to be
> sure of covering all of softfloat)... I'd be happier if we just renamed
> the int32 & friends to some other non-clashing name, if all we're
> trying to solve is a name clash issue.

I wouldn't be too worried:

typedef uint8_t flag;
typedef uint8_t uint8;
typedef int8_t int8;
typedef int uint16;
typedef int int16;
typedef unsigned int uint32;
typedef signed int int32;
typedef uint64_t uint64;
typedef int64_t int64;

So adding _t suffixes in appropriate places should be a no-op, except
for uint16/int16--and those types are never used.

-Nathan
Peter Maydell - Dec. 18, 2010, 10:39 a.m.
On 18 December 2010 02:30, Nathan Froyd <froydnj@codesourcery.com> wrote:
> I wouldn't be too worried:
>
> typedef uint8_t flag;
> typedef uint8_t uint8;
> typedef int8_t int8;
> typedef int uint16;
> typedef int int16;
> typedef unsigned int uint32;
> typedef signed int int32;
> typedef uint64_t uint64;
> typedef int64_t int64;
>
> So adding _t suffixes in appropriate places should be a no-op, except
> for uint16/int16--and those types are never used.

Eh? If you comment out the int16 typedef you'll find softfloat.c
doesn't compile because of all the places it's used... (uint16
isn't used, though.) A lot of the int16 uses are things like shift counts
which should probably go to plain old 'int' rather than 'int16_t'.

Also, are we sure we want to throw away the current information
in the code about the distinction between "I need at least X bits"
and "I need exactly X bits" ?

-- PMM
Andreas Färber - Dec. 18, 2010, 11:49 a.m.
Am 18.12.2010 um 11:39 schrieb Peter Maydell:

> On 18 December 2010 02:30, Nathan Froyd <froydnj@codesourcery.com>  
> wrote:
>> I wouldn't be too worried:
>>
>> typedef uint8_t flag;
>> typedef uint8_t uint8;
>> typedef int8_t int8;
>> typedef int uint16;
>> typedef int int16;
>> typedef unsigned int uint32;
>> typedef signed int int32;
>> typedef uint64_t uint64;
>> typedef int64_t int64;
>>
>> So adding _t suffixes in appropriate places should be a no-op, except
>> for uint16/int16--and those types are never used.
>
> Eh? If you comment out the int16 typedef you'll find softfloat.c
> doesn't compile because of all the places it's used... (uint16
> isn't used, though.) A lot of the int16 uses are things like shift  
> counts
> which should probably go to plain old 'int' rather than 'int16_t'.
>
> Also, are we sure we want to throw away the current information
> in the code about the distinction between "I need at least X bits"
> and "I need exactly X bits" ?

IMO a lot of code in QEMU is cryptic because someone thinks that  
someone else must've thought something particular when doing it that  
way and is thus reluctant to touch it...

For a fact, [u]int8 und [u]int64 remain unchanged width-wise.
For [u]int16, only malc may know what that maps to on AIX, for which  
they are #ifndef'ed out. I doubt it's an int.
Unless there's an ILP64 platform we support, [u]int32 would stay the  
same width, too.
That's why I was saying, putting, e.g., a 33rd bit into int32 has  
undefined semantics, just as for the POSIX int_least32_t type. I don't  
see a win in declaring that information.

My patch tries to do three things in one:
1.) Fix mismatches between headers and sources, i.e. float32  
int32_to_float32(int); vs. float32 int32_to_float32(int32) {...} etc.
2.) Drop the unnecessary custom integer types in favor of standard ones.
3.) Fix instances of lazyness where _t was forgotten and the mistake  
was hidden by the softfloat typedefs.

Renaming int32 to qint32 would defeat the second purpose. I got around  
the Haiku issue for now, so that's not a pressing need.

Had the softfloat code not been a real refactoring-unfriendly mess of  
int, int* and int*_t, I would've offered to do this in multiple steps  
per type. I could try splitting out part 1 above. Part 3 can easily be  
split off by cut-and-paste and could be applied independently.

Promoting int16[_t] to int for things like shift counts is beyond the  
scope of my patch.

Andreas
Peter Maydell - Dec. 18, 2010, 12:15 p.m.
On 18 December 2010 11:49, Andreas Färber <andreas.faerber@web.de> wrote:
> IMO a lot of code in QEMU is cryptic because someone thinks that someone
> else must've thought something particular when doing it that way and is thus
> reluctant to touch it...

> For a fact, [u]int8 und [u]int64 remain unchanged width-wise.
> For [u]int16, only malc may know what that maps to on AIX, for which they
> are #ifndef'ed out. I doubt it's an int.
> Unless there's an ILP64 platform we support, [u]int32 would stay the same
> width, too.
> That's why I was saying, putting, e.g., a 33rd bit into int32 has undefined
> semantics, just as for the POSIX int_least32_t type. I don't see a win in
> declaring that information.

It's saying "it's OK to provide more than 32 bits if that would be faster",
and indeed that's exactly how we typedef it. Some parts of softfloat
that use bits32 do rely on there being exactly 32 bits and not 64.

> My patch tries to do three things in one:

> 1.) Fix mismatches between headers and sources, i.e. float32
> int32_to_float32(int); vs. float32 int32_to_float32(int32) {...} etc.

In this case we do know the rationale for this mismatch:
http://www.jhauser.us/arithmetic/SoftFloat-2b/SoftFloat-source.txt
---begin---
Unlike the actual function definitions in `softfloat.c', the declarations
in `softfloat.h' do not use any of the types defined by the `processors'
header file.  This is done so that clients will not have to include the
`processors' header file in order to use SoftFloat.  Nevertheless, the
target-specific declarations in `softfloat.h' must match what `softfloat.c'
expects.  For example, if `int32' is defined as `int' in the `processors'
header file, then in `softfloat.h' the output of `float32_to_int32' should
be stated as `int', although in `softfloat.c' it is given in target-
independent form as `int32'.
---endit---

...which doesn't really apply to the way qemu has taken softfloat,
so I agree it makes sense to change things here.

> 2.) Drop the unnecessary custom integer types in favor of standard ones.

...but it doesn't do this because it isn't touching the 'bits32' types which
are the ones which are exact synonyms for the posix int32_t &c.
If your aim is to remove unnecessary custom types this is the first and
easiest target because you can do it as a pure search-and-replace.

> 3.) Fix instances of lazyness where _t was forgotten and the mistake was
> hidden by the softfloat typedefs.
>
> Renaming int32 to qint32 would defeat the second purpose. I got around the
> Haiku issue for now, so that's not a pressing need.
>
> Had the softfloat code not been a real refactoring-unfriendly mess of int,
> int* and int*_t, I would've offered to do this in multiple steps per type. I
> could try splitting out part 1 above. Part 3 can easily be split off by
> cut-and-paste and could be applied independently.

I certainly think it would be easier to review as separate patches which
did different things.

> Promoting int16[_t] to int for things like shift counts is beyond the scope
> of my patch.

...but your patch changes what is currently an 'int' (hidden behind the int16
typedef) to int16_t, so it is making a change here. It's a safe change but
it doesn't actually make any sense.

-- PMM
Andreas Färber - Dec. 18, 2010, 12:31 p.m.
Am 18.12.2010 um 13:15 schrieb Peter Maydell:

> On 18 December 2010 11:49, Andreas Färber <andreas.faerber@web.de>  
> wrote:
>> IMO a lot of code in QEMU is cryptic because someone thinks that  
>> someone
>> else must've thought something particular when doing it that way  
>> and is thus
>> reluctant to touch it...
>
>> For a fact, [u]int8 und [u]int64 remain unchanged width-wise.
>> For [u]int16, only malc may know what that maps to on AIX, for  
>> which they
>> are #ifndef'ed out. I doubt it's an int.
>> Unless there's an ILP64 platform we support, [u]int32 would stay  
>> the same
>> width, too.
>> That's why I was saying, putting, e.g., a 33rd bit into int32 has  
>> undefined
>> semantics, just as for the POSIX int_least32_t type. I don't see a  
>> win in
>> declaring that information.
>
> It's saying "it's OK to provide more than 32 bits if that would be  
> faster",
> and indeed that's exactly how we typedef it. Some parts of softfloat
> that use bits32 do rely on there being exactly 32 bits and not 64.

Okay, then I'll use int_least*_t instead. Performance is always a good  
argument. :)

>> My patch tries to do three things in one:
>
>> 1.) Fix mismatches between headers and sources, i.e. float32
>> int32_to_float32(int); vs. float32 int32_to_float32(int32) {...} etc.
>
> In this case we do know the rationale for this mismatch:
> http://www.jhauser.us/arithmetic/SoftFloat-2b/SoftFloat-source.txt
> ---begin---
> Unlike the actual function definitions in `softfloat.c', the  
> declarations
> in `softfloat.h' do not use any of the types defined by the  
> `processors'
> header file.  This is done so that clients will not have to include  
> the
> `processors' header file in order to use SoftFloat.  Nevertheless, the
> target-specific declarations in `softfloat.h' must match what  
> `softfloat.c'
> expects.  For example, if `int32' is defined as `int' in the  
> `processors'
> header file, then in `softfloat.h' the output of `float32_to_int32'  
> should
> be stated as `int', although in `softfloat.c' it is given in target-
> independent form as `int32'.
> ---endit---
>
> ...which doesn't really apply to the way qemu has taken softfloat,
> so I agree it makes sense to change things here.

So, how far are we from the original? Given that the latest version is  
from 2002, would it make any sense to move this to a Git submodule?

>> 2.) Drop the unnecessary custom integer types in favor of standard  
>> ones.
>
> ...but it doesn't do this because it isn't touching the 'bits32'  
> types which
> are the ones which are exact synonyms for the posix int32_t &c.
> If your aim is to remove unnecessary custom types this is the first  
> and
> easiest target because you can do it as a pure search-and-replace.

OK, will do.

>> 3.) Fix instances of lazyness where _t was forgotten and the  
>> mistake was
>> hidden by the softfloat typedefs.
>>
>> Renaming int32 to qint32 would defeat the second purpose. I got  
>> around the
>> Haiku issue for now, so that's not a pressing need.
>>
>> Had the softfloat code not been a real refactoring-unfriendly mess  
>> of int,
>> int* and int*_t, I would've offered to do this in multiple steps  
>> per type. I
>> could try splitting out part 1 above. Part 3 can easily be split  
>> off by
>> cut-and-paste and could be applied independently.
>
> I certainly think it would be easier to review as separate patches  
> which
> did different things.
>
>> Promoting int16[_t] to int for things like shift counts is beyond  
>> the scope
>> of my patch.
>
> ...but your patch changes what is currently an 'int' (hidden behind  
> the int16
> typedef) to int16_t, so it is making a change here. It's a safe  
> change but
> it doesn't actually make any sense.

No, it's an implementation detail and is only the way you describe  
outside AIX currently. It may well be int16_t already there.
And yes, it doesn't make sense, but that's not my fault, it's the  
author's use of int16 that's unnecessary from the start.

Andreas
Nathan Froyd - Dec. 18, 2010, 1:07 p.m.
On Sat, Dec 18, 2010 at 10:39:05AM +0000, Peter Maydell wrote:
> On 18 December 2010 02:30, Nathan Froyd <froydnj@codesourcery.com> wrote:
> > So adding _t suffixes in appropriate places should be a no-op, except
> > for uint16/int16--and those types are never used.
> 
> Eh? If you comment out the int16 typedef you'll find softfloat.c
> doesn't compile because of all the places it's used... (uint16
> isn't used, though.)

Sorry about that, I fail at grepping late at night. =/

-Nathan
Andreas Färber - Dec. 18, 2010, 4:41 p.m.
Am 18.12.2010 um 13:31 schrieb Andreas Färber:

> Am 18.12.2010 um 13:15 schrieb Peter Maydell:
>
>> On 18 December 2010 11:49, Andreas Färber <andreas.faerber@web.de>  
>> wrote:
>>> IMO a lot of code in QEMU is cryptic because someone thinks that  
>>> someone
>>> else must've thought something particular when doing it that way  
>>> and is thus
>>> reluctant to touch it...
>>
>>> For a fact, [u]int8 und [u]int64 remain unchanged width-wise.
>>> For [u]int16, only malc may know what that maps to on AIX, for  
>>> which they
>>> are #ifndef'ed out. I doubt it's an int.
>>> Unless there's an ILP64 platform we support, [u]int32 would stay  
>>> the same
>>> width, too.
>>> That's why I was saying, putting, e.g., a 33rd bit into int32 has  
>>> undefined
>>> semantics, just as for the POSIX int_least32_t type. I don't see a  
>>> win in
>>> declaring that information.
>>
>> It's saying "it's OK to provide more than 32 bits if that would be  
>> faster",
>> and indeed that's exactly how we typedef it. Some parts of softfloat
>> that use bits32 do rely on there being exactly 32 bits and not 64.
>
> Okay, then I'll use int_least*_t instead. Performance is always a  
> good argument. :)

...so on second thoughts I went with int_fast*_t.

>>> My patch tries to do three things in one:
>>
>>> 1.) Fix mismatches between headers and sources, i.e. float32
>>> int32_to_float32(int); vs. float32 int32_to_float32(int32) {...}  
>>> etc.
>>
>> In this case we do know the rationale for this mismatch:
>> http://www.jhauser.us/arithmetic/SoftFloat-2b/SoftFloat-source.txt
>> ---begin---
>> Unlike the actual function definitions in `softfloat.c', the  
>> declarations
>> in `softfloat.h' do not use any of the types defined by the  
>> `processors'
>> header file.  This is done so that clients will not have to include  
>> the
>> `processors' header file in order to use SoftFloat.  Nevertheless,  
>> the
>> target-specific declarations in `softfloat.h' must match what  
>> `softfloat.c'
>> expects.  For example, if `int32' is defined as `int' in the  
>> `processors'
>> header file, then in `softfloat.h' the output of `float32_to_int32'  
>> should
>> be stated as `int', although in `softfloat.c' it is given in target-
>> independent form as `int32'.
>> ---endit---
>>
>> ...which doesn't really apply to the way qemu has taken softfloat,
>> so I agree it makes sense to change things here.

Done in 4/7.

>>> 2.) Drop the unnecessary custom integer types in favor of standard  
>>> ones.
>>
>> ...but it doesn't do this because it isn't touching the 'bits32'  
>> types which
>> are the ones which are exact synonyms for the posix int32_t &c.
>> If your aim is to remove unnecessary custom types this is the first  
>> and
>> easiest target because you can do it as a pure search-and-replace.

Done in 5/7.

>>> 3.) Fix instances of lazyness where _t was forgotten and the  
>>> mistake was
>>> hidden by the softfloat typedefs.
>>>
>>> Renaming int32 to qint32 would defeat the second purpose. I got  
>>> around the
>>> Haiku issue for now, so that's not a pressing need.
>>>
>>> Had the softfloat code not been a real refactoring-unfriendly mess  
>>> of int,
>>> int* and int*_t, I would've offered to do this in multiple steps  
>>> per type. I
>>> could try splitting out part 1 above. Part 3 can easily be split  
>>> off by
>>> cut-and-paste and could be applied independently.
>>
>> I certainly think it would be easier to review as separate patches  
>> which
>> did different things.

Please do. I've migrated [u]int16 only for now, awaiting review before  
continuing.

Patches 1-3 could be applied right away IMO if no objections arise,  
the rest should be synchronized with yours.

Andreas
malc - Dec. 18, 2010, 5:55 p.m.
On Sat, 18 Dec 2010, Andreas F?rber wrote:

> Am 18.12.2010 um 11:39 schrieb Peter Maydell:
> 
> > On 18 December 2010 02:30, Nathan Froyd <froydnj@codesourcery.com> wrote:
> > > I wouldn't be too worried:
> > > 
> > > typedef uint8_t flag;
> > > typedef uint8_t uint8;
> > > typedef int8_t int8;
> > > typedef int uint16;
> > > typedef int int16;
> > > typedef unsigned int uint32;
> > > typedef signed int int32;
> > > typedef uint64_t uint64;
> > > typedef int64_t int64;
> > > 
> > > So adding _t suffixes in appropriate places should be a no-op, except
> > > for uint16/int16--and those types are never used.
> > 
> > Eh? If you comment out the int16 typedef you'll find softfloat.c
> > doesn't compile because of all the places it's used... (uint16
> > isn't used, though.) A lot of the int16 uses are things like shift counts
> > which should probably go to plain old 'int' rather than 'int16_t'.
> > 
> > Also, are we sure we want to throw away the current information
> > in the code about the distinction between "I need at least X bits"
> > and "I need exactly X bits" ?
> 
> IMO a lot of code in QEMU is cryptic because someone thinks that someone else
> must've thought something particular when doing it that way and is thus
> reluctant to touch it...
> 
> For a fact, [u]int8 und [u]int64 remain unchanged width-wise.
> For [u]int16, only malc may know what that maps to on AIX, for which they are
> #ifndef'ed out. I doubt it's an int.

AIX leaks all sorts of stuff from system headers, i don't remember what
int16 is defined as.

> Unless there's an ILP64 platform we support, [u]int32 would stay the same
> width, too.
> That's why I was saying, putting, e.g., a 33rd bit into int32 has undefined
> semantics, just as for the POSIX int_least32_t type. I don't see a win in
> declaring that information.
> 
> My patch tries to do three things in one:
> 1.) Fix mismatches between headers and sources, i.e. float32
> int32_to_float32(int); vs. float32 int32_to_float32(int32) {...} etc.
> 2.) Drop the unnecessary custom integer types in favor of standard ones.
> 3.) Fix instances of lazyness where _t was forgotten and the mistake was
> hidden by the softfloat typedefs.
> 
> Renaming int32 to qint32 would defeat the second purpose. I got around the
> Haiku issue for now, so that's not a pressing need.
> 
> Had the softfloat code not been a real refactoring-unfriendly mess of int,
> int* and int*_t, I would've offered to do this in multiple steps per type. I
> could try splitting out part 1 above. Part 3 can easily be split off by
> cut-and-paste and could be applied independently.
> 
> Promoting int16[_t] to int for things like shift counts is beyond the scope of
> my patch.
> 
> Andreas
Peter Maydell - Jan. 1, 2011, 11:46 p.m.
On 17 December 2010 15:56, Peter Maydell <peter.maydell@linaro.org> wrote:
> The softfloat functions float*_is_nan() were badly misnamed,
> because they return true only for quiet NaNs, not for all NaNs.
> Rename them to float*_is_quiet_nan() to more accurately reflect
> what they do.
>
> This change was produced by:
>  perl -p -i -e 's/_is_nan/_is_quiet_nan/g' $(git grep -l is_nan)
> (with the results manually checked.)
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> Reviewed-by: Nathan Froyd <froydnj@codesourcery.com>
> Acked-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>

Ping? This patch got no further comments (although it provoked
a long thread on a completely unrelated topic), it's been
reviewed and it still applies to master currently. I think it's
an uncontroversially good idea (~80% of current uses of the
functions are actually buggy because the people who wrote
them were misled by the function name!).

Can it be applied please? (cc'd Aurelien since you seem to be
committing various missed patches at the moment :-))

thanks
-- PMM
Andreas Färber - Jan. 2, 2011, 12:35 a.m.
Am 02.01.2011 um 00:46 schrieb Peter Maydell:

> On 17 December 2010 15:56, Peter Maydell <peter.maydell@linaro.org>  
> wrote:
>> The softfloat functions float*_is_nan() were badly misnamed,
>> because they return true only for quiet NaNs, not for all NaNs.
>> Rename them to float*_is_quiet_nan() to more accurately reflect
>> what they do.
>>
>> This change was produced by:
>>  perl -p -i -e 's/_is_nan/_is_quiet_nan/g' $(git grep -l is_nan)
>> (with the results manually checked.)
>>
>> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
>> Reviewed-by: Nathan Froyd <froydnj@codesourcery.com>
>> Acked-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
>
> Ping? This patch got no further comments (although it provoked
> a long thread on a completely unrelated topic), it's been
> reviewed and it still applies to master currently. I think it's
> an uncontroversially good idea (~80% of current uses of the
> functions are actually buggy because the people who wrote
> them were misled by the function name!).
>
> Can it be applied please?

No objections from my side. While I have not yet tested it, the fpu/  
changes only have *_is_* functions in the patch context and introduce  
no new type hickups as far as I could see.

Andreas
Aurelien Jarno - Jan. 2, 2011, 10:31 a.m.
On Sat, Jan 01, 2011 at 11:46:16PM +0000, Peter Maydell wrote:
> On 17 December 2010 15:56, Peter Maydell <peter.maydell@linaro.org> wrote:
> > The softfloat functions float*_is_nan() were badly misnamed,
> > because they return true only for quiet NaNs, not for all NaNs.
> > Rename them to float*_is_quiet_nan() to more accurately reflect
> > what they do.
> >
> > This change was produced by:
> >  perl -p -i -e 's/_is_nan/_is_quiet_nan/g' $(git grep -l is_nan)
> > (with the results manually checked.)
> >
> > Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> > Reviewed-by: Nathan Froyd <froydnj@codesourcery.com>
> > Acked-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
> 
> Ping? This patch got no further comments (although it provoked
> a long thread on a completely unrelated topic), it's been
> reviewed and it still applies to master currently. I think it's
> an uncontroversially good idea (~80% of current uses of the
> functions are actually buggy because the people who wrote
> them were misled by the function name!).
> 
> Can it be applied please? (cc'd Aurelien since you seem to be
> committing various missed patches at the moment :-))
> 

Sorry, I understood there was a conflict with another patch series, and
it was better to wait. Committed now.

As a side note, there are now a few places where the following code is
present:

  float32_is_quiet_nan(x) || float32_is_signaling_nan(x)

It might be a good idea to add back a function float32_is_nan() that
this time checks for both quiet and signaling NaN.
Peter Maydell - Jan. 2, 2011, 11:12 a.m.
On 2 January 2011 10:31, Aurelien Jarno <aurelien@aurel32.net> wrote:
> On Sat, Jan 01, 2011 at 11:46:16PM +0000, Peter Maydell wrote:
>> Can it be applied please? (cc'd Aurelien since you seem to be
>> committing various missed patches at the moment :-))
>
> Sorry, I understood there was a conflict with another patch series, and
> it was better to wait. Committed now.

Thanks.

> As a side note, there are now a few places where the following code is
> present:
>
>  float32_is_quiet_nan(x) || float32_is_signaling_nan(x)
>
> It might be a good idea to add back a function float32_is_nan() that
> this time checks for both quiet and signaling NaN.

This is already present as float32_is_any_nan() (I added it as
part of one of the earlier ARM patchsets).

-- PMM
Aurelien Jarno - Jan. 2, 2011, 11:56 a.m.
On Sun, Jan 02, 2011 at 11:12:32AM +0000, Peter Maydell wrote:
> On 2 January 2011 10:31, Aurelien Jarno <aurelien@aurel32.net> wrote:
> > On Sat, Jan 01, 2011 at 11:46:16PM +0000, Peter Maydell wrote:
> >> Can it be applied please? (cc'd Aurelien since you seem to be
> >> committing various missed patches at the moment :-))
> >
> > Sorry, I understood there was a conflict with another patch series, and
> > it was better to wait. Committed now.
> 
> Thanks.
> 
> > As a side note, there are now a few places where the following code is
> > present:
> >
> >  float32_is_quiet_nan(x) || float32_is_signaling_nan(x)
> >
> > It might be a good idea to add back a function float32_is_nan() that
> > this time checks for both quiet and signaling NaN.
> 
> This is already present as float32_is_any_nan() (I added it as
> part of one of the earlier ARM patchsets).
> 

Ok, then I am going to produce a cleanup patch to use it.

Patch

diff --git a/fpu/softfloat-native.c b/fpu/softfloat-native.c
index 049c830..008bb53 100644
--- a/fpu/softfloat-native.c
+++ b/fpu/softfloat-native.c
@@ -254,7 +254,7 @@  int float32_is_signaling_nan( float32 a1)
     return ( ( ( a>>22 ) & 0x1FF ) == 0x1FE ) && ( a & 0x003FFFFF );
 }
 
-int float32_is_nan( float32 a1 )
+int float32_is_quiet_nan( float32 a1 )
 {
     float32u u;
     uint64_t a;
@@ -411,7 +411,7 @@  int float64_is_signaling_nan( float64 a1)
 
 }
 
-int float64_is_nan( float64 a1 )
+int float64_is_quiet_nan( float64 a1 )
 {
     float64u u;
     uint64_t a;
@@ -504,7 +504,7 @@  int floatx80_is_signaling_nan( floatx80 a1)
         && ( u.i.low == aLow );
 }
 
-int floatx80_is_nan( floatx80 a1 )
+int floatx80_is_quiet_nan( floatx80 a1 )
 {
     floatx80u u;
     u.f = a1;
diff --git a/fpu/softfloat-native.h b/fpu/softfloat-native.h
index 6da0bcb..80b5f28 100644
--- a/fpu/softfloat-native.h
+++ b/fpu/softfloat-native.h
@@ -242,7 +242,7 @@  INLINE int float32_unordered( float32 a, float32 b STATUS_PARAM)
 int float32_compare( float32, float32 STATUS_PARAM );
 int float32_compare_quiet( float32, float32 STATUS_PARAM );
 int float32_is_signaling_nan( float32 );
-int float32_is_nan( float32 );
+int float32_is_quiet_nan( float32 );
 
 INLINE float32 float32_abs(float32 a)
 {
@@ -351,7 +351,7 @@  INLINE int float64_unordered( float64 a, float64 b STATUS_PARAM)
 int float64_compare( float64, float64 STATUS_PARAM );
 int float64_compare_quiet( float64, float64 STATUS_PARAM );
 int float64_is_signaling_nan( float64 );
-int float64_is_nan( float64 );
+int float64_is_quiet_nan( float64 );
 
 INLINE float64 float64_abs(float64 a)
 {
@@ -455,7 +455,7 @@  INLINE int floatx80_unordered( floatx80 a, floatx80 b STATUS_PARAM)
 int floatx80_compare( floatx80, floatx80 STATUS_PARAM );
 int floatx80_compare_quiet( floatx80, floatx80 STATUS_PARAM );
 int floatx80_is_signaling_nan( floatx80 );
-int floatx80_is_nan( floatx80 );
+int floatx80_is_quiet_nan( floatx80 );
 
 INLINE floatx80 floatx80_abs(floatx80 a)
 {
diff --git a/fpu/softfloat-specialize.h b/fpu/softfloat-specialize.h
index 0746878..f382f7a 100644
--- a/fpu/softfloat-specialize.h
+++ b/fpu/softfloat-specialize.h
@@ -76,7 +76,7 @@  typedef struct {
 | NaN; otherwise returns 0.
 *----------------------------------------------------------------------------*/
 
-int float32_is_nan( float32 a_ )
+int float32_is_quiet_nan( float32 a_ )
 {
     uint32_t a = float32_val(a_);
 #if SNAN_BIT_IS_ONE
@@ -166,9 +166,9 @@  static float32 propagateFloat32NaN( float32 a, float32 b STATUS_PARAM)
     if ( STATUS(default_nan_mode) )
         return float32_default_nan;
 
-    aIsNaN = float32_is_nan( a );
+    aIsNaN = float32_is_quiet_nan( a );
     aIsSignalingNaN = float32_is_signaling_nan( a );
-    bIsNaN = float32_is_nan( b );
+    bIsNaN = float32_is_quiet_nan( b );
     bIsSignalingNaN = float32_is_signaling_nan( b );
     av = float32_val(a);
     bv = float32_val(b);
@@ -223,7 +223,7 @@  static float32 propagateFloat32NaN( float32 a, float32 b STATUS_PARAM)
 | NaN; otherwise returns 0.
 *----------------------------------------------------------------------------*/
 
-int float64_is_nan( float64 a_ )
+int float64_is_quiet_nan( float64 a_ )
 {
     bits64 a = float64_val(a_);
 #if SNAN_BIT_IS_ONE
@@ -320,9 +320,9 @@  static float64 propagateFloat64NaN( float64 a, float64 b STATUS_PARAM)
     if ( STATUS(default_nan_mode) )
         return float64_default_nan;
 
-    aIsNaN = float64_is_nan( a );
+    aIsNaN = float64_is_quiet_nan( a );
     aIsSignalingNaN = float64_is_signaling_nan( a );
-    bIsNaN = float64_is_nan( b );
+    bIsNaN = float64_is_quiet_nan( b );
     bIsSignalingNaN = float64_is_signaling_nan( b );
     av = float64_val(a);
     bv = float64_val(b);
@@ -377,7 +377,7 @@  static float64 propagateFloat64NaN( float64 a, float64 b STATUS_PARAM)
 | quiet NaN; otherwise returns 0.
 *----------------------------------------------------------------------------*/
 
-int floatx80_is_nan( floatx80 a )
+int floatx80_is_quiet_nan( floatx80 a )
 {
 #if SNAN_BIT_IS_ONE
     bits64 aLow;
@@ -462,9 +462,9 @@  static floatx80 propagateFloatx80NaN( floatx80 a, floatx80 b STATUS_PARAM)
         return a;
     }
 
-    aIsNaN = floatx80_is_nan( a );
+    aIsNaN = floatx80_is_quiet_nan( a );
     aIsSignalingNaN = floatx80_is_signaling_nan( a );
-    bIsNaN = floatx80_is_nan( b );
+    bIsNaN = floatx80_is_quiet_nan( b );
     bIsSignalingNaN = floatx80_is_signaling_nan( b );
 #if SNAN_BIT_IS_ONE
     a.low &= ~LIT64( 0xC000000000000000 );
@@ -511,7 +511,7 @@  static floatx80 propagateFloatx80NaN( floatx80 a, floatx80 b STATUS_PARAM)
 | NaN; otherwise returns 0.
 *----------------------------------------------------------------------------*/
 
-int float128_is_nan( float128 a )
+int float128_is_quiet_nan( float128 a )
 {
 #if SNAN_BIT_IS_ONE
     return
@@ -588,9 +588,9 @@  static float128 propagateFloat128NaN( float128 a, float128 b STATUS_PARAM)
         return a;
     }
 
-    aIsNaN = float128_is_nan( a );
+    aIsNaN = float128_is_quiet_nan( a );
     aIsSignalingNaN = float128_is_signaling_nan( a );
-    bIsNaN = float128_is_nan( b );
+    bIsNaN = float128_is_quiet_nan( b );
     bIsSignalingNaN = float128_is_signaling_nan( b );
 #if SNAN_BIT_IS_ONE
     a.high &= ~LIT64( 0x0000800000000000 );
diff --git a/fpu/softfloat.h b/fpu/softfloat.h
index 1c1004d..1f37877 100644
--- a/fpu/softfloat.h
+++ b/fpu/softfloat.h
@@ -287,7 +287,7 @@  int float32_le_quiet( float32, float32 STATUS_PARAM );
 int float32_lt_quiet( float32, float32 STATUS_PARAM );
 int float32_compare( float32, float32 STATUS_PARAM );
 int float32_compare_quiet( float32, float32 STATUS_PARAM );
-int float32_is_nan( float32 );
+int float32_is_quiet_nan( float32 );
 int float32_is_signaling_nan( float32 );
 float32 float32_maybe_silence_nan( float32 );
 float32 float32_scalbn( float32, int STATUS_PARAM );
@@ -367,7 +367,7 @@  int float64_le_quiet( float64, float64 STATUS_PARAM );
 int float64_lt_quiet( float64, float64 STATUS_PARAM );
 int float64_compare( float64, float64 STATUS_PARAM );
 int float64_compare_quiet( float64, float64 STATUS_PARAM );
-int float64_is_nan( float64 a );
+int float64_is_quiet_nan( float64 a );
 int float64_is_signaling_nan( float64 );
 float64 float64_maybe_silence_nan( float64 );
 float64 float64_scalbn( float64, int STATUS_PARAM );
@@ -437,7 +437,7 @@  int floatx80_lt( floatx80, floatx80 STATUS_PARAM );
 int floatx80_eq_signaling( floatx80, floatx80 STATUS_PARAM );
 int floatx80_le_quiet( floatx80, floatx80 STATUS_PARAM );
 int floatx80_lt_quiet( floatx80, floatx80 STATUS_PARAM );
-int floatx80_is_nan( floatx80 );
+int floatx80_is_quiet_nan( floatx80 );
 int floatx80_is_signaling_nan( floatx80 );
 floatx80 floatx80_scalbn( floatx80, int STATUS_PARAM );
 
@@ -503,7 +503,7 @@  int float128_le_quiet( float128, float128 STATUS_PARAM );
 int float128_lt_quiet( float128, float128 STATUS_PARAM );
 int float128_compare( float128, float128 STATUS_PARAM );
 int float128_compare_quiet( float128, float128 STATUS_PARAM );
-int float128_is_nan( float128 );
+int float128_is_quiet_nan( float128 );
 int float128_is_signaling_nan( float128 );
 float128 float128_scalbn( float128, int STATUS_PARAM );
 
diff --git a/linux-user/arm/nwfpe/fpa11_cprt.c b/linux-user/arm/nwfpe/fpa11_cprt.c
index 5d64591..0e61b58 100644
--- a/linux-user/arm/nwfpe/fpa11_cprt.c
+++ b/linux-user/arm/nwfpe/fpa11_cprt.c
@@ -199,21 +199,21 @@  static unsigned int PerformComparison(const unsigned int opcode)
    {
       case typeSingle:
         //printk("single.\n");
-	if (float32_is_nan(fpa11->fpreg[Fn].fSingle))
+	if (float32_is_quiet_nan(fpa11->fpreg[Fn].fSingle))
 	   goto unordered;
         rFn = float32_to_floatx80(fpa11->fpreg[Fn].fSingle, &fpa11->fp_status);
       break;
 
       case typeDouble:
         //printk("double.\n");
-	if (float64_is_nan(fpa11->fpreg[Fn].fDouble))
+	if (float64_is_quiet_nan(fpa11->fpreg[Fn].fDouble))
 	   goto unordered;
         rFn = float64_to_floatx80(fpa11->fpreg[Fn].fDouble, &fpa11->fp_status);
       break;
 
       case typeExtended:
         //printk("extended.\n");
-	if (floatx80_is_nan(fpa11->fpreg[Fn].fExtended))
+	if (floatx80_is_quiet_nan(fpa11->fpreg[Fn].fExtended))
 	   goto unordered;
         rFn = fpa11->fpreg[Fn].fExtended;
       break;
@@ -225,7 +225,7 @@  static unsigned int PerformComparison(const unsigned int opcode)
    {
      //printk("Fm is a constant: #%d.\n",Fm);
      rFm = getExtendedConstant(Fm);
-     if (floatx80_is_nan(rFm))
+     if (floatx80_is_quiet_nan(rFm))
         goto unordered;
    }
    else
@@ -235,21 +235,21 @@  static unsigned int PerformComparison(const unsigned int opcode)
       {
          case typeSingle:
            //printk("single.\n");
-	   if (float32_is_nan(fpa11->fpreg[Fm].fSingle))
+	   if (float32_is_quiet_nan(fpa11->fpreg[Fm].fSingle))
 	      goto unordered;
            rFm = float32_to_floatx80(fpa11->fpreg[Fm].fSingle, &fpa11->fp_status);
          break;
 
          case typeDouble:
            //printk("double.\n");
-	   if (float64_is_nan(fpa11->fpreg[Fm].fDouble))
+	   if (float64_is_quiet_nan(fpa11->fpreg[Fm].fDouble))
 	      goto unordered;
            rFm = float64_to_floatx80(fpa11->fpreg[Fm].fDouble, &fpa11->fp_status);
          break;
 
          case typeExtended:
            //printk("extended.\n");
-	   if (floatx80_is_nan(fpa11->fpreg[Fm].fExtended))
+	   if (floatx80_is_quiet_nan(fpa11->fpreg[Fm].fExtended))
 	      goto unordered;
            rFm = fpa11->fpreg[Fm].fExtended;
          break;
diff --git a/target-alpha/op_helper.c b/target-alpha/op_helper.c
index ff5ae26..6c2ae20 100644
--- a/target-alpha/op_helper.c
+++ b/target-alpha/op_helper.c
@@ -904,7 +904,7 @@  uint64_t helper_cmptun (uint64_t a, uint64_t b)
     fa = t_to_float64(a);
     fb = t_to_float64(b);
 
-    if (float64_is_nan(fa) || float64_is_nan(fb))
+    if (float64_is_quiet_nan(fa) || float64_is_quiet_nan(fb))
         return 0x4000000000000000ULL;
     else
         return 0;
diff --git a/target-m68k/helper.c b/target-m68k/helper.c
index 56de897..514b039 100644
--- a/target-m68k/helper.c
+++ b/target-m68k/helper.c
@@ -614,10 +614,10 @@  float64 HELPER(sub_cmp_f64)(CPUState *env, float64 a, float64 b)
     /* ??? Should flush denormals to zero.  */
     float64 res;
     res = float64_sub(a, b, &env->fp_status);
-    if (float64_is_nan(res)) {
+    if (float64_is_quiet_nan(res)) {
         /* +/-inf compares equal against itself, but sub returns nan.  */
-        if (!float64_is_nan(a)
-            && !float64_is_nan(b)) {
+        if (!float64_is_quiet_nan(a)
+            && !float64_is_quiet_nan(b)) {
             res = float64_zero;
             if (float64_lt_quiet(a, res, &env->fp_status))
                 res = float64_chs(res);
diff --git a/target-microblaze/op_helper.c b/target-microblaze/op_helper.c
index 3d2b313..97461ae 100644
--- a/target-microblaze/op_helper.c
+++ b/target-microblaze/op_helper.c
@@ -308,7 +308,7 @@  uint32_t helper_fcmp_un(uint32_t a, uint32_t b)
         r = 1;
     }
 
-    if (float32_is_nan(fa.f) || float32_is_nan(fb.f)) {
+    if (float32_is_quiet_nan(fa.f) || float32_is_quiet_nan(fb.f)) {
         r = 1;
     }
 
diff --git a/target-mips/op_helper.c b/target-mips/op_helper.c
index 41abd57..5df42cc 100644
--- a/target-mips/op_helper.c
+++ b/target-mips/op_helper.c
@@ -2889,10 +2889,10 @@  static int float64_is_unordered(int sig, float64 a, float64 b STATUS_PARAM)
 {
     if (float64_is_signaling_nan(a) ||
         float64_is_signaling_nan(b) ||
-        (sig && (float64_is_nan(a) || float64_is_nan(b)))) {
+        (sig && (float64_is_quiet_nan(a) || float64_is_quiet_nan(b)))) {
         float_raise(float_flag_invalid, status);
         return 1;
-    } else if (float64_is_nan(a) || float64_is_nan(b)) {
+    } else if (float64_is_quiet_nan(a) || float64_is_quiet_nan(b)) {
         return 1;
     } else {
         return 0;
@@ -2947,10 +2947,10 @@  static flag float32_is_unordered(int sig, float32 a, float32 b STATUS_PARAM)
 {
     if (float32_is_signaling_nan(a) ||
         float32_is_signaling_nan(b) ||
-        (sig && (float32_is_nan(a) || float32_is_nan(b)))) {
+        (sig && (float32_is_quiet_nan(a) || float32_is_quiet_nan(b)))) {
         float_raise(float_flag_invalid, status);
         return 1;
-    } else if (float32_is_nan(a) || float32_is_nan(b)) {
+    } else if (float32_is_quiet_nan(a) || float32_is_quiet_nan(b)) {
         return 1;
     } else {
         return 0;
diff --git a/target-ppc/op_helper.c b/target-ppc/op_helper.c
index f32a5ff..5ded1c1 100644
--- a/target-ppc/op_helper.c
+++ b/target-ppc/op_helper.c
@@ -546,7 +546,7 @@  uint32_t helper_compute_fprf (uint64_t arg, uint32_t set_fprf)
     int ret;
     farg.ll = arg;
     isneg = float64_is_neg(farg.d);
-    if (unlikely(float64_is_nan(farg.d))) {
+    if (unlikely(float64_is_quiet_nan(farg.d))) {
         if (float64_is_signaling_nan(farg.d)) {
             /* Signaling NaN: flags are undefined */
             ret = 0x00;
@@ -1111,7 +1111,7 @@  uint64_t helper_fctiw (uint64_t arg)
     if (unlikely(float64_is_signaling_nan(farg.d))) {
         /* sNaN conversion */
         farg.ll = fload_invalid_op_excp(POWERPC_EXCP_FP_VXSNAN | POWERPC_EXCP_FP_VXCVI);
-    } else if (unlikely(float64_is_nan(farg.d) || float64_is_infinity(farg.d))) {
+    } else if (unlikely(float64_is_quiet_nan(farg.d) || float64_is_infinity(farg.d))) {
         /* qNan / infinity conversion */
         farg.ll = fload_invalid_op_excp(POWERPC_EXCP_FP_VXCVI);
     } else {
@@ -1135,7 +1135,7 @@  uint64_t helper_fctiwz (uint64_t arg)
     if (unlikely(float64_is_signaling_nan(farg.d))) {
         /* sNaN conversion */
         farg.ll = fload_invalid_op_excp(POWERPC_EXCP_FP_VXSNAN | POWERPC_EXCP_FP_VXCVI);
-    } else if (unlikely(float64_is_nan(farg.d) || float64_is_infinity(farg.d))) {
+    } else if (unlikely(float64_is_quiet_nan(farg.d) || float64_is_infinity(farg.d))) {
         /* qNan / infinity conversion */
         farg.ll = fload_invalid_op_excp(POWERPC_EXCP_FP_VXCVI);
     } else {
@@ -1168,7 +1168,7 @@  uint64_t helper_fctid (uint64_t arg)
     if (unlikely(float64_is_signaling_nan(farg.d))) {
         /* sNaN conversion */
         farg.ll = fload_invalid_op_excp(POWERPC_EXCP_FP_VXSNAN | POWERPC_EXCP_FP_VXCVI);
-    } else if (unlikely(float64_is_nan(farg.d) || float64_is_infinity(farg.d))) {
+    } else if (unlikely(float64_is_quiet_nan(farg.d) || float64_is_infinity(farg.d))) {
         /* qNan / infinity conversion */
         farg.ll = fload_invalid_op_excp(POWERPC_EXCP_FP_VXCVI);
     } else {
@@ -1186,7 +1186,7 @@  uint64_t helper_fctidz (uint64_t arg)
     if (unlikely(float64_is_signaling_nan(farg.d))) {
         /* sNaN conversion */
         farg.ll = fload_invalid_op_excp(POWERPC_EXCP_FP_VXSNAN | POWERPC_EXCP_FP_VXCVI);
-    } else if (unlikely(float64_is_nan(farg.d) || float64_is_infinity(farg.d))) {
+    } else if (unlikely(float64_is_quiet_nan(farg.d) || float64_is_infinity(farg.d))) {
         /* qNan / infinity conversion */
         farg.ll = fload_invalid_op_excp(POWERPC_EXCP_FP_VXCVI);
     } else {
@@ -1205,7 +1205,7 @@  static inline uint64_t do_fri(uint64_t arg, int rounding_mode)
     if (unlikely(float64_is_signaling_nan(farg.d))) {
         /* sNaN round */
         farg.ll = fload_invalid_op_excp(POWERPC_EXCP_FP_VXSNAN | POWERPC_EXCP_FP_VXCVI);
-    } else if (unlikely(float64_is_nan(farg.d) || float64_is_infinity(farg.d))) {
+    } else if (unlikely(float64_is_quiet_nan(farg.d) || float64_is_infinity(farg.d))) {
         /* qNan / infinity round */
         farg.ll = fload_invalid_op_excp(POWERPC_EXCP_FP_VXCVI);
     } else {
@@ -1375,7 +1375,7 @@  uint64_t helper_fnmadd (uint64_t arg1, uint64_t arg2, uint64_t arg3)
         farg1.d = float64_mul(farg1.d, farg2.d, &env->fp_status);
         farg1.d = float64_add(farg1.d, farg3.d, &env->fp_status);
 #endif
-        if (likely(!float64_is_nan(farg1.d)))
+        if (likely(!float64_is_quiet_nan(farg1.d)))
             farg1.d = float64_chs(farg1.d);
     }
     return farg1.ll;
@@ -1425,7 +1425,7 @@  uint64_t helper_fnmsub (uint64_t arg1, uint64_t arg2, uint64_t arg3)
         farg1.d = float64_mul(farg1.d, farg2.d, &env->fp_status);
         farg1.d = float64_sub(farg1.d, farg3.d, &env->fp_status);
 #endif
-        if (likely(!float64_is_nan(farg1.d)))
+        if (likely(!float64_is_quiet_nan(farg1.d)))
             farg1.d = float64_chs(farg1.d);
     }
     return farg1.ll;
@@ -1533,7 +1533,7 @@  uint64_t helper_fsel (uint64_t arg1, uint64_t arg2, uint64_t arg3)
 
     farg1.ll = arg1;
 
-    if ((!float64_is_neg(farg1.d) || float64_is_zero(farg1.d)) && !float64_is_nan(farg1.d))
+    if ((!float64_is_neg(farg1.d) || float64_is_zero(farg1.d)) && !float64_is_quiet_nan(farg1.d))
         return arg2;
     else
         return arg3;
@@ -1546,8 +1546,8 @@  void helper_fcmpu (uint64_t arg1, uint64_t arg2, uint32_t crfD)
     farg1.ll = arg1;
     farg2.ll = arg2;
 
-    if (unlikely(float64_is_nan(farg1.d) ||
-                 float64_is_nan(farg2.d))) {
+    if (unlikely(float64_is_quiet_nan(farg1.d) ||
+                 float64_is_quiet_nan(farg2.d))) {
         ret = 0x01UL;
     } else if (float64_lt(farg1.d, farg2.d, &env->fp_status)) {
         ret = 0x08UL;
@@ -1575,8 +1575,8 @@  void helper_fcmpo (uint64_t arg1, uint64_t arg2, uint32_t crfD)
     farg1.ll = arg1;
     farg2.ll = arg2;
 
-    if (unlikely(float64_is_nan(farg1.d) ||
-                 float64_is_nan(farg2.d))) {
+    if (unlikely(float64_is_quiet_nan(farg1.d) ||
+                 float64_is_quiet_nan(farg2.d))) {
         ret = 0x01UL;
     } else if (float64_lt(farg1.d, farg2.d, &env->fp_status)) {
         ret = 0x08UL;
@@ -1938,7 +1938,7 @@  target_ulong helper_dlmzb (target_ulong high, target_ulong low, uint32_t update_
 /* If X is a NaN, store the corresponding QNaN into RESULT.  Otherwise,
  * execute the following block.  */
 #define DO_HANDLE_NAN(result, x)                \
-    if (float32_is_nan(x) || float32_is_signaling_nan(x)) {     \
+    if (float32_is_quiet_nan(x) || float32_is_signaling_nan(x)) {     \
         CPU_FloatU __f;                                         \
         __f.f = x;                                              \
         __f.l = __f.l | (1 << 22);  /* Set QNaN bit. */         \
@@ -2283,7 +2283,7 @@  void helper_vcmpbfp_dot (ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t *b)
         float_status s = env->vec_status;                               \
         set_float_rounding_mode(float_round_to_zero, &s);               \
         for (i = 0; i < ARRAY_SIZE(r->f); i++) {                        \
-            if (float32_is_nan(b->f[i]) ||                              \
+            if (float32_is_quiet_nan(b->f[i]) ||                              \
                 float32_is_signaling_nan(b->f[i])) {                    \
                 r->element[i] = 0;                                      \
             } else {                                                    \
@@ -3132,7 +3132,7 @@  static inline int32_t efsctsi(uint32_t val)
 
     u.l = val;
     /* NaN are not treated the same way IEEE 754 does */
-    if (unlikely(float32_is_nan(u.f)))
+    if (unlikely(float32_is_quiet_nan(u.f)))
         return 0;
 
     return float32_to_int32(u.f, &env->vec_status);
@@ -3144,7 +3144,7 @@  static inline uint32_t efsctui(uint32_t val)
 
     u.l = val;
     /* NaN are not treated the same way IEEE 754 does */
-    if (unlikely(float32_is_nan(u.f)))
+    if (unlikely(float32_is_quiet_nan(u.f)))
         return 0;
 
     return float32_to_uint32(u.f, &env->vec_status);
@@ -3156,7 +3156,7 @@  static inline uint32_t efsctsiz(uint32_t val)
 
     u.l = val;
     /* NaN are not treated the same way IEEE 754 does */
-    if (unlikely(float32_is_nan(u.f)))
+    if (unlikely(float32_is_quiet_nan(u.f)))
         return 0;
 
     return float32_to_int32_round_to_zero(u.f, &env->vec_status);
@@ -3168,7 +3168,7 @@  static inline uint32_t efsctuiz(uint32_t val)
 
     u.l = val;
     /* NaN are not treated the same way IEEE 754 does */
-    if (unlikely(float32_is_nan(u.f)))
+    if (unlikely(float32_is_quiet_nan(u.f)))
         return 0;
 
     return float32_to_uint32_round_to_zero(u.f, &env->vec_status);
@@ -3205,7 +3205,7 @@  static inline uint32_t efsctsf(uint32_t val)
 
     u.l = val;
     /* NaN are not treated the same way IEEE 754 does */
-    if (unlikely(float32_is_nan(u.f)))
+    if (unlikely(float32_is_quiet_nan(u.f)))
         return 0;
     tmp = uint64_to_float32(1ULL << 32, &env->vec_status);
     u.f = float32_mul(u.f, tmp, &env->vec_status);
@@ -3220,7 +3220,7 @@  static inline uint32_t efsctuf(uint32_t val)
 
     u.l = val;
     /* NaN are not treated the same way IEEE 754 does */
-    if (unlikely(float32_is_nan(u.f)))
+    if (unlikely(float32_is_quiet_nan(u.f)))
         return 0;
     tmp = uint64_to_float32(1ULL << 32, &env->vec_status);
     u.f = float32_mul(u.f, tmp, &env->vec_status);
@@ -3474,7 +3474,7 @@  uint32_t helper_efdctsi (uint64_t val)
 
     u.ll = val;
     /* NaN are not treated the same way IEEE 754 does */
-    if (unlikely(float64_is_nan(u.d)))
+    if (unlikely(float64_is_quiet_nan(u.d)))
         return 0;
 
     return float64_to_int32(u.d, &env->vec_status);
@@ -3486,7 +3486,7 @@  uint32_t helper_efdctui (uint64_t val)
 
     u.ll = val;
     /* NaN are not treated the same way IEEE 754 does */
-    if (unlikely(float64_is_nan(u.d)))
+    if (unlikely(float64_is_quiet_nan(u.d)))
         return 0;
 
     return float64_to_uint32(u.d, &env->vec_status);
@@ -3498,7 +3498,7 @@  uint32_t helper_efdctsiz (uint64_t val)
 
     u.ll = val;
     /* NaN are not treated the same way IEEE 754 does */
-    if (unlikely(float64_is_nan(u.d)))
+    if (unlikely(float64_is_quiet_nan(u.d)))
         return 0;
 
     return float64_to_int32_round_to_zero(u.d, &env->vec_status);
@@ -3510,7 +3510,7 @@  uint64_t helper_efdctsidz (uint64_t val)
 
     u.ll = val;
     /* NaN are not treated the same way IEEE 754 does */
-    if (unlikely(float64_is_nan(u.d)))
+    if (unlikely(float64_is_quiet_nan(u.d)))
         return 0;
 
     return float64_to_int64_round_to_zero(u.d, &env->vec_status);
@@ -3522,7 +3522,7 @@  uint32_t helper_efdctuiz (uint64_t val)
 
     u.ll = val;
     /* NaN are not treated the same way IEEE 754 does */
-    if (unlikely(float64_is_nan(u.d)))
+    if (unlikely(float64_is_quiet_nan(u.d)))
         return 0;
 
     return float64_to_uint32_round_to_zero(u.d, &env->vec_status);
@@ -3534,7 +3534,7 @@  uint64_t helper_efdctuidz (uint64_t val)
 
     u.ll = val;
     /* NaN are not treated the same way IEEE 754 does */
-    if (unlikely(float64_is_nan(u.d)))
+    if (unlikely(float64_is_quiet_nan(u.d)))
         return 0;
 
     return float64_to_uint64_round_to_zero(u.d, &env->vec_status);
@@ -3571,7 +3571,7 @@  uint32_t helper_efdctsf (uint64_t val)
 
     u.ll = val;
     /* NaN are not treated the same way IEEE 754 does */
-    if (unlikely(float64_is_nan(u.d)))
+    if (unlikely(float64_is_quiet_nan(u.d)))
         return 0;
     tmp = uint64_to_float64(1ULL << 32, &env->vec_status);
     u.d = float64_mul(u.d, tmp, &env->vec_status);
@@ -3586,7 +3586,7 @@  uint32_t helper_efdctuf (uint64_t val)
 
     u.ll = val;
     /* NaN are not treated the same way IEEE 754 does */
-    if (unlikely(float64_is_nan(u.d)))
+    if (unlikely(float64_is_quiet_nan(u.d)))
         return 0;
     tmp = uint64_to_float64(1ULL << 32, &env->vec_status);
     u.d = float64_mul(u.d, tmp, &env->vec_status);