| Message ID | 1292601366-990-1-git-send-email-peter.maydell@linaro.org |
|---|---|
| State | New |
| Headers | show |
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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.
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);