* x86 Denormal flag @ 2021-06-19 1:09 Michael Morrell 2021-06-21 20:00 ` Joseph Myers 0 siblings, 1 reply; 3+ messages in thread From: Michael Morrell @ 2021-06-19 1:09 UTC (permalink / raw) To: libc-alpha Should fetestexcept be able to test for the denormal flag in the MXCSR? My test case is: define _GNU_SOURCE #include <fenv.h> #include <stdio.h> #include <xmmintrin.h> volatile float two = 2.0f; volatile float den = 0x1.0p-130; int main() { volatile float r; r = den / two; if (_mm_getcsr() & _MM_EXCEPT_DENORM) printf("mxcsr has DENORM bit set\n"); if (fetestexcept(__FE_DENORM)) printf("DENORM is set\n"); return 0; } And it shows that the Denormal flag is set in MXCSR, but fetestexcept returns 0 here. It seems like fetestexcept only works for the 5 standard IEEE flags, but then why is __FE_DENORM even defined? Michael ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: x86 Denormal flag 2021-06-19 1:09 x86 Denormal flag Michael Morrell @ 2021-06-21 20:00 ` Joseph Myers 2021-06-21 20:44 ` Michael Morrell 0 siblings, 1 reply; 3+ messages in thread From: Joseph Myers @ 2021-06-21 20:00 UTC (permalink / raw) To: Michael Morrell; +Cc: libc-alpha On Sat, 19 Jun 2021, Michael Morrell wrote: > It seems like fetestexcept only works for the 5 standard IEEE flags, but > then why is __FE_DENORM even defined? It would probably be reasonable to move __FE_DENORM from an installed header to an internal one that's only used by the fesetenv and fesetmode implementations that need to work on the environment (or the control mode parts of the environment) as a whole, including implementation-defined parts of the environment. I think including the "denormal operand" flag in FE_ALL_EXCEPT would be a bad idea, since it doesn't indicate any kind of exceptional condition in standard terms, and given that it's not in FE_ALL_EXCEPT, treating it as an exception in other standard functions would be problematic. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: x86 Denormal flag 2021-06-21 20:00 ` Joseph Myers @ 2021-06-21 20:44 ` Michael Morrell 0 siblings, 0 replies; 3+ messages in thread From: Michael Morrell @ 2021-06-21 20:44 UTC (permalink / raw) To: Joseph Myers; +Cc: libc-alpha I guess I'm not convinced that adding the denormal operand flag in FE_ALL_EXCEPT is bad. From a quick grep, I think this flag is defined in the following architectures: ia64 (FE_UNNORMAL), alpha (FE_DENORMAL), csky (__FE_DENORMAL), and x86 (__FE_DENORM). AARCH64 also has this flag (the IDC bit in FPSR), but glibc does not define an FE_ constant for it. For ia64, FE_ALL_EXCEPT includes FE_UNNORMAL, but none of the others seems to include it so that is kind of inconsistent. Michael -----Original Message----- From: Joseph Myers <joseph@codesourcery.com> Sent: Monday, June 21, 2021 1:01 PM To: Michael Morrell <mmorrell@tachyum.com> Cc: libc-alpha@sourceware.org Subject: Re: x86 Denormal flag On Sat, 19 Jun 2021, Michael Morrell wrote: > It seems like fetestexcept only works for the 5 standard IEEE flags, > but then why is __FE_DENORM even defined? It would probably be reasonable to move __FE_DENORM from an installed header to an internal one that's only used by the fesetenv and fesetmode implementations that need to work on the environment (or the control mode parts of the environment) as a whole, including implementation-defined parts of the environment. I think including the "denormal operand" flag in FE_ALL_EXCEPT would be a bad idea, since it doesn't indicate any kind of exceptional condition in standard terms, and given that it's not in FE_ALL_EXCEPT, treating it as an exception in other standard functions would be problematic. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-06-21 20:44 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-06-19 1:09 x86 Denormal flag Michael Morrell 2021-06-21 20:00 ` Joseph Myers 2021-06-21 20:44 ` Michael Morrell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).