unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Jim Wilson <jimw@sifive.com>
To: Alistair Francis <alistair23@gmail.com>
Cc: Joseph Myers <joseph@codesourcery.com>,
	GNU C Library <libc-alpha@sourceware.org>
Subject: Re: Math errors
Date: Tue, 7 Jan 2020 10:29:37 -0800	[thread overview]
Message-ID: <CAFyWVaYFRAVd7bWTGpw-iqYn3iwEVwT7B=PQpjaD_gOC+=Pcbg@mail.gmail.com> (raw)
In-Reply-To: <CAKmqyKOfm8pcJYPkZyp89WL+t7WMnmRJL3rXALYokj1A3pdu8g@mail.gmail.com>

On Mon, Jan 6, 2020 at 5:33 PM Alistair Francis <alistair23@gmail.com> wrote:
> I have the latest 5.4.x kernel, I'm not sure if that has it or not.

I don't know.  I don't follow linux kernel development that closely.
But the failures I sometimes see are test-fenv and test-fpucw which I
don't see in your list.

I only run glibc testsuite on hardware though, and I've only been
testing rv64gc support.  I haven't tried qemu.  In the RISC-V software
meeting this morning, Palmer mentioned that there are some known
RISC-V qemu FP bugs, for instance fcmp doesn't set the FP reg dirty
bit when an exception flag is set, which could cause a testcase
failure if a context switch happens at the wrong time.  This could
cause tests to sometimes fail and sometimes work.  I have seen some
RISC-V qemu FP bugs myself, for instance with NaN-boxing, where
sometimes single float outputs aren't NaN-boxed, and sometimes
non-NaN-boxed single float inputs don't cause failures.  This is a
problem I noticed by accident, I don't know if that has been fixed
yet, and I don't know if that would cause glibc testsuite failures.
Someone will have to look at the rv32gc math failures, and keep an
open mind that they could be glibc, qemu, gcc, linux kernel, etc
problems.  That of course assumes you have an up-to-date ulps file as
Joseph already mentioned.

Jim

  reply	other threads:[~2020-01-07 18:29 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-30 19:52 Math errors Alistair Francis
2019-12-30 22:28 ` Joseph Myers
2019-12-30 22:29   ` Joseph Myers
2020-01-03  2:18     ` Alistair Francis
2020-01-03  9:30       ` Szabolcs Nagy
2020-01-04 18:09         ` Alistair Francis
2020-01-07  1:29       ` Jim Wilson
2020-01-07  1:32         ` Alistair Francis
2020-01-07 18:29           ` Jim Wilson [this message]
2020-01-14  2:10             ` Alistair Francis
2020-01-14  2:28               ` Jonathan Nieder
2020-01-14  4:57                 ` Alistair Francis
2020-01-14  7:28                   ` Alistair Francis

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

  List information: https://www.gnu.org/software/libc/involved.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFyWVaYFRAVd7bWTGpw-iqYn3iwEVwT7B=PQpjaD_gOC+=Pcbg@mail.gmail.com' \
    --to=jimw@sifive.com \
    --cc=alistair23@gmail.com \
    --cc=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    /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).