<div dir="ltr"><div dir="ltr">Adding the right address for core-libs-dev.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 8, 2022 at 12:19 PM Ludovic Henry <<a href="mailto:ludovic@rivosinc.com">ludovic@rivosinc.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello,<div><br></div><div>I've noticed that some Math trigonometry tests are failing in the GNU Mauve test suite. From digging into it, it's related to NaN values being passed to java.lang.Math trigonometry functions, and how these values are handled in the native libm library.</div><div><br></div><div>Given the following C test case compiled and run with `gcc acos.c -lm && ./a.out`<br><br>```</div><div>#include <stdint.h><br>#include <math.h><br>#include <stdlib.h><br>#include <stdio.h><br><br>void main(int argc, char* argv[]) {<br>    int64_t bitsNaN = 0x7fff800000000000L;<br>    double valNaN = *((double*)&bitsNaN);<br><br>    double resD = acos(valNaN);<br>    int64_t res = *((int64_t*)&resD);<br>    if (!(res == bitsNaN)) {<br>        printf("expected 0x%lx but got 0x%lx\n", bitsNaN, res);<br>        exit(1);<br>    }<br>}<br></div><div>```</div><div></div><div><br></div><div>On a Linux-x64, the test succeeds, but on Linux-RISC-V, the test fails.</div><div><br></div><div>You've the same test failure in the equivalent Java code:</div><div><br></div><div>```</div><div>public class acos {<br>    public static void main (String[] args) {<br>        long bitsNaN = 0x7fff800000000000L;<br>        double valNaN = Double.longBitsToDouble(bitsNaN);<br><br>        long res = Double.doubleToRawLongBits(Math.acos(valNaN));<br>        if (!(res == bitsNaN)) {<br>            throw new RuntimeException(String.format("expected 0x%x but got 0x%x", bitsNaN, res));<br>        }<br>    }<br>}<br></div><div>```</div><div><br></div><div>What approach should we take in these cases? Is it that the test case is wrong, and should assume that given a NaN, any value of NaN returned is valid? Or should we make sure that the behavior is the same across platforms and that we "fix" any difference in behavior of the native library?</div><div><br></div><div>Cheers,</div><div>Ludovic</div></div>
</blockquote></div></div>