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
next prev parent 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).