public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
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

  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).