public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Joseph Myers <joseph@codesourcery.com>
To: Andreas Krebbel <krebbel@linux.vnet.ibm.com>
Cc: <libc-alpha@sourceware.org>, <stli@linux.vnet.ibm.com>
Subject: Re: Fix sysdeps/ieee754 pow handling of sNaN arguments (bug 20916) [committed]
Date: Wed, 14 Dec 2016 17:22:00 -0000	[thread overview]
Message-ID: <alpine.DEB.2.20.1612141719550.32751@digraph.polyomino.org.uk> (raw)
In-Reply-To: <20161214095352.GA17128@maggie>

On Wed, 14 Dec 2016, Andreas Krebbel wrote:

> The problem with the load and test instruction is that it is not
> consistent to doing a load and a compare separately.  Our floating
> point loads do not quiet a NaN.
> 
> While the IEEE standard leaves it open to quiet NaNs with loads it is
> probably supposed to be the same for all loads.
> 
> The plan is to disable the use of the FPR result of a load-and-test
> instruction in the compiler.  We would leave the Glibc tests failing
> since this appears to be a real finding to me.
> 
> Does this sound reasonable?

It sounds reasonable, given the quality-of-implementation goal to allow 
signaling NaNs to be copied without quieting.  If using that FPR result is 
useful for optimization, and harmless in the absence of signaling NaNs, of 
course you could restrict the disabling to the -fsignaling-nans case (and 
arrange for pow to be built with that option in glibc for s390).

-- 
Joseph S. Myers
joseph@codesourcery.com

      reply	other threads:[~2016-12-14 17:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-02 23:22 Joseph Myers
2016-12-12 16:43 ` Stefan Liebler
2016-12-13 21:42   ` Joseph Myers
2016-12-14  9:54     ` Andreas Krebbel
2016-12-14 17:22       ` Joseph Myers [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=alpine.DEB.2.20.1612141719550.32751@digraph.polyomino.org.uk \
    --to=joseph@codesourcery.com \
    --cc=krebbel@linux.vnet.ibm.com \
    --cc=libc-alpha@sourceware.org \
    --cc=stli@linux.vnet.ibm.com \
    /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).