Missing Underflow float exceptions in some cases (XuanTie Group explained) #17
Comments
|
Adding some test results: This suggests that C906 could be affected too. |
|
Minimal assembly reproduction: #!/bin/sh
cat <<EOF | as -o thead_bug_probe.o -
.global _start
_start:
li a3,0x41
fscsr a3
li a1, 0xb80fffffc000007f
fmv.d.x fa5, a1
fcvt.s.d fa0, fa5
frflags a0
li a7, 93
ecall
EOF
ld thead_bug_probe.o -o thead_bug_probe
./thead_bug_probe
echo $?Expected output: 3 |
|
I have tried to run berkeley's testfloat which compares against a softfloat implementation, suggested by @sequencer Here are all the failed test cases: |
|
What a shame. |
|
Unbelievable |
|
CC @chainsx |
|
c908 (kendryte k230) test success |
Can you send this to LKML? We should be dynamically probing for this behavior and marking it as an errata for userspace. |
|
Do we have any information on whether this problem is fixable in a way that can be used in mission critical environment (no weird hacks)? Or if not what the projected impact of this would be? |
Provide test results plz |
|
Wow, how did the company did not think to test with test suite units before shipping the boards out?? Really incredible beyond belief. |
|
|
|
C910 datasheet: https://www.t-head.cn/product/C910 |
|
|
The RISC-V ISA manual is even more explicit about this: that said, the T-Head designs pretty frequently violate the ISA so it wouldn't be surprising that's the case here too. Unfortunately RISC-V still has vendors self-certify their designs. So it doesn't really matter what any of the specs say, we're just stuck with the mess. Unless there's some magic bit we can set to make this IEEE, we're probably stuck just recording it as a user-visible errata -- at least we can probe for this by executing a code sequence and then turn off the FPU until userspace acks it can handle the errata. That said, that's all probably best discussed on the upstream lists. |
|
Please refer to this issue. C910 may have a misunderstanding of the IEEE 754 on after rounding and Rounding-direction attributes. Forgive me for taking the liberty of commenting. |
In my opinion this case expected output 1，the LicheePi 4A is true。 |
However test program on K230 reports 3 |
|
Statement of the underflow problem of Xuantie C910 (by XuanTie Group) Description of the issue For RISC-V floating-point arithmetic instructions, tininess is detected after rounding as the exponent range is unbounded. Xuantie C910 uses bounded exponent to judge underflow exceptions, resulting in the following extreme cases where underflow bit may not be set: Impact of the issue On multiplication, division and conversion instructions(narrow conversion), Xuantie C910 will miss the underflow flag only when the corner result is presented, but will still get the result consistent with correct behaviour. |
Source link? |
Can you provide a link to this reply? |
|
I am an engineer from the XuanTie Group, and it was here for the first time that the official replied to this issue. All responses from other locations will point here, so here is the Source Link. |
RevySR
changed the title
Is C920v2 and C907 also affected by this issue? |
|
C920v2 and C907 are not affected by this issue, and they are not open source right now. |
Some glibc tests failed because of missing expected underflow float exceptions.
The failing math tests have one thing in common: underflow float exception is missing. Here is the test log from
math/test-float-double-div:I built the following minimal reproduction out of this:
And the following command is used to compile and run it:
gcc fdiv-repro.c -lm -std=c2x -o fdiv-repro && ./fdiv-reproExpected behavior: the program output
Success: Exception Underflow is set!.However, I got
Failure: Exception Underflow is not set!!!.Test results on different machines, OS and architectures:
This might suggest something is wrong in the floating-point implementation of C910 & C920.
The text was updated successfully, but these errors were encountered: