<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Hello,</p>
<p>Okay, so it looks like the test is expected the same bit pattern
to be used for a NaN output if a NaN was used as an input.</p>
<p>That isn't necessarily unreasonable, but it is *not* required by
the specifications for the Math or StrictMath method, spec for
Math.acos:</p>
<p>
<blockquote type="cite">Returns the arc cosine of a value; the
returned angle is in the range 0.0 through <i>pi</i>. Special
case:
<ul>
<li>If the argument is NaN or its absolute value is greater
than 1, then the result is NaN. </li>
<li>If the argument is <code>1.0</code>, the result is
positive zero. </li>
</ul>
<p>The computed result must be within 1 ulp of the exact result.
Results must be semi-monotonic.</p>
</blockquote>
<a class="moz-txt-link-freetext" href="https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/Math.html#acos(double)">https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/Math.html#acos(double)</a><br>
</p>
<p>On a NaN argument, any NaN bit pattern is valid per the spec.
Even if you're trying to return the same NaN, there can be
challenges to doing so depending on how the underlying processor
handles signaling NaNs, a concept which doesn't exist in the Java
platform.</p>
<p>HTH,<br>
</p>
<p>-Joe<br>
</p>
<div class="moz-cite-prefix">On 12/8/2022 8:26 AM, Ludovic Henry
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CADT88DuxtUt+0OYMZeSKek1GAwEQEVXMuRK+moc4xHA9w--01Q@mail.gmail.com">
<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" moz-do-not-send="true" class="moz-txt-link-freetext">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><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>
</blockquote>
</body>
</html>