bug653153.js test fails when cross-compiling JS to 32-bit x86 (from x86-64); floating-point subtraction gives wrong result
Categories
(Core :: JavaScript Engine, defect, P5)
Tracking
()
People
(Reporter: iain, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:73.0) Gecko/20100101 Firefox/73.0
Steps to reproduce:
We're trying to build Spidermonkey 68 for Ubuntu and Debian currently. It's mostly fine but one last issue is that this test fails on 32-bit x86 (which we call i386):
/<<PKGBUILDDIR>>/js/src/jit-test/tests/basic/bug653153.js:16:1 Error: Assertion failed: got false, expected true
Stack:
@/<<PKGBUILDDIR>>/js/src/jit-test/tests/basic/bug653153.js:16:1
Exit code: 3
FAIL - basic/bug653153.js
TEST-UNEXPECTED-FAIL | js/src/jit-test/tests/basic/bug653153.js | /<<PKGBUILDDIR>>/js/src/jit-test/tests/basic/bug653153.js:16:1 Error: Assertion failed: got false, expected true (code 3, args "") [0.0 s]
INFO exit-status : 3
INFO timed-out : False
INFO stderr 2> /<<PKGBUILDDIR>>/js/src/jit-test/tests/basic/bug653153.js:16:1 Error: Assertion failed: got false, expected true
INFO stderr 2> Stack:
INFO stderr 2> @/<<PKGBUILDDIR>>/js/src/jit-test/tests/basic/bug653153.js:16:1
Actual results:
If I run interactively on i386:
js> parseInt(1e21 - 65537) > 1e20
false
js> parseInt(1e21 - 65537)
1
js> 1e21 - 65537
1e+21
This AFAICS is a new test relative to Spidermonkey 60, and the same behaviour is present there so it's not a regression - but the test is finding a bug.
Expected results:
And on x86_64 (called amd64 in Debian-land):
js> parseInt(1e21 - 65537) > 1e20
true
js> parseInt(1e21 - 65537)
999999999999999900000
js> 1e21 - 65537
999999999999999900000
These are the correct results.
I tried the usual tricks that I know of: build with -fexcess-precision=standard and/or -ffloat-store but it didn't help. Do note that we are building with gcc/g++.
OK, I just rebuilt 68 with clang/clang++ and the same failure happens there, thankfully. :)
Hi,
I don't have the technical knowledge to confirm this issue but I'll add product and component so the team can make some research on it. Hopefully, someone with a more deep understanding of this matter can help. Feel free to route this ticket to the corresponding team.
Regards,
Jerónimo
|
||
Comment 3•5 years ago
|
||
This sounds similar to bug 1343608. Cross-compiling to x86 on x64 systems seems to require to set -mfpmath=sse -msse -msse2. That way floating point operations are guaranteed to use SSE instructions instead of x87-fpu instructions.
|
||
Comment 4•5 years ago
|
||
Hmm. That bug didn't reproduce under Clang, though, and this one does.
Iain, what happens if you use the compiler flags in comment 3?
|
|
||
Comment 5•5 years ago
|
||
Just to clarify: the bug is that 1e21 - 65537 is 1e+21 on i386 when it should be 999999999999999900000 as it is on x86_64.
The parseInt stuff is just other features working as expected downstream of the bug.
|
||
Comment 6•5 years ago
|
||
(In reply to André Bargull [:anba] from comment #3)
This sounds similar to bug 1343608. Cross-compiling to x86 on x64 systems seems to require to set
-mfpmath=sse -msse -msse2. That way floating point operations are guaranteed to use SSE instructions instead of x87-fpu instructions.
This worked as you suggested.
So I think the bug can be closed, assuming that mozjs (and based products) are requiring CPU with SSE2 support.
|
||
Comment 7•5 years ago
|
||
Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)
|
|
||
Comment 8•5 years ago
|
||
Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)
|
|
||
Comment 9•5 years ago
|
||
Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)
|
|
||
Comment 10•5 years ago
|
||
The severity of these bugs was changed, mistakenly, from normal to S3.
Because these bugs have a priority of --, indicating that they have not been previously triaged, these bugs should be changed to Severity of --.
|
|
||
Comment 11•5 years ago
|
||
In theory, SpiderMonkey shouldn't build if it's going to give wrong answers. There could be an assertion on startup that math works as desired. However, this isn't a major priority for us.
|
||
Comment 12•1 year ago
|
||
A needinfo is requested from the reporter, however, the reporter is inactive on Bugzilla. Closing the bug as incomplete.
For more information, please visit BugBot documentation.
Description
•