Re: Bug#905829: mozjs52: tests fail on sparc64: numeric operations expecting NaN get undefined instead

[Dennis Clarke <dclarke@blastwave.org>]

On 08/10/2018 06:34 AM, Simon McVittie wrote:
> Source: mozjs52
> Version: 52.9.1-1
> Severity: normal
> User: debian-sparc@lists.debian.org
> Usertags: sparc64
>
> Lots of mozjs52 tests fail on sparc64 because the test does some numeric
> operation that expects NaN (not a number) as result, but gets undefined
> back instead, for example:
>
> FAILED! Number.NEGATIVE_INFINITY % Number.NEGATIVE_INFINITY = undefined expected: NaN
> FAILED! VAR1 =-Infinity; VAR2=-Infinity; VAR1 %= VAR2; VAR1 = undefined expected: NaN
> FAILED! [reported from top level script] testfunc : Expected value 'NaN', Actual value 'undefined'
>
> Does sparc64 have an unusual binary representation of NaN and undefined
> or something?

This seems oddly familiar to me. I seem to recall that Sun implemented
the Payne and Hanek’s method for range reduction within some elementary
functions.  I will go look at the SUN fdlibm library source code and see
what is there but floating point modulo operations should follow the
specification rules here regardless of architecture.  I don't think
sparc is "special" in this regard.  I'll dig around a bit as this feels
familiar in some way.

Dennis