From: Joseph Myers <joseph@codesourcery.com>
To: Stefan Kanthak <stefan.kanthak@nexgo.de>
Cc: <gcc@gcc.gnu.org>
Subject: Re: Suboptimal code generated for __buitlin_trunc on AMD64 without SS4_4.1
Date: Mon, 9 Aug 2021 17:19:41 +0000 [thread overview]
Message-ID: <alpine.DEB.2.22.394.2108091706060.2508152@digraph.polyomino.org.uk> (raw)
In-Reply-To: <529D8A0E50484BD5A4C5DE4A44B7DF5C@H270>
On Sat, 7 Aug 2021, Stefan Kanthak wrote:
> Joseph Myers <joseph@codesourcery.com> wrote:
> > You should be looking at TS 18661-3 / C2x Annex F for sNaN handling;
>
> I'll do so as soon as GCC drops support for all C dialects before C2x!
>
> Unless you use a time machine and fix the POSIX and ISO C standards
> written in the past you CAN'T neglect all software written before C2x
> modified sNaN handling that relies on the documented behaviour at the
> time it was written.
Pre-C2x versions of C don't cover signaling NaNs at all; they use "NaN" to
mean "quiet NaN" (so signaling NaNs are trap representations). Software
written before C2x thus can't rely on any particular sNaN handling.
The POSIX description of signaling NaNs ("On implementations that support
the IEC 60559:1989 standard floating point, functions with signaling NaN
argument(s) shall be treated as if the function were called with an
argument that is a required domain error and shall return a quiet NaN
result, except where stated otherwise.") is consistent with C2x as regards
trunc (sNaN) needing to return a quiet NaN with INVALID raised. The
problems are (a) POSIX fails to "state otherwise" for the cases (e.g.
fabs, copysign) where a signaling NaN argument should not result in a
quiet NaN with INVALID raised (as per IEEE semantics for those operations)
and (b) the POSIX rule about setting errno to EDOM when (math_errhandling
& MATH_ERRNO) is nonzero is inappropriate for sNaN arguments (incompatible
with the normal approach of generating INVALID and a quiet NaN by passing
NaN arguments through arithmetic) and the C2x approach of being
implementation-defined whether an sNaN input is a domain error is more
appropriate.
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2021-08-09 17:19 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-05 7:25 Stefan Kanthak
2021-08-05 9:42 ` Gabriel Paubert
2021-08-05 10:19 ` Richard Biener
2021-08-05 11:58 ` Stefan Kanthak
2021-08-05 13:59 ` Gabriel Paubert
2021-08-06 12:43 ` Stefan Kanthak
2021-08-06 12:59 ` Richard Biener
2021-08-06 13:20 ` Gabriel Paubert
2021-08-06 14:37 ` Stefan Kanthak
2021-08-06 17:44 ` Joseph Myers
2021-08-07 12:32 ` Stefan Kanthak
2021-08-08 22:58 ` Vincent Lefevre
2021-08-09 17:19 ` Joseph Myers [this message]
2021-08-06 13:31 ` Michael Matz
2021-08-06 14:32 ` Stefan Kanthak
2021-08-06 15:04 ` Michael Matz
2021-08-06 15:16 ` Richard Biener
2021-08-06 16:57 ` Stefan Kanthak
2021-08-05 13:18 ` Gabriel Ravier
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=alpine.DEB.2.22.394.2108091706060.2508152@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=gcc@gcc.gnu.org \
--cc=stefan.kanthak@nexgo.de \
/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).