public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Joseph Myers <joseph@codesourcery.com>
To: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
Cc: Matheus Castanho <msc@linux.ibm.com>,
	Carlos O'Donell <carlos@redhat.com>,  <libc-alpha@sourceware.org>,
	<patsy@redhat.com>
Subject: Re: [PATCH v2] powerpc: Update ULPs and output for j0 with ibm128
Date: Thu, 10 Sep 2020 15:07:03 +0000	[thread overview]
Message-ID: <alpine.DEB.2.21.2009101502290.11907@digraph.polyomino.org.uk> (raw)
In-Reply-To: <87een93g2f.fsf@linux.ibm.com>

On Thu, 10 Sep 2020, Tulio Magno Quites Machado Filho via Libc-alpha wrote:

> Carlos, Joseph,
> 
> I'm afraid that Matheus is either in a deadlock or we need a clearer
> explanation of what is acceptable for ibm128.
> 
> Notice that Matheus' first patch was rejected because results were greater
> than 9.
> 
> With that said, would both of you accept the first version of this patch?
> https://patchwork.sourceware.org/project/glibc/patch/20200820183700.115087-1-msc@linux.ibm.com/

The first version is appropriate.  The bigger limits for ibm128 are 
deliberate.  An architecture-specific ulps update should not be rejected 
just because it increases ulps within the bounds accepted for that format 
(and you shouldn't be able to get an update that increases them outside 
those bounds unless you edit the ulps file manually, and if you do edit it 
manually then the ulps it lists outside those bounds will be ignored 
anyway).

The most likely reason for rejecting an ulps update is that new ulps are 
greater than for other architectures using the same code in glibc for the 
same functions for the same format, suggesting that the update is actually 
covering up a bug somewhere else.  This doesn't apply in this case.

(If an ulps increase results from a change to the implementation of a libm 
functions that makes it less accurate in some cases, we need to consider 
if we want that change, but that's deciding whether we want the libm 
change, not deciding whether we want the ulps updates consequent on it.)

-- 
Joseph S. Myers
joseph@codesourcery.com

  reply	other threads:[~2020-09-10 15:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-09 16:58 Matheus Castanho
2020-09-09 17:17 ` Joseph Myers
2020-09-10 13:40   ` Tulio Magno Quites Machado Filho
2020-09-10 15:07     ` Joseph Myers [this message]
2020-09-10 18:52       ` Tulio Magno Quites Machado Filho
2020-09-10 17:08     ` Carlos O'Donell
2020-09-10 17:29       ` Matheus Castanho

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.21.2009101502290.11907@digraph.polyomino.org.uk \
    --to=joseph@codesourcery.com \
    --cc=carlos@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=msc@linux.ibm.com \
    --cc=patsy@redhat.com \
    --cc=tuliom@linux.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).