Precision errors in Math.cbrt() on GTK, EFL

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Zan Dobersek]

Math.cbrt(), introduced in r158401, is returning unexpected values in the js/math.html layout test (and the related stress tests) that are indicating precision errors. This only occurs on GTK and EFL.
http://trac.webkit.org/changeset/158401

The precision error originates in the underlying cbrt() call in JSC::mathProtoFuncCbrt. pow() works as expected, FWIW.

Diff:
--- /home/slave/webkitgtk/gtk-linux-64-release/build/layout-test-results/js/math-expected.txt
+++ /home/slave/webkitgtk/gtk-linux-64-release/build/layout-test-results/js/math-actual.txt
@@ -184,8 +184,8 @@
 PASS Math.cbrt(NaN) is NaN
 PASS Math.cbrt(0) is 0
 PASS Math.cbrt(-0) is -0
-PASS Math.cbrt(27) is 3
-PASS Math.cbrt(-27) is -3
+FAIL Math.cbrt(27) should be 3. Was 3.0000000000000004.
+FAIL Math.cbrt(-27) should be -3. Was -3.0000000000000004.
 PASS Math.cbrt(Infinity) is Infinity
 PASS Math.cbrt(-Infinity) is -Infinity
 PASS Math.cosh(NaN) is NaN

[Oliver Hunt]

Try changing the test to +/-8 -> +/-2

[Zan Dobersek]

Created attachment 215808 [details]
Patch

[Csaba Osztrogonác]

Comment on attachment 215808 [details]
Patch

LGTM

[WebKit Commit Bot]

Comment on attachment 215808 [details]
Patch

Clearing flags on attachment: 215808

Committed r158545: <http://trac.webkit.org/changeset/158545>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Darin Adler]

This patch just stops testing for this bug, it doesn’t fix the bug. Do we want to fix the bug?

[Oliver Hunt]

(In reply to comment #6)
> This patch just stops testing for this bug, it doesn’t fix the bug. Do we want to fix the bug?

The bug is lack of precision in the linux/gtk lib math, it can't be fixed in JSC short of us reimplementing cbrt entirely