<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Hi Ludovic,</p>
<p>Catching up on email, your understanding of my comments is
correct. Since the relevant Java specification are agnostic
towards what bits are in a NaN's significand, I don't think the
Java implementations of this these methods should be updated to
accommodate additional requirements for NaN handling used
elsewhere.<br>
</p>
<p>Thanks,<br>
</p>
<p>-Joe<br>
</p>
<div class="moz-cite-prefix">On 12/8/2022 11:27 AM, Ludovic Henry
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CADT88DudMeQ6akYbz7an+QXXQrqBbn_0hTw4Hu28959ZaQxpUw@mail.gmail.com">
<div dir="ltr">Hi Joe,
<div><br>
</div>
<div>I got an answer on the glibc mailing list, and the overall
answer is "it is the expected behavior" [1].</div>
<div><br>
</div>
<div>From your answer, IIUC, you would want things to stand
as-is, and it's the test case that should be fixed, correct?</div>
<div><br>
</div>
<div>Ludovic</div>
<div><br>
</div>
<div>[1] <a href="https://urldefense.com/v3/__https://sourceware.org/pipermail/libc-alpha/2022-December/143912.html__;!!ACWV5N9M2RV99hQ!JvhCHTYr_G9gOYrCS4khD78epumPjjRQ14dxB5Kzp6Yukj-_sVbxkEZ4OXvevB2LYd-FtibWc9goJkkKBg$" moz-do-not-send="true">https://sourceware.org/pipermail/libc-alpha/2022-December/143912.html</a></div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Dec 8, 2022 at 4:08 PM
Joseph D. Darcy <<a href="mailto:joe.darcy@oracle.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">joe.darcy@oracle.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>
<p><br>
</p>
<div>On 12/8/2022 10:01 AM, Ludovic Henry wrote:<br>
</div>
<blockquote type="cite">
<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">
<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" target="_blank" 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://urldefense.com/v3/__https://sourceware.org/glibc/wiki/Release/2.35*RISC-V_.28rv64imafdc.2Flp64d.29__;Iw!!ACWV5N9M2RV99hQ!JvhCHTYr_G9gOYrCS4khD78epumPjjRQ14dxB5Kzp6Yukj-_sVbxkEZ4OXvevB2LYd-FtibWc9jKIBqBRw$" rel="noreferrer" target="_blank" moz-do-not-send="true">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>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>