The interpreter engine for the core JavaScript language, independent of the browser's object model. File ONLY core JavaScript language bugs in this category. For bugs involving browser objects such as "window" and "document", use the "DOM" component. For bugs involving calls between JavaScript and C++, use the "XPConnect" component.

Comment on attachment 8591594[details]
MozReview Request: bz://1153602/ProgramFOX
https://reviewboard.mozilla.org/r/6991/#review6243
::: js/src/tests/ecma_7/SIMD/unary-operations.js:54
(Diff revision 3)
> - return Math.fround(1 / Math.sqrt(a));
> + return Math.fround(1 / Math.fround(Math.sqrt(Math.fround(a))));
It looks like we can ensure only float32 values flow in here, so instead of |Math.fround(a)|, use |a| directly and add
assertEq(Math.fround(a), a);
as a sanity check.
::: js/src/tests/ecma_7/SIMD/unary-operations.js:62
(Diff revision 3)
> + [Math.pow(2, 31), Math.pow(2, -31), Math.pow(2, -1074), Math.pow(2, -149)].map(reciprocalsqrtf)]
If you're passing these into float32 values, Math.pow(2, -1074) isn't a float32 and will round to +0. There's no reason not to use +0 directly. (And certainly +0 is a very good candidate for testing.)
Past that, on second glance it seems very, very strange to me to use reciprocalsqrtf to generate expected values here. I'd perform comparisons against constants, or arithmetic expressions as close to constant as possible, so that there's less of a chance of offsetting errors:
var vals = [
[[1, 1, 0.25, 0.25],
[1, 1, 2, 2]],
[[25, 16, 6.25, 1.5625],
[Math.fround(1 / 5), 0.25, Math.fround(1 / 2.5), Math.fround(1 / 1.25)]],
[[NaN, -0, Infinity, -Infinity],
[NaN, -Infinity, +0, NaN]],
[[Math.pow(2, 32), Math.pow(2, -32), +0, Math.pow(2, -148)],
[Math.pow(2, -16), Math.pow(2, 16), Infinity, Math.pow(2, 74)]],
];
I checked, and 2**-148 has the same 1/sqrt and sqrt(1/) differences as that was designed to test, originally. But 2**-148 and 2**32 are better here because the results of the squaring aren't irrational. Probably there *should* be a test with an irrational expected output, but I've been staring at this too long as-is and shouldn't take more time to come up with a nice testcase. If you end up coming up with one, please write out its value as an exact binary fraction in decimal form --