unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Alistair Francis <alistair23@gmail.com>
Cc: Jim Wilson <jimw@sifive.com>,
	Joseph Myers <joseph@codesourcery.com>,
	GNU C Library <libc-alpha@sourceware.org>
Subject: Re: Math errors
Date: Tue, 14 Jan 2020 02:28:56 +0000	[thread overview]
Message-ID: <20200114022856.GA24302@google.com> (raw)
In-Reply-To: <CAKmqyKOSqsUeADkB3KDCxj67AHix7jrexDetRcG-xLbQVr3E7g@mail.gmail.com>

Hi,

Alistair Francis wrote:
> On Wed, Jan 8, 2020 at 4:29 AM Jim Wilson <jimw@sifive.com> wrote:
>> 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
>
> I have noticed that running the tests not in parallel gives much better results

Interesting.  Can you provide full "uname -r" output?  What Linux
distribution do you use?

I suspect the issue Jim mentioned is fixed by v5.3-rc5~12^2~1 ("riscv:
Correct the initialized flow of FP register", 2019-08-14), which you
would already have.  That said, the 5.5-rc series has some more fp reg
handling fixes.

[...]
>> 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
>
> Yeah, that's what I was thinking. There are only a few math tests left
> failing, so it's not too bad. Thanks for the information Jim.

That it appears more often with threading does suggest some kind of FP
register leakage.

Thanks and happy hunting,
Jonathan

  reply	other threads:[~2020-01-14  2: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
2020-01-14  2:10             ` Alistair Francis
2020-01-14  2:28               ` Jonathan Nieder [this message]
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=20200114022856.GA24302@google.com \
    --to=jrnieder@gmail.com \
    --cc=alistair23@gmail.com \
    --cc=jimw@sifive.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).