* Math errors
@ 2019-12-30 19:59 Alistair Francis
2019-12-30 22:28 ` Joseph Myers
0 siblings, 1 reply; 13+ messages in thread
From: Alistair Francis @ 2019-12-30 19:59 UTC (permalink / raw)
To: GNU C Library
Hey,
I'm running the `make check` tests on RV32 inside QEMU and about 800
math tests are failing with errors along these lines:
$ cat math/test-double-erf.out
Failure: Test: erf (0x1.4p+0)
Result:
is: 9.2290012825645817e-01 0x1.d8865d98abe00p-1
should be: 9.2290012825645829e-01 0x1.d8865d98abe01p-1
difference: 1.1102230246251565e-16 0x1.0000000000000p-53
ulp : 1.0000
max.ulp : 0.0000
Maximal error of `erf'
is : 1 ulp
accepted: 0 ulp
Failure: Test: erf_downward (-0x1.4d32f4p-12)
Result:
is: -3.5855754629430663e-04 -0x1.77f98ef609eb3p-12
should be: -3.5855754629430669e-04 -0x1.77f98ef609eb4p-12
difference: 5.4210108624275221e-20 0x1.0000000000000p-64
ulp : 1.0000
max.ulp : 0.0000
Failure: Test: erf_downward (0x1.44e722p+0)
Result:
is: 9.2732266856644440e-01 0x1.daca096caa26ap-1
should be: 9.2732266856644429e-01 0x1.daca096caa269p-1
difference: 1.1102230246251565e-16 0x1.0000000000000p-53
It seems the tests are failing due to small differences in the
floating point values.
Has anyone seen this before? I don't see how this can be related
specifically to the RV32 port, but I didn't see these errors when
running the ARM 32-bit testing. It's possible we are loosing
information in the QEMU floating point implementation for RV32.
Alistair
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Math errors
2019-12-30 19:59 Math errors Alistair Francis
@ 2019-12-30 22:28 ` Joseph Myers
2019-12-30 22:29 ` Joseph Myers
0 siblings, 1 reply; 13+ messages in thread
From: Joseph Myers @ 2019-12-30 22:28 UTC (permalink / raw)
To: Alistair Francis; +Cc: GNU C Library
On Mon, 30 Dec 2019, Alistair Francis wrote:
> Hey,
>
> I'm running the `make check` tests on RV32 inside QEMU and about 800
> math tests are failing with errors along these lines:
You need to generate libm-test-ulps for RV32 ("make regen-ulps") (also
remember to create a corresponding libm-test-ulps-name file for use in
generating the table in the manual).
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Math errors
2019-12-30 22:28 ` Joseph Myers
@ 2019-12-30 22:29 ` Joseph Myers
2020-01-03 2:18 ` Alistair Francis
0 siblings, 1 reply; 13+ messages in thread
From: Joseph Myers @ 2019-12-30 22:29 UTC (permalink / raw)
To: Alistair Francis; +Cc: GNU C Library
On Mon, 30 Dec 2019, Joseph Myers wrote:
> On Mon, 30 Dec 2019, Alistair Francis wrote:
>
> > Hey,
> >
> > I'm running the `make check` tests on RV32 inside QEMU and about 800
> > math tests are failing with errors along these lines:
>
> You need to generate libm-test-ulps for RV32 ("make regen-ulps") (also
> remember to create a corresponding libm-test-ulps-name file for use in
> generating the table in the manual).
I should add: first try renaming the RV64 libm-test-ulps to make it
generic for both RV32 and RV64. You should only need a separate file for
RV32 if there is a clear reason for different results between the two.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Math errors
2019-12-30 22:29 ` Joseph Myers
@ 2020-01-03 2:18 ` Alistair Francis
2020-01-03 9:30 ` Szabolcs Nagy
2020-01-07 1:29 ` Jim Wilson
0 siblings, 2 replies; 13+ messages in thread
From: Alistair Francis @ 2020-01-03 2:18 UTC (permalink / raw)
To: Joseph Myers; +Cc: GNU C Library
On Mon, Dec 30, 2019 at 2:29 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Mon, 30 Dec 2019, Joseph Myers wrote:
>
> > On Mon, 30 Dec 2019, Alistair Francis wrote:
> >
> > > Hey,
> > >
> > > I'm running the `make check` tests on RV32 inside QEMU and about 800
> > > math tests are failing with errors along these lines:
> >
> > You need to generate libm-test-ulps for RV32 ("make regen-ulps") (also
> > remember to create a corresponding libm-test-ulps-name file for use in
> > generating the table in the manual).
>
> I should add: first try renaming the RV64 libm-test-ulps to make it
> generic for both RV32 and RV64. You should only need a separate file for
> RV32 if there is a clear reason for different results between the two.
Thanks Joseph,
I moved the RV64 one to be generic and that seems to fix most of the
math tests. I tried `make regen-ulps` after that, just to be sure, and
it didn't generate a diff.
There are a handful of math tests that seem to fail, but if I manually
run the test a few times I will eventually get a pass. Any hints on
what to do there?
Alistair
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Math errors
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
1 sibling, 1 reply; 13+ messages in thread
From: Szabolcs Nagy @ 2020-01-03 9:30 UTC (permalink / raw)
To: Alistair Francis, Joseph Myers; +Cc: nd, GNU C Library
On 03/01/2020 02:18, Alistair Francis wrote:
> On Mon, Dec 30, 2019 at 2:29 PM Joseph Myers <joseph@codesourcery.com> wrote:
>>
>> On Mon, 30 Dec 2019, Joseph Myers wrote:
>>
>>> On Mon, 30 Dec 2019, Alistair Francis wrote:
>>>
>>>> Hey,
>>>>
>>>> I'm running the `make check` tests on RV32 inside QEMU and about 800
>>>> math tests are failing with errors along these lines:
>>>
>>> You need to generate libm-test-ulps for RV32 ("make regen-ulps") (also
>>> remember to create a corresponding libm-test-ulps-name file for use in
>>> generating the table in the manual).
>>
>> I should add: first try renaming the RV64 libm-test-ulps to make it
>> generic for both RV32 and RV64. You should only need a separate file for
>> RV32 if there is a clear reason for different results between the two.
>
> Thanks Joseph,
>
> I moved the RV64 one to be generic and that seems to fix most of the
> math tests. I tried `make regen-ulps` after that, just to be sure, and
> it didn't generate a diff.
regen-ulps should create a math/NewUlps file.
(details are in math/README.libm-test)
>
> There are a handful of math tests that seem to fail, but if I manually
> run the test a few times I will eventually get a pass. Any hints on
> what to do there?
flaky math test is not normal, you need to investigate.
>
> Alistair
>
>>
>> --
>> Joseph S. Myers
>> joseph@codesourcery.com
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Math errors
2020-01-03 9:30 ` Szabolcs Nagy
@ 2020-01-04 18:09 ` Alistair Francis
0 siblings, 0 replies; 13+ messages in thread
From: Alistair Francis @ 2020-01-04 18:09 UTC (permalink / raw)
To: Szabolcs Nagy; +Cc: Joseph Myers, nd, GNU C Library
On Fri, Jan 3, 2020 at 1:30 AM Szabolcs Nagy <Szabolcs.Nagy@arm.com> wrote:
>
> On 03/01/2020 02:18, Alistair Francis wrote:
> > On Mon, Dec 30, 2019 at 2:29 PM Joseph Myers <joseph@codesourcery.com> wrote:
> >>
> >> On Mon, 30 Dec 2019, Joseph Myers wrote:
> >>
> >>> On Mon, 30 Dec 2019, Alistair Francis wrote:
> >>>
> >>>> Hey,
> >>>>
> >>>> I'm running the `make check` tests on RV32 inside QEMU and about 800
> >>>> math tests are failing with errors along these lines:
> >>>
> >>> You need to generate libm-test-ulps for RV32 ("make regen-ulps") (also
> >>> remember to create a corresponding libm-test-ulps-name file for use in
> >>> generating the table in the manual).
> >>
> >> I should add: first try renaming the RV64 libm-test-ulps to make it
> >> generic for both RV32 and RV64. You should only need a separate file for
> >> RV32 if there is a clear reason for different results between the two.
> >
> > Thanks Joseph,
> >
> > I moved the RV64 one to be generic and that seems to fix most of the
> > math tests. I tried `make regen-ulps` after that, just to be sure, and
> > it didn't generate a diff.
>
> regen-ulps should create a math/NewUlps file.
> (details are in math/README.libm-test)
Yep, I just meant that I diffed that to the RV64 one.
>
> >
> > There are a handful of math tests that seem to fail, but if I manually
> > run the test a few times I will eventually get a pass. Any hints on
> > what to do there?
>
> flaky math test is not normal, you need to investigate.
It turns out that there is a difference between libm-test-ulps for
RV32 and RV64. The gen-libm-test.py script was failing to run as I
don't have Python2 installed, so the file wasn't being updated. If I
manually run the script with Python3 I can generate a libm-test-ulps
file that is somewhat different to the RV64 one.
I'm running the tests now, but hopefully that fixes the failing math test cases.
Alistair
>
> >
> > Alistair
> >
> >>
> >> --
> >> Joseph S. Myers
> >> joseph@codesourcery.com
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Math errors
2020-01-03 2:18 ` Alistair Francis
2020-01-03 9:30 ` Szabolcs Nagy
@ 2020-01-07 1:29 ` Jim Wilson
2020-01-07 1:33 ` Alistair Francis
1 sibling, 1 reply; 13+ messages in thread
From: Jim Wilson @ 2020-01-07 1:29 UTC (permalink / raw)
To: Alistair Francis; +Cc: Joseph Myers, GNU C Library
On Thu, Jan 2, 2020 at 6:18 PM Alistair Francis <alistair23@gmail.com> wrote:
> There are a handful of math tests that seem to fail, but if I manually
> run the test a few times I will eventually get a pass. Any hints on
> what to do there?
There is a known bug in the RISC-V linux port where FP regs can leak
across fork and exec. This is normally not a fatal problem, except
for some tests that assume that the FP exception flags are clear on
program start. This can be false if they were set in the parent
process, which can cause some glibc math test failures. This can
result in failures that appear/disappear when run manually versus from
the testsuite driver. There are only about 5 tests that are affected.
The bug was finally fixed about a year and a half after I first
reported it. That happened only a few months ago. If you don't have
a recent enough version of the linux kernel you may not have the fix.
Jim
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Math errors
2020-01-07 1:29 ` Jim Wilson
@ 2020-01-07 1:33 ` Alistair Francis
2020-01-07 18:29 ` Jim Wilson
0 siblings, 1 reply; 13+ messages in thread
From: Alistair Francis @ 2020-01-07 1:33 UTC (permalink / raw)
To: Jim Wilson; +Cc: Joseph Myers, GNU C Library
On Mon, Jan 6, 2020 at 5:29 PM Jim Wilson <jimw@sifive.com> wrote:
>
> On Thu, Jan 2, 2020 at 6:18 PM Alistair Francis <alistair23@gmail.com> wrote:
> > There are a handful of math tests that seem to fail, but if I manually
> > run the test a few times I will eventually get a pass. Any hints on
> > what to do there?
>
> There is a known bug in the RISC-V linux port where FP regs can leak
> across fork and exec. This is normally not a fatal problem, except
> for some tests that assume that the FP exception flags are clear on
> program start. This can be false if they were set in the parent
> process, which can cause some glibc math test failures. This can
> result in failures that appear/disappear when run manually versus from
> the testsuite driver. There are only about 5 tests that are affected.
> The bug was finally fixed about a year and a half after I first
> reported it. That happened only a few months ago. If you don't have
> a recent enough version of the linux kernel you may not have the fix.
Thanks for that Jim.
I have the latest 5.4.x kernel, I'm not sure if that has it or not.
I see a lot of math failures, so I'm not sure if it's the same issue.
Right now I have all of these failing:
FAIL: math/atest-exp
FAIL: math/atest-exp2
FAIL: math/atest-sincos
FAIL: math/test-double-cacos
FAIL: math/test-double-cosh
FAIL: math/test-double-fromfpx
FAIL: math/test-double-islessgreater
FAIL: math/test-double-iszero
FAIL: math/test-double-jn
FAIL: math/test-double-llrint
FAIL: math/test-double-log1p
FAIL: math/test-double-ufromfp
UNSUPPORTED: math/test-fesetexcept-traps
UNSUPPORTED: math/test-fexcept-traps
FAIL: math/test-float-cabs
FAIL: math/test-float-ilogb
FAIL: math/test-float-isnormal
FAIL: math/test-float-ldouble-div
FAIL: math/test-float128-fmod
FAIL: math/test-float128-iseqsig
FAIL: math/test-float128-ufromfpx
FAIL: math/test-float32-catan
FAIL: math/test-float32-csinh
FAIL: math/test-float32-float64x-add
FAIL: math/test-float32-iszero
FAIL: math/test-float32-jn
FAIL: math/test-float32-significand
FAIL: math/test-float32-sincos
FAIL: math/test-float32-tanh
FAIL: math/test-float32-yn
FAIL: math/test-float32x-asinh
FAIL: math/test-float32x-exp
FAIL: math/test-float32x-log10
FAIL: math/test-float32x-yn
FAIL: math/test-float64-asinh
FAIL: math/test-float64-canonicalize
FAIL: math/test-float64-getpayload
FAIL: math/test-float64-j1
FAIL: math/test-float64-jn
FAIL: math/test-float64x-cexp
FAIL: math/test-float64x-ctanh
FAIL: math/test-idouble-acos
FAIL: math/test-idouble-catanh
FAIL: math/test-idouble-copysign
FAIL: math/test-idouble-csinh
FAIL: math/test-idouble-erf
FAIL: math/test-idouble-fminmag
FAIL: math/test-idouble-hypot
FAIL: math/test-idouble-lgamma
FAIL: math/test-idouble-log1p
FAIL: math/test-idouble-setpayload
FAIL: math/test-ifloat-cacos
FAIL: math/test-ifloat-cacosh
FAIL: math/test-ifloat-casin
FAIL: math/test-ifloat-erf
FAIL: math/test-ifloat-llround
FAIL: math/test-ifloat-pow
FAIL: math/test-ifloat-setpayload
FAIL: math/test-ifloat-sincos
FAIL: math/test-ifloat-tan
FAIL: math/test-ifloat-tgamma
FAIL: math/test-ifloat128-ctan
FAIL: math/test-ifloat128-j0
FAIL: math/test-ifloat32-clog10
FAIL: math/test-ifloat32-issignaling
FAIL: math/test-ifloat32x-cpow
FAIL: math/test-ifloat32x-fmaxmag
FAIL: math/test-ifloat32x-j0
FAIL: math/test-ifloat32x-remainder
FAIL: math/test-ifloat64-cexp
FAIL: math/test-ifloat64-floor
FAIL: math/test-ifloat64-fmod
FAIL: math/test-ifloat64-lrint
FAIL: math/test-ifloat64-sincos
FAIL: math/test-ildouble-lgamma
FAIL: math/test-ldouble-exp
FAIL: math/test-ldouble-fmod
FAIL: math/test-ldouble-ilogb
UNSUPPORTED: math/test-matherr
UNSUPPORTED: math/test-matherr-2
UNSUPPORTED: math/test-nearbyint-except-2
Alistair
>
> Jim
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Math errors
2020-01-07 1:33 ` Alistair Francis
@ 2020-01-07 18:29 ` Jim Wilson
2020-01-14 2:11 ` Alistair Francis
0 siblings, 1 reply; 13+ messages in thread
From: Jim Wilson @ 2020-01-07 18:29 UTC (permalink / raw)
To: Alistair Francis; +Cc: Joseph Myers, GNU C Library
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Math errors
2020-01-07 18:29 ` Jim Wilson
@ 2020-01-14 2:11 ` Alistair Francis
2020-01-14 2:29 ` Jonathan Nieder
0 siblings, 1 reply; 13+ messages in thread
From: Alistair Francis @ 2020-01-14 2:11 UTC (permalink / raw)
To: Jim Wilson; +Cc: Joseph Myers, GNU C Library
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
> 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
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.
Alistair
> problems. That of course assumes you have an up-to-date ulps file as
> Joseph already mentioned.
>
> Jim
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Math errors
2020-01-14 2:11 ` Alistair Francis
@ 2020-01-14 2:29 ` Jonathan Nieder
2020-01-14 4:57 ` Alistair Francis
0 siblings, 1 reply; 13+ messages in thread
From: Jonathan Nieder @ 2020-01-14 2:29 UTC (permalink / raw)
To: Alistair Francis; +Cc: Jim Wilson, Joseph Myers, GNU C Library
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Math errors
2020-01-14 2:29 ` Jonathan Nieder
@ 2020-01-14 4:57 ` Alistair Francis
2020-01-14 7:28 ` Alistair Francis
0 siblings, 1 reply; 13+ messages in thread
From: Alistair Francis @ 2020-01-14 4:57 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Jim Wilson, Joseph Myers, GNU C Library
On Tue, Jan 14, 2020 at 12:28 PM Jonathan Nieder <jrnieder@gmail.com> wrote:
>
> 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 don't have it in front of me right now, but it's 5.4.x and built
from OpenEmbedded.
>
> 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.
It could be a QEMU issue:
https://lists.gnu.org/archive/html/qemu-devel/2020-01/msg02455.html
Alistair
>
> [...]
> >> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Math errors
2020-01-14 4:57 ` Alistair Francis
@ 2020-01-14 7:28 ` Alistair Francis
0 siblings, 0 replies; 13+ messages in thread
From: Alistair Francis @ 2020-01-14 7:28 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Jim Wilson, Joseph Myers, GNU C Library
On Tue, Jan 14, 2020 at 2:57 PM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Tue, Jan 14, 2020 at 12:28 PM Jonathan Nieder <jrnieder@gmail.com> wrote:
> >
> > 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 don't have it in front of me right now, but it's 5.4.x and built
> from OpenEmbedded.
# uname -r
5.4.7
Alistair
>
> >
> > 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.
>
> It could be a QEMU issue:
> https://lists.gnu.org/archive/html/qemu-devel/2020-01/msg02455.html
>
> Alistair
>
> >
> > [...]
> > >> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2020-01-14 7:28 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-30 19:59 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:33 ` Alistair Francis
2020-01-07 18:29 ` Jim Wilson
2020-01-14 2:11 ` Alistair Francis
2020-01-14 2:29 ` Jonathan Nieder
2020-01-14 4:57 ` Alistair Francis
2020-01-14 7:28 ` Alistair Francis
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).