From: Michael Morrell <mmorrell@tachyum.com>
To: Joseph Myers <joseph@codesourcery.com>
Cc: "libc-alpha@sourceware.org" <libc-alpha@sourceware.org>
Subject: RE: x86 Denormal flag
Date: Mon, 21 Jun 2021 20:44:44 +0000 [thread overview]
Message-ID: <27908b0e6bcd409ca29e418635908fff@tachyum.com> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2106211955160.1010016@digraph.polyomino.org.uk>
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
prev parent reply other threads:[~2021-06-21 20:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-19 1:09 Michael Morrell
2021-06-21 20:00 ` Joseph Myers
2021-06-21 20:44 ` Michael Morrell [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=27908b0e6bcd409ca29e418635908fff@tachyum.com \
--to=mmorrell@tachyum.com \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).