mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: leijitang <leijitang@huawei.com>
Cc: "musl@lists.openwall.com" <musl@lists.openwall.com>,
	"zhangwentao (M)" <zhangwentao234@huawei.com>,
	"wanghao (H)" <wanghao293@huawei.com>,
	"Huangqiang (H)" <h.huangqiang@huawei.com>
Subject: Re: [musl] Unexpected exceptions in  math functions
Date: Wed, 22 Apr 2020 12:16:59 -0400	[thread overview]
Message-ID: <20200422161659.GM11469@brightrain.aerifal.cx> (raw)
In-Reply-To: <A157A71BEF653F4BB32E06650E67C99323A48532@dggemm514-mbx.china.huawei.com>

On Wed, Apr 22, 2020 at 01:56:46PM +0000, leijitang wrote:
> Hi all,
> 
> Recently we update musl in our project from 1.1.2 to version 1.2.0. But there are some errors about math functions when running
> the opensource test cases for musl, which are passed in musl 1.1.2. These errors are about exp2(), pow() and powf().
> Logs are listed below.
> According to the commit message, the underflow exception is signaled if the result is in the subnormal range even if
> the result is exact (e.g. exp2(-1023.0)). But we got INEXACT exception at the same time, which is not as expected.
> Is this a problem?

For practical purposes, probably not, because basically nothing uses
fenv, and clang doesn't even support it (its optimizer makes invalid
transformations that will break use of fenv).

Strictly speaking, yes, and this should be fixed. exp2 with integer
argument should behave like scalbn/ldexp.

> Otherwise, there is a overflow exception in powf(0x1.fffffep+127,0x1p+0) with FE_UPWARD rounding mode(log is also behind. As
> 0x1.fffffep+127 is the largest number that float can represent, there should not be INEXACT|OVERFLOW exceptions.

I think that's correct. pow has various special cases that should be
exact, but catching them all to make sure they're exact is a bit of
work, and possibly hard to do without impacting the performance of
common cases. Still, use of pow in ways that should be exact is common
enough that I think this should be fixed.

> If these are problems affirmed, is there any patch to fix this?

Not yet.

  reply	other threads:[~2020-04-22 16:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-22 13:56 leijitang
2020-04-22 16:16 ` Rich Felker [this message]
2020-04-22 16:32   ` Rich Felker
2020-04-22 17:16 ` Szabolcs Nagy

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=20200422161659.GM11469@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=h.huangqiang@huawei.com \
    --cc=leijitang@huawei.com \
    --cc=musl@lists.openwall.com \
    --cc=wanghao293@huawei.com \
    --cc=zhangwentao234@huawei.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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

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 NNTP newsgroup(s).