<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 12/8/2022 10:01 AM, Ludovic Henry
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CADT88DvmACxJCzGMck_ccg704tra5UcCOKH1zmUsDEuszc0Srg@mail.gmail.com">
      
      <div dir="ltr">Hi,
        <div><br>
        </div>
        <div>Yes, this is very much a difference of behavior at the
          libm/libc level. I'm trying to figure out whether that
          behavior difference is acceptable from the libm/libc level (is
          it considered a bug to behave differently across architectures
          in that case?). If that behaviour is acceptable in libm/libc,
          then is it acceptable to behave differently in Java across
          architectures?</div>
        <div><br>
        </div>
        <div>From your answer Palmer, the difference _might_ not be
          acceptable in the glibc test suite (I haven't check why the
          tests are failing). I'm still trying to figure that one out.</div>
        <div><br>
        </div>
        <div>From your answer Joe, the difference _is_ acceptable from
          the documentation. IMO the question becomes whether it's a
          case of the implementation details bleeding into the API and
          whether we want to be 100% compatible to avoid further issues.
          The fix for that could be a simple `RISCV_ONLY(if (isnan(v))
          return v);` or equivalent
          in src/java.base/share/native/libjava/StrictMath.c to match
          the behavior without any extra cost for other platforms.</div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>I would not support changing the library native sources (or Java
      sources) in this way to accommodate NaN handling.<br>
    </p>
    <p>-Joe<br>
    </p>
    <blockquote type="cite" cite="mid:CADT88DvmACxJCzGMck_ccg704tra5UcCOKH1zmUsDEuszc0Srg@mail.gmail.com">
      <div dir="ltr">
        <div><br>
        </div>
        <div>Thanks,</div>
        <div>Ludovic</div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Thu, Dec 8, 2022 at 2:50 PM
          Palmer Dabbelt <<a href="mailto:palmer@dabbelt.com" moz-do-not-send="true" class="moz-txt-link-freetext">palmer@dabbelt.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">On
          Thu, 08 Dec 2022 08:26:30 PST (-0800), <a href="mailto:ludovic@rivosinc.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">ludovic@rivosinc.com</a>
          wrote:<br>
          > Adding the right address for core-libs-dev.<br>
          ><br>
          > On Thu, Dec 8, 2022 at 12:19 PM Ludovic Henry <<a href="mailto:ludovic@rivosinc.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">ludovic@rivosinc.com</a>>
          wrote:<br>
          ><br>
          >> Hello,<br>
          >><br>
          >> I've noticed that some Math trigonometry tests are
          failing in the GNU<br>
          >> Mauve test suite. From digging into it, it's related
          to NaN values being<br>
          >> passed to java.lang.Math trigonometry functions, and
          how these values are<br>
          >> handled in the native libm library.<br>
          >><br>
          >> Given the following C test case compiled and run with
          `gcc acos.c -lm &&<br>
          >> ./a.out`<br>
          >><br>
          >> ```<br>
          >> #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>
          >> ```<br>
          >><br>
          >> On a Linux-x64, the test succeeds, but on
          Linux-RISC-V, the test fails.<br>
          >><br>
          >> You've the same test failure in the equivalent Java
          code:<br>
          >><br>
          >> ```<br>
          >> 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<br>
          >> got 0x%x", bitsNaN, res));<br>
          >>         }<br>
          >>     }<br>
          >> }<br>
          >> ```<br>
          >><br>
          >> What approach should we take in these cases? Is it
          that the test case is<br>
          >> wrong, and should assume that given a NaN, any value
          of NaN returned is<br>
          >> valid? Or should we make sure that the behavior is
          the same across<br>
          >> platforms and that we "fix" any difference in
          behavior of the native<br>
          >> library?<br>
          <br>
          It might just be a glibc bug, we're failing the acos() tests:
          <br>
          <a href="https://sourceware.org/glibc/wiki/Release/2.35#RISC-V_.28rv64imafdc.2Flp64d.29" rel="noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://sourceware.org/glibc/wiki/Release/2.35#RISC-V_.28rv64imafdc.2Flp64d.29</a>
          <br>
          .  I haven't looked at why, but they do have some nan-related
          bits in <br>
          there.<br>
          <br>
          >><br>
          >> Cheers,<br>
          >> Ludovic<br>
          >><br>
        </blockquote>
      </div>
    </blockquote>
  </body>
</html>