[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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.


Reply to: