| Summary: | Incorrect NAN-boxing for float registers in RISC-V | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | ivan.tetyushkin |
| Component: | vex | Assignee: | Julian Seward <jseward> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ivan.tetyushkin, laokz, mark, petr.pavlu, pjfloyd, rjiejie, rjones, sam |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | riscv64: Fix nan-boxing for single-precision calculations | ||
Hi I've noticed that current implementation in RISC-V behaves wrongly for not nan-boxed float values (details upper). To fix this, you can use attached patch (the test included in the patch). Could you take a look here please? Looks good. Thanks for including the testcase so I could follow. Pushed patch as: commit 9dd24c9b57cde064ca8b356c985b2e1cb7972adc Author: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com> Date: Mon Apr 21 11:59:48 2025 +0300 riscv64: Fix nan-boxing for single-precision calculations For float values, for arithmetics we expect to have canonical nan if used double register is not currectly nan-boxed. https://bugs.kde.org/show_bug.cgi?id=503098 Can we update README.riscv64 to remove this line (3) Operations do not check if the input operands are correctly NaN-boxed. ? |
Created attachment 180473 [details] riscv64: Fix nan-boxing for single-precision calculations Float arithmetic instructions check input registers. If any of input registers is not NAN-boxed, this instruction treats it as canonical NAN. Here is a line from the RISC-V unprivileged specification: ``` NaN Boxing of Narrower Values ... Apart from transfer operations described in the previous paragraph, all other floating-point operations on narrower-bit operations (n<FLEN) check if the input operands are correctly NaN-boxed, i.e., all upper FLEN-n bits are 1. If so, the n least-significant bits of the input are used as the input value, otherwise the input value is treated as an n-bit canonical NaN. ``` Currently, as we use FLW to get a float register, the register is always correctly NaN-boxed, which results in a wrong operation result. Attached file is the patch that fixes this behavior.